Re: W3WP Crashing

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Michael Temari (Michael_at_TemWare.Com)
Date: 03/24/05


Date: Wed, 23 Mar 2005 23:19:27 -0500

Thanks for the reply David.

 I have posted a new message under the subject "IISState Output (For Ken or
any Msft)".

Hopefully, Pat or Ken can take a look.

Thanks again,

Michael Temari
Michael@TemWare.Com

"David Wang [Msft]" <someone@online.microsoft.com> wrote in message
news:e4HRe0BMFHA.2988@TK2MSFTNGP14.phx.gbl...
> With IIS6, you should rarely need to restart IIS to get things working.
> Recycling the Application Pool that contains the troublesome application
> should be sufficient.
>
> At this point, something run by your application is crashing. That's what
> the events tell you (the first one, with error 0xc0000005, indicates an
> "access violation" [i.e. generic sort of crash]), and the second one with
> HRESULT 0x8007006d = Win32 109 = "the pipe has been ended.", which
basically
> indicates "loss of communication with w3wp.exe" [which could come from a
> crash]).
>
> Thread 24 crashed because it was told to make a function call into a piece
> of memory that didn't contain any functions. So, it's not exactly the
> problem -- it is a symptom -- we need to find either:
> 1. who told the thread to make that call
> 2. who corrupted a piece of memory such that the thread made the bad call
>
> I don't have the time right now, but if you retitle this thread as
"IISState
> Log Analysis Needed" and make the ZIP files available, it would catch
Pat's
> eye if he has time. Otherwise, you'll need to contact Microsoft PSS for
them
> to take a look. If the issue ends up as a Microsoft issue, you won't be
> charged, but otherwise, you will. Realize that with a jump from NT4 to
WS03
> is a period of nearly a decade, and some things may have accidentally
worked
> all this time, or it may be a new bug.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "MS User" <MSUser@NoSpam.Com> wrote in message
> news:WK60e.16$Hj1.13@fe37.usenetserver.com...
> "MS User" <MSUser@NoSpam.Com> wrote in message
> news:jG50e.13$Hj1.0@fe37.usenetserver.com...
> > So now I am going to do a log right before a crash and then a log when
it
> > crashes to see what the thread was doing prior.
>
> Okay I just captured this. Thread 24 was given as the reason for failure.
> About 1 minute before the crash the log said:
> Thread ID: 24
> System Thread ID: c88
> Kernel Time: 0:0:1.265
> User Time: 0:0:9.78
> Thread Status: Thread is in a WAIT state.
> Thread Type: Idle ASP thread
> # ChildEBP RetAddr
> 00 07e0fdcc 77f4372d SharedUserData!SystemCallStub+0x4
> 01 07e0fdd0 77e41bfa ntdll!NtWaitForMultipleObjects+0xc
> 02 07e0fe78 77d076f5 kernel32!WaitForMultipleObjectsEx+0x11a
> 03 07e0fed4 77d077f5 USER32!RealMsgWaitForMultipleObjectsEx+0x13f
> 04 07e0fef0 756342a4 USER32!MsgWaitForMultipleObjects+0x1d
> 05 07e0ff84 77bc91ed comsvcs!CSTAThread::WorkerLoop+0x1e3
> 06 07e0ffb8 77e4a990 msvcrt!_endthreadex+0x95
> 07 07e0ffec 00000000 kernel32!BaseThreadStart+0x34
>
> When it crashed the log said:
> Thread ID: 24
> System Thread ID: c88
> Kernel Time: 0:0:1.265
> User Time: 0:0:9.78
> Thread Type: Idle ASP thread
> # ChildEBP RetAddr
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 00 07e0fda4 77d0612f 0x2217147e
> 01 07e0fdd0 77d069a5 USER32!InternalCallWinProc+0x1b
> 02 07e0fe48 77d06689 USER32!UserCallWinProcCheckWow+0x151
> 03 07e0feb0 77d06704 USER32!DispatchMessageWorker+0x327
> 04 07e0febc 75633854 USER32!DispatchMessageW+0xb
> 05 07e0fed4 756337ad comsvcs!CSTAQueueLessMessageWork::DoWork+0x45
> 06 07e0fee8 75633f71 comsvcs!CSTAThread::DoWork+0x14
> 07 07e0ff04 7563423b comsvcs!CSTAThread::ProcessQueueWork+0x30
> 08 07e0ff84 77bc91ed comsvcs!CSTAThread::WorkerLoop+0x17a
> 09 07e0ffb8 77e4a990 msvcrt!_endthreadex+0x95
> 0a 07e0ffec 00000000 kernel32!BaseThreadStart+0x34
>
> ********
>
> All other parts of the log files were identical except a couple threads
had
> slightly different kernel and user times
> and thread 14 at the crash said:
> Thread ID: 14
> System Thread ID: 244
> Kernel Time: 0:0:0.0
> User Time: 0:0:0.0
> *** WARNING: Unable to verify checksum for C:\WINDOWS\system32\PDM.DLL
> *** ERROR: Symbol file could not be found. Defaulted to export symbols
for
> C:\WINDOWS\system32\PDM.DLL -
> Thread Status: Thread is in a WAIT state.
> Thread Type: PDM (Debugger) Thread.
> # ChildEBP RetAddr
> 00 024efd84 77f4372d SharedUserData!SystemCallStub+0x4
> 01 024efd88 77e41bfa ntdll!NtWaitForMultipleObjects+0xc
> 02 024efe30 77d076f5 kernel32!WaitForMultipleObjectsEx+0x11a
> 03 024efe8c 77d077f5 USER32!RealMsgWaitForMultipleObjectsEx+0x13f
> 04 024efea8 4a00886c USER32!MsgWaitForMultipleObjects+0x1d
> 05 024eff8c 4a008a85 PDM+0x886c
> 06 024effb4 4a008a09 PDM+0x8a85
> 07 024effb8 77e4a990 PDM+0x8a09
> 08 024effec 00000000 kernel32!BaseThreadStart+0x34
>
> Before the crash is said the same as above except the Warning and Error
line
> said:
> *** WARNING: Unable to verify checksum for
> *** ERROR: Symbol file could not be found. Defaulted to export symbols
> or -
>
> I suppose this is just a because of IISState running.
>
>
>
>



Relevant Pages

  • Re: Session Variables Cleared afer Server.Execute
    ... Secondly you need to use the -hc switch with IISState when you run it. ... > System Thread ID: 17c4 ... > Thread Type: Other ... > # ChildEBP RetAddr ...
    (microsoft.public.inetserver.asp.general)
  • Re: Session Variables Cleared afer Server.Execute
    ... Secondly you need to use the -hc switch with IISState when you run it. ... > System Thread ID: 17c4 ... > Thread Type: Other ... > # ChildEBP RetAddr ...
    (microsoft.public.inetserver.iis)
  • Re: IIS Crashes with a WSS event handler
    ... The IISState crash was in managed code that was being cleaned up (i.e. the ... > System Thread ID: 17d8 ... > # ChildEBP RetAddr ... > Thread Type: HTTP Compression Thread ...
    (microsoft.public.inetserver.iis)
  • Re: IISState log
    ... > 90% usage and thats when I seen it and ran iisstate. ... > System Thread ID: ea0 ... > # ChildEBP RetAddr ... > Thread Type: HTTP Compression Thread ...
    (microsoft.public.inetserver.iis)
  • Re: IISState log interpretation
    ... The process is paused while IISState runs. ... > System Thread ID: dfc ... > Thread Type: Other ... > # ChildEBP RetAddr ...
    (microsoft.public.inetserver.iis)