Hi,

 I am receiving a null reference exception in SessionStateModule.PollLockedSessionCallbacks(). It seems to be associated with Async Callbacks. If I view my web page and refresh a couple of times, the AppDomain.CurrentDomain.UnhandledException is fired with the exception below.

System.NullReferenceException: Object reference not set to an instance of an object.
    at System.Web.SessionState.SessionStateModule.PollLockedSessionCallback(Object state)
    at System.Threading._TimerCallback.TimerCallback_Context(Object state)
    at System.Threading.ExecutionContext.runTryCode(Object userData)
    at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
    at System.Threading._TimerCallback.PerformTimerCallback(Object state)

The exception is terminating the asp worker process which is causing me problems.

I am using ASP.NET 2.0 with ASP.NET Ajax.

Any help will be greatly appreciated.

Thank you,

Jason Blackwell
 

HI, Jason Blackwell 

This was probably caused by using Sql Server Session state and . The resolution was to use Inproc session state for
debugging.

You can  look at the machine.config, which was the only config file above this
web.config in the hierarchy. Make sure the sql state was specified to InProc.

If i misunderstand you about your question, please feel free to correct me and i will try to help you with more information.

I hope the above information will be helpful. If you have any issues or concerns, please let me know. It's my pleasure to be

of assistance

 Rex,

 
Thanks for your reply.

 The session state is currently set to InProc in the web.config and machine.config. None of the pages use session so turning off session state is an option and does fix the problem but I would like to know exactly why this is happening. It only started happening on Wednesday (7/11) after the windows update for .NET was applied so I'm wondering if it could possibly have something to do with that.

The exception that is thrown is logged in the event viewer of the server. It is pasted below.
 EventType clr20r3, P1 aspnet_wp.exe, P2 2.0.50727.832, P3 461ef1db, P4 system.web, P5 2.0.0.0, P6 461ef1d2, P7 297c, P8 8d, P9 system.nullreferenceexception, P10 NIL.
 

 If you need anymore information from me please let me know. I really want to get to the bottom of this.

Thanks. 

I had the exact same issue along with many of the developers on my team.  We removed the Security Update for .NET Framework 2.0 (KB928365) from our machines and the problem went away. Your hunch was correct and most helpful!  The web is loaded with various issues that this "fix" is causing.

Have you found a fix for this yet.  I have the same problem and the only fix we have found is to uninstall the update.  If we do find the solution, I will post it.

 Thanks.

We have the same issue with an almost identical stack trace as in the original post. We also removed the KB928365 security patch and the problem went away, but we're at a point now where we are going to need to keep the patch installed.

buckeyes has another post (http://forums.asp.net/t/1132290.aspx) with a possible solution, or at least a workaround. I'll need to investigate our code further to make sure we don't have that issue. That situation also involves AJAX. Is this primarily an AJAX issue then? Is there any further word from MSFT?

 Dan

We were able to fix this issue.  As it turns out, the problem was caused by our custom IIdentity object we use to track authenticated users.  I switched our code to use a static, thread-safe collection and pull authenticated users from this collection instead of the HttpContext.Current.User property.  Now, our app does not replace the FormsIdentity object, and we no longer experience an app-pool crash under heavy load, and we can leave the security patch in place.

The solution suggested by MatthewP worked identically in my situation. Initially I suspected that the problem was caused by the location of the session state or the type of data stored it in. Further investigation proved this to be due to impersonation issues - specifically the assignment of IIdentity based objects to Context.User or to Thread.CurrentPrincipal. I was predictably able to reproduce this by refreshing the page 3-4 times but did not see the issue occur as frequently in production environments. It does not appear the problem is specific to servers under load.

 My solution was to simply move any assignments to Context.User into Context.Session since impersonation could be done where needed rather than assigning it for the lifetime of execution. Likely a better solution all around.

Hi all-

Just spent 4 hours struggling with this problem, including 2 hours after finding this thread; then another 3.5 hours on top of that, on the phone with MS Tech Support.

I thought I would share what I learned, which includes another workaround.

The workarounds suggested above were not an option for me for various reasons, and I was not using impersonation. My particular web application required a custom Security.Principal.

So, the upshot, after 3 and a half hours with the MS Tech connected remotely to my dev PC, was this:

Take the custom Security.Principal class out of the website project, and compile it as a Class library into a .DLL (assembly). Sign the .DLL with a Strong Name, and place it in the GAC. Adjust your code that references the custom Principal to call the code in its new location, if necessary- I wound up adding a Reference to the new assembly in my website project. No more problem!

A side note: if you use a WebSetup project to install your website, as I did, you can have it place the assembly into the server's GAC for you, during the installation.

There is apparently something about moving the code that deals with the IIdentity out of the main project (out of the process?), that avoids the issue.

I thought this might help someone else struggling with this issue. There is NOTHING on the web about this issue other than this thread!

Hope this helps someone,

-Andrew

I worked with MatthewP on this issue for our web application.  I called Microsoft for support on this issue and after analyzing three crash dumps from our application (running without MatthewP's fix so we could repro the error) they had a lot of info for me.  They initially stated that our custom IIdentity object was not serializing properly.  I implemented explicit serialization on this object and it continued to crash.  After analyzing the additional crash reports, Microsoft was able to supply me with an internal hotfix that fixes this issue.  It hasn't been released yet although they have informed me that they will be making it available for download in the near future.  It's ID is KB942086 and you'll need to call microsoft support to get it (as of this post, anyway) but this completely fixed the issue caused by KB928365 without the workaround that we were using and without the explicit serialization on our custom IIdentity object.

Fred-

Thanks for the update. With your new info "in hand", I contacted the Tech who worked on my case, and he verified that, although the error message I received was not the same as the one in the KB article you mentioned about the Hotfix, that the Hotfix *was* applicable to my case. Thanks to you, I now have the Hotfix and can apply it.

Incidentally, my Tech says he is the one who filed the bug which resulted in the Hotfix being developed. I wonder if you and I spoke to the same Tech? Small world if so.

Thanks again,

-Andrew

The tech that I worked with was named Sunil, and he was very helpful in this.  I don't know if he is the one that initially filed the bug, but he did say that there were a few other incidents of this issue that had been reported so it's possible.  Also, he just informed me today that the KB942086 is now publicly available, here's the direct link: http://support.microsoft.com/kb/942086

We are experiencing the same issue. However, I went to the URL outlined to get the fix and it was not available. You have to call MS support.