question

JnDaiJnsson-1929 avatar image
0 Votes"
JnDaiJnsson-1929 asked cooldadtx commented

System.Web.HttpException happening when session expires or if it is abandoned

I have been dealing with this sneaky exception for a while, and I'm having a very hard time figuring it out. When a session expires or when I call Session.Abandon() the application will run for a second and then Visual studio will tell me it is in a break mode and will stop the debugging. When this happens on our production server it will kill the application pool. The project is a .Net webforms application running on .Net 4.5.2.

I've tried stepping through all the code after calling Session.Abandon() and it will throw the exception on random places.

The stack trace:

Exception: System.Web.HttpException
Message: Exception of type 'System.Web.HttpException' was thrown.
StackTrace:    at System.Web.HttpAsyncResult.End()
   at System.Web.Util.AspCompatApplicationStep.RaiseAspCompatEvent(HttpContext context, HttpApplication app, String sessionId, EventHandler eventHandler, Object source, EventArgs eventArgs)
   at System.Web.HttpApplicationFactory.FireSessionOnEnd(HttpSessionState session, Object eventSource, EventArgs eventArgs)
   at System.Web.SessionState.SessionOnEndTargetWorkItem.RaiseOnEndCallback()
   at System.Web.Util.WorkItem.CallCallbackWithAssert(WorkItemCallback callback)
   at System.Web.Util.WorkItem.OnQueueUserWorkItemCompletion(Object state)
   at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
InnerException: System.ArgumentNullException
Message: Value cannot be null.
Parameter name: httpContext
StackTrace:    at System.Web.HttpContextWrapper..ctor(HttpContext httpContext)
   at System.Web.HttpApplication.<>c__DisplayClass284_0.<OnExecuteRequestStep>b__0(Action nextStepAction)
   at System.Web.HttpApplication.StepInvoker.Invoke(Action executionStep)
   at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


All help is greatly appreciated!

dotnet-csharpvs-debuggingdotnet-standarddotnet-aspnet-webforms
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

cooldadtx avatar image
1 Vote"
cooldadtx answered cooldadtx commented

The actual exception that is causing this is a bad argument (null) being passed to HttpContextWrapper. This is causing cascading failures. The question becomes why would it do that. At the top of my list of suspects is any code that you have written (perhaps in Application) that is using HttpContext. Perhaps it is on your EndRequest or Session_End methods or similar. It could also be caused by a handler you rely on.

To debug this I would change the exception settings in the debugger to break when ArgumentNullException is thrown. Then run the code and let it fail. When the exception is thrown you'll get thrown into the debugger (perhaps even before your test case occurs). Once in the debugger however you have the callstack and can hopefully find some code either written by you or a third party you rely on that is causing the problem.

· 4
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hi, thank you for the response.

Even when telling the debugger to break at an ArgumentNullException this still happens, the exception is in System.Web.dll so I can't get the debugger to stop there.
There are no references in HttpContext in EndRequest nor Session_End, and I am not sure what you mean by Application.

Best regards

0 Votes 0 ·
cooldadtx avatar image cooldadtx JnDaiJnsson-1929 ·

telling the debugger to break at ANE should break irrelevant of the location and then the callstack window would be available even if the code wasn't. That's odd.

The exception appears to be coming from the ASPNET compatibility code. Do you have this enabled on your app and do you need it?
It is getting triggered by the Session_OnEnd event which makes sense. Here's the relevant code.

private void FireSessionOnEnd(HttpSessionState session, object eventSource, EventArgs eventArgs)
        {
            if (this._sessionOnEndMethod != null)
            {
                HttpApplication specialApplicationInstance = this.GetSpecialApplicationInstance();
                if (AspCompatApplicationStep.AnyStaObjectsInSessionState(session) || HttpRuntime.ApartmentThreading)
                {
                    HttpApplicationFactory.AspCompatSessionOnEndHelper aspCompatSessionOnEndHelper = new HttpApplicationFactory.AspCompatSessionOnEndHelper(specialApplicationInstance, session, eventSource, eventArgs);
                    AspCompatApplicationStep.RaiseAspCompatEvent(null, specialApplicationInstance, session.SessionID, this._sessionOnEndEventHandlerAspCompatHelper, aspCompatSessionOnEndHelper, EventArgs.Empty);
                }
...


It only triggers if you have a Session_OnEnd handler defined or using COM.

1 Vote 1 ·

Thank you so much!
This comment got us onto the right track. After days of debugging the problem is fixed :)


We tried adding
<system.serviceModel> <serviceHostingEnvironment aspNetCompatibilityEnabled="false" /> </system.serviceModel>
To our web.config to turn off the Compatability, that didn't do the trick so we deleted the Session_End method in Global.asax, and that was what did the trick!
The method was empty and we tried to put a breakpoint in it but it was never hit when the bug occurred so we assumed the method was not the cause.
Do you by any chance know why deleting Session_End fixes this issue when there was no code in it?


If you are ever in Reykjavík we would love to invite you for a beer!

0 Votes 0 ·
Show more comments