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
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
//
( 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...
"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.