Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

how to use debugdiag report for IIS Application pool crash

484 views
Skip to first unread message

Lynn Zou

unread,
Dec 27, 2006, 4:55:13 PM12/27/06
to
I got the analysis report from the IIS applicationpool crash dump file by
using Debug Diagnotics tool.
But I still can not figure out what is the problem with our ISAPI
application. I appreciate if anyone can
help to analyze what cause the crash happen.
Here are some of the report:

The first error:
In w3wp__PID__41040__Date__12_26_2006__Time_02_35_33PM__940__First chance
exception 0XE06D7363.dmp the assembly instruction at
kernel32!RaiseException+3c in C:\WINDOWS\system32\kernel32.dll from
Microsoft Corporation has caused an unknown exception (0xe06d7363) on thread
23

This exception originated from msvcrt!CxxThrowException+36.

Thread 23 - System ID 51080
Entry point w3tp+1d80
Create time 12/26/2006 9:37:40 AM
Time spent in user mode 0 Days 0:0:16.437
Time spent in kernel mode 0 Days 0:0:43.734


This thread is calling an ISAPI Extension FASD

Function Source
ntdll!KiFastSystemCallRet
msvcrt!mktemp+2bd
msvcrt!sopen+2d
msvcrt!wscanf+dad
msvcrt!fsopen+3a
msvcrt!fopen+12
FasdGen!CFasdGenObj::LogMessage+f1
FASD+72af2
FASD!TerminateExtension+1510
FASD!TerminateExtension+8ca
FASD!TerminateExtension+22b
FASD!HttpExtensionProc+34
w3isapi!ProcessIsapiRequest+100
w3core+68ff
w3core+67e0
w3core+6764
w3core+66f4
w3core+66ae
w3core+6648
w3core+2264
w3core+65ea
w3dt!UlAtqAllocateMemory+16f
w3dt!UlAtqAllocateMemory+19a
w3tp!THREAD_POOL::PostCompletion+c9
w3tp!THREAD_POOL::~THREAD_POOL+153
w3tp+1db9
kernel32!GetModuleFileNameA+eb

the Second error:

In w3wp__PID__41040__Date__12_26_2006__Time_02_35_34PM__877__First chance
exception 0XE06D7363.dmp the assembly instruction at
kernel32!RaiseException+3c in C:\WINDOWS\system32\kernel32.dll from
Microsoft Corporation has caused an unknown exception (0xe06d7363) on thread
19

This exception originated from msvcrt!CxxThrowException+36.

Thread 19 - System ID 47664
Entry point w3tp+1d80
Create time 12/26/2006 1:48:01 AM
Time spent in user mode 0 Days 0:0:29.843
Time spent in kernel mode 0 Days 0:1:15.312


This thread is calling an ISAPI Extension FASD

Function Source
kernel32!RaiseException+3c
msvcrt!CxxThrowException+36
FASD+87362
FASD+8733a
FASD+227e
FASD+72af2
FASD!TerminateExtension+1510
FASD!TerminateExtension+8ca
FASD!TerminateExtension+22b
FASD!HttpExtensionProc+34
w3isapi!ProcessIsapiRequest+100
w3core+68ff
w3core+67e0
w3core+6764
w3core+66f4
w3core+66ae
w3core+6648
w3core+2264
w3core+65ea
w3dt!UlAtqAllocateMemory+16f
w3dt!UlAtqAllocateMemory+19a
w3tp!THREAD_POOL::PostCompletion+c9
w3tp!THREAD_POOL::~THREAD_POOL+153
w3tp+1db9
kernel32!GetModuleFileNameA+eb


The third error:

WARNING - DebugDiag was not able to locate debug symbols for ntdll.dll, so
the information below may be incomplete.

In
w3wp__PID__41040__Date__12_26_2006__Time_05_35_03PM__582__Second_Chance_Exce
ption_C0000005.dmp the assembly instruction at
ntdll!RtlEnterCriticalSection+19 in C:\WINDOWS\system32\ntdll.dll from
Microsoft Corporation has caused an access violation exception (0xC0000005)
when trying to write to memory location 0x0000000f on thread 22

Thread 29 - System ID 50948
Entry point w3tp+1d80
Create time 12/26/2006 2:35:31 PM
Time spent in user mode 0 Days 0:0:0.15
Time spent in kernel mode 0 Days 0:0:0.0


This thread is not fully resolved and may or may not be a problem. Further
analysis of these threads may be required.

Function Source
ntdll!KiFastSystemCallRet
w3tp!THREAD_POOL::PostCompletion+89
w3tp!THREAD_POOL::~THREAD_POOL+153
w3tp+1db9
kernel32!GetModuleFileNameA+eb


David Wang

unread,
Dec 27, 2006, 6:15:20 PM12/27/06
to
You'll need to setup DebugDiag with symbols for your ISAPI as well as
Microsoft (free online access) to get a more useful crash log.

Error analysis:
1. Code inside C++ class CFasdGenObj::LogMessage in FasdGen.dll
crashed. Looks like it failed to handle File IO correctly.
2. Need symbols for FASD.dll to know line number of error
3. Some code is trying to use a deleted critical section. Need symbols
to look up which thread owns the critical section and then the stack of
the offender to progress.

DebugDiag is good aid to determine which code is responsible for the
crash. For real analysis/debugging, you still need to use a debugger.

//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Lynn Zou

unread,
Dec 28, 2006, 5:43:25 PM12/28/06
to
Thanks for the reply.
Part of the report in my last post is based on the symbols from Microsoft
server.
Now I got new report after I add the symbols for our own application.
However, the report still says
that DebugDiag was not able to locate debug symbols for ole32.dll ,
ntdll.dll and comsvcs.dll, but I found
the pdbs for the three dlls is in the symbol folder. Can anyone tell me why
debug diag analysis can not find the
symbols for these dlls?
Besides the error items in the report, I also get information items, for
example:
===========================
The following threads in
w3wp__PID__41040__Date__12_26_2006__Time_02_35_33PM__940__First chance
exception 0XE06D7363.dmp are making a database operation using ADO. The call
to ADO originated from FASD!CFASDExtension::~CFASDExtension+38

( 3 4 5 19 )

13.33% of threads blocked
===========================
What does this information tell? what does "thread blocked" mean?

I appreciate for the help.

Lynn


"David Wang" <w3....@gmail.com> wrote in message
news:1167261320....@79g2000cws.googlegroups.com...

David Wang

unread,
Dec 29, 2006, 12:54:37 PM12/29/06
to
I don't know what "Symbols folder" you are referencing, but if you told
DebugDiag to use it and the report still says DebugDiag was not able to
locate debug symbols, then it means the PDB does not match the DLL. It
doesn't mean the PDB is bad; it just means it does not match your
specific DLL versions and hence useless. It is a problem for you to
correct, by first locating the correct PDB and then telling DebugDiag
use it.

"thread blocked" means exactly what it says. The destructor of the
CFASDExtension class makes ADO database calls that are blocked waiting
on network. It sounds like the CFASDExtension is constantly
created/destroyed, hence lots of threads executing ISAPI Extensions are
stuck waiting on the database network call. Having blocked threads is
usually an indication of flawed software design. Maybe the object
should not be created/destroyed as often. Maybe the object should not
make database calls on creation/deletion.

Based on what I have seen, it seems like the ISAPI Extension has some
serious design flaws and implementation bugs. You need to hire someone
to fix it.

0 new messages