1

We recently integrated the ASP.Net Async SessionState Module and have started seeing null ref exceptions in our Global.asax Session_Start event handler.

I can't replicate it locally, and it doesn't appear to happen all the time in live, but I believe this is when we attempt to access HttpContext.Current in Session_Start. My guess is HttpContext.Current is sometimes null, because Session initialization is asynchronous.

Any suggestions as to how to address?

Matt
  • 25,467
  • 18
  • 120
  • 187
Matt Evans
  • 7,113
  • 7
  • 32
  • 64
  • did you implement your own `SessionStateStoreProviderAsyncBase`? if so, can you post some code? also, this package looks to work with HttpContextBase, not HttpContext – user326608 Dec 10 '18 at 05:43
  • @user326608 no we used the module linked in the question – Matt Evans Dec 10 '18 at 06:42

1 Answers1

2

Maybe the answer is too simple, but I have also seen this from time to time, and I'd suggest that you safeguard your code inside the Session_Start event like

if (HttpContext.Current !== null)
{
    // do your actions with the Current object
}
else
{
    // possibly add some logging here to see what's going on
}

If you notice it is just a race condition, your code will react properly and not just end up in a NullReferenceException.

Safeguarding it like this is in this particular case better than adding Elvis operators (?.) everywhere you're referencing it because that will lead into more complex scenarios for your testing/troubleshooting. In other cases, however, this operator is quite useful, for example in this different context.

Additionally, In the link you provided, I saw the hint "To implement your own async sessionstate provider which works with Microsoft.AspNet.SessionState.SessionStateModule, all you need to do is to implement a concrete SessionStateStoreProviderAsyncBase class which is included in the Microsoft.AspNet.SessionState.SessionStateModule NuGet package."

Maybe you just need to implement that class rather than using Session_Start - because here is always a HttpContext given as parameter and Session_Start is just there for backwards-compatibility?

Matt
  • 25,467
  • 18
  • 120
  • 187
  • Yes, this is pretty much what I have done. Unfortunately we need to HttpContext to perform some business logic – Matt Evans Dec 10 '18 at 06:43
  • 1
    In the link you provided, I saw the hint *"To implement your own async sessionstate provider which works with Microsoft.AspNet.SessionState.SessionStateModule, all you need to do is to implement a concrete SessionStateStoreProviderAsyncBase class which is included in the Microsoft.AspNet.SessionState.SessionStateModule NuGet package."* - just a guess: Maybe you just need to implement that class rather than using Session_Start - because here is always a HttpContext given as parameter and Session_Start is just there for backwards-compatibility? – Matt Dec 10 '18 at 08:24
  • Interesting idea. That may be worth exploring. I'll have a look – Matt Evans Dec 10 '18 at 08:57