IIS 5 & IIS 6
Something wrong with rpcrt4.dll? Maybe msvcr80.dll? Symptoms: Droppin...
Last post May 11, 2008 03:37 PM by JaroDunajsky
May 09, 2008 02:39 PM|USMCEddie|LINK
Ladies and Gents,
I've been digging on this one for several days, and I just can't quite get a handle on it. I've run as many diagnostics agents that I could get my hands on, and read several blogs and articles, but nothing seems to have precisely what I'm after. Would
someone take a peek at this for me and nudge me in the right direction please?
The symptom I'm observing: The session is unexpectedly severed, which triggers the user to log back in seconds after initially logging in... this ticks them off quite badly, and the encrypted session id is how we allow them to navigate the site securely.
In HTTP Errors I get 1492904551 Connection_Dropped AppPool+#2
Event viewer shows nothing. Filemon shows no errors.
Analysis for crashed iis related processes (all) in debugdiag is:
In w3wp__PID__9440__Date__05_08_2008__Time_09_51_18AM__89__First chance exception 0X00000005.dmp the assembly instruction at
kernel32!RaiseException+53 in C:\WINDOWS\system32\kernel32.dll from
Microsoft Corporation has caused an unknown exception (0x00000005) on thread
This exception originated from rpcrt4!RpcpRaiseException+24.
I also get these from the memory leak tester.
msvcr80.dll is responsible
for 4.16 KBytes worth of outstanding allocations. The following are the top 2 memory consuming functions:
4.16 KBytes worth of outstanding allocations.
kernel32.dll (a known
Windows memory manager) is responsible for 4.06 KBytes worth of outstanding allocations. These allocations appear to have originated from the following module(s) and function(s):
No module info available. Please see the
callstack samples for further information on these allocations.
Call stack sample 1
Would someone please give me a hand? I'm pretty rookie with this debugging thing.
May 11, 2008 03:37 PM|JaroDunajsky|LINK
I don't think the leaks have any significance for your investigation. The COM object being accesed may have already been already released. It looks like code on the stack should be beyond control of your application. Can you consistently reproduce with
the same stack? If not then there may be a heap corruption in your process.
You could use pageheap (http://support.microsoft.com/kb/286470) to narrow down the issue, but I'm not sure it would help in your case. (Just don't forget to disable pageheap once you are done with investigation).