Last post Nov 01, 2016 02:28 AM by Chris Zhao
Oct 12, 2016 12:27 PM|Kiran.Manchikatla|LINK
we have hosted our web application in IIS in production environment. we found that users are being logged out randomly while they are working. we have seen IIS error logs and found that w3wp worker process is getting terminated abruptly. But the same code
is working fine in other environments this is only happening in our production. we have also seen lot of thread abort exceptions ... we changed the code from Response.Redirect() and Response.End() to Context.ApplicationInstance.CompleteRequest(). Due to process
termination we are even losing session information.
There is a separate app pool configured for our application. Does any of you have faced such (user logouts) issue previously.. If you require any other information please let me know.. any help is greatly appreciated..
Oct 12, 2016 12:41 PM|Siva Krishna Macha|LINK
Is your application deployed in single server (i.e., without load balancer) ?
If it's in multiple servers - then need to ensure the session is handled properly.
Oct 12, 2016 04:34 PM|Chris Zhao|LINK
Session loss problems can result from a misconfigured application pool. For example, if the application pool your site is running is configured as a web farm or a web garden (by setting the maximum number of worker processes to more than one), and if you're
not using the session service or SQL sessions, incoming requests will unpredictably go to one of the worker processes, and if it's not the one the session was created on, it's lost. Remember to synchronize your <machinekey> between all machines in the farm.
Oct 12, 2016 07:30 PM|Mikesdotnetting|LINK
This is a very good reason not to use Session to manage logins. You should change your application to use authentication cookies instead.
Oct 20, 2016 07:37 AM|Kiran.Manchikatla|LINK
Thank you , for your response . Application was hosted on a single server and there are no load balancer's.
Oct 20, 2016 01:30 PM|Siva Krishna Macha|LINK
Probably worth checking the entry in the Event log (Windows + R (run) and then type eventvwr and enter).
That should give some clue regarding the termination of the process.
Oct 21, 2016 10:53 AM|PatriceSc|LINK
Terminated abruptly? That is? Doesn't it give some more details such as an error message or a termination reason? It's also a bit unclear if this is a w3wp crash or a pool recycle.
https://blogs.msdn.microsoft.com/johan/2007/05/16/common-reasons-why-your-application-pool-may-unexpectedly-recycle/ but IMO it's mcuh better to take the time to understand first what happens.
Depending on which access level you have you could also take a memory dump when the crash happens to try to narrow down the root cause.
So IMO if you need further help let's start from the EXACT error you see for now. Is this really a w3wp process crash?
Oct 25, 2016 07:26 AM|Kiran.Manchikatla|LINK
I verified the Dump file ... and here are the error details.. I think's it's with in CLR 0xC0000005 (Access Voilation Exception) .. Error shows that the thread tried to read from or write to a virtual address for which it does not have the appropriate access.Please
go through the below details for more information...
671bf356 8b00 mov eax,dword ptr [eax]
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 671bf356 (clr+0x0000f356)
ExceptionCode: c0000005 (Access violation)
Attempt to read from address 00000004
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.
FAULTING_MODULE: 748b0000 kernel32
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
671bf356 8b00 mov eax,dword ptr [eax]
LAST_CONTROL_TRANSFER: from 671bf2a4 to 671bf356
WARNING: Stack unwind information not available. Following frames may be wrong.
1284ef88 671bf2a4 00000000 00000028 00000000 clr+0xf356
1284efac 671bddc6 336e4d1c 00000071 00000028 clr+0xf2a4
1284eff8 671bd900 673c443f 328e77d0 00000000 clr+0xddc6
1284f2bc 671bd9cc 1284f2e8 673c443f 1284f6a4 clr+0xd900
1284f5f4 673c4d48 673c443f 1284f6a4 00001f51 clr+0xd9cc
1284f65c 673c4b76 328e77d0 1284f6a4 00001f51 clr+0x214d48
1284f9d4 6a1fab89 014c0690 328e77d0 6a1fa880 clr+0x214b76
1284fcf0 6a1fac7e 00000cdc 328e77d0 00001478 AppDynamics_Profiler_x86+0x4ab89
1284fd34 6a1fa9ac 00000cdc 328e77d0 00001478 AppDynamics_Profiler_x86+0x4ac7e
1284fd7c 6a1f9902 328e77d0 00001478 3ab66690 AppDynamics_Profiler_x86+0x4a9ac
1284fdb4 6a1f937d 1284fdd0 6a1fa09c 3ab66650 AppDynamics_Profiler_x86+0x49902
1284fdbc 6a1fa09c 3ab66650 3ab66650 124ec3e0 AppDynamics_Profiler_x86+0x4937d
1284fdd0 6a1f9464 3ab66650 434c2e0a 00000000 AppDynamics_Profiler_x86+0x4a09c
1284fe04 6a1f9559 434c2e4e 00000000 00000000 AppDynamics_Profiler_x86+0x49464
1284fe40 748c336a 124ec3e0 1284fe8c 76f99902 AppDynamics_Profiler_x86+0x49559
1284fe4c 76f99902 124ec3e0 6d8a93df 00000000 kernel32+0x1336a
1284fe8c 76f998d5 6a1f9510 124ec3e0 ffffffff ntdll+0x39902
1284fea4 00000000 6a1f9510 124ec3e0 00000000 ntdll+0x398d5
STACK_COMMAND: ~23s; .ecxr ; kb
Nov 01, 2016 02:28 AM|Chris Zhao|LINK
we have also seen lot of thread abort exceptions ... we changed the code from Response.Redirect() and Response.End() to Context.ApplicationInstance.CompleteRequest(). Due to process termination we are even losing session information.
You can do is use the overloaded version of Redirect:
This does not abort the thread.