RE: IIS Consuming 100% CPU

RE: IIS Consuming 100% CPU

am 03.12.2007 17:52:04 von EricHertlein

"Eric Hertlein" wrote:

> I think this is offending thread:
>

... snip..

> I am not sure where to go from here. It doesn't even look as though this is
> a page being processed. I don't see any ASP calls. Any suggestions?

Acutally loading the dump into WinDbg gave me the following thread as the
offender:

ERROR_CODE: (NTSTATUS) 0x80000007 - {Kernel Debugger Awakened} the system
debugger was awakened by an interrupt.

DERIVED_WAIT_CHAIN:

Dl Eid Cid WaitType
-- --- ------- --------------------------
26 568.408 Unknown

WAIT_CHAIN_COMMAND: ~26s;k;;

BLOCKING_THREAD: 00000408

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_BusyHang

LAST_CONTROL_TRANSFER: from 7c817c9a to 7c82ccb7

FAULTING_THREAD: 0000001a

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
0628b0a8 7c817c9a 0628b0e0 00073674 00000000 ntdll!bsearch+0x37
0628b100 7c817bde 000734e8 03f75218 0628b164
ntdll!RtlFindActivationContextSectionGuid+0x161
0628b140 77e6016c 00000001 00000000 000734e8
ntdll!RtlFindActivationContextSectionGuid+0xa5
0628b1a8 776a8578 00000001 00000000 00000004
kernel32!FindActCtxSectionGuid+0x49
0628b20c 776a8aa9 00094bb8 00000000 03f75218
ole32!CComSxSCatalog::GetClassInfoW+0x25
0628b288 776a8a14 77794a74 00000017 00000000
ole32!CComCatalog::GetClassInfoInternal+0x9c
0628b2ac 776a89bd 77794a78 00000017 00000000
ole32!CComCatalog::GetClassInfoW+0x22
0628b2cc 776a8947 03f75218 0628b2e8 00000000 ole32!GetClassInfoFromClsid+0x2d
0628b2ec 776a6852 03f75218 0628b3c0 00000000 ole32!LookForConfiguredClsid+0x33
0628b3d4 776a679a 03f75218 00000000 00000005 ole32!ICoCreateInstanceEx+0x135
0628b408 776a6762 03f75218 00000000 00000000
ole32!CComActivator::DoCreateInstance+0x6a
0628b42c 73653937 03f75218 00000000 00000005 ole32!CoCreateInstanceEx+0x23
0628b49c 73649c9d 03f75130 0628b4dc 0628b4b4 msvbvm60!_vbaBoolErrVar+0x29fd
0628b4d4 0400308e 00000000 0628b5b8 0628b6c8 msvbvm60!_vbaNew+0x21
0628b5a4 03fbf93c 0551da60 0628b6c8 0628b6fc CAM!DllCanUnloadNow+0x7598c
0628b730 03fba4d0 05e9cf70 0628b7d0 0628b804 CAM!DllCanUnloadNow+0x3223a
0628b848 03fb94a1 0513edc0 0628b924 0628b904 CAM!DllCanUnloadNow+0x2cdce
0628b940 03fb8691 0513edc0 0628b998 08507e2f CAM!DllCanUnloadNow+0x2bd9f
0628b9bc 04c0e5bf 0513edc0 0628baa4 0628ba8c CAM!DllCanUnloadNow+0x2af8f
0628bac4 04c0ef45 04f6ce78 08507e2f 08598bef
IStarDataSources!DllCanUnloadNow+0xbfc15
0628bb10 048d2b94 04f6ce78 04ae861c 049277d8
IStarDataSources!DllCanUnloadNow+0xc059b
0628d4d8 048cff95 08507e2f 08598bef 00012d2f
ISTemplates!DllUnregisterServer+0xd409
0628d510 048d53f5 0628f280 058951e0 11073e4c
ISTemplates!DllUnregisterServer+0xa80a
0628e268 048d8a29 0628e278 049277d8 646f7270
ISTemplates!DllUnregisterServer+0xfc6a
0628e738 110494f8 084dcc34 05aca37c 049277d8
ISTemplates!DllUnregisterServer+0x1329e
0628e97c 77d05186 05465460 05895188 05895198 istar21!DllCanUnloadNow+0x1e72e
0628e9ac 73646a6f 05465460 00000030 00000004 oleaut32!DispCallFunc+0xab
0628f308 7363a0d4 05465460 11009ad4 60030005 msvbvm60!_vbaAptOffset+0x68b
0628f364 7347d3cb 05465460 60030005 734614f4 msvbvm60!BASIC_CLASS_Invoke+0x65
0628f3b8 73468ad1 088fe268 05465460 60030005
vbscript!CatchIDispatchInvoke+0x46
0628f3f8 73468a40 088915c8 05465460 60030005 vbscript!IDispatchInvoke2+0xaf
0628f434 734689f2 088915c8 05465460 60030005 vbscript!IDispatchInvoke+0x59
0628f548 7346613b 088915c8 05465460 60030005 vbscript!InvokeDispatch+0x13a
0628f56c 73466f6c 088915c8 05465460 60030005 vbscript!InvokeByName+0x42
0628f848 734633e0 00000000 00000000 088915c8
vbscript!CScriptRuntime::Run+0x262b
0628f940 734637d1 00000000 00000000 00000000
vbscript!CScriptEntryPoint::Call+0x5c
0628f998 73463b9c 0898b9a0 00000000 00000000 vbscript!CSession::Execute+0xb4
0628f9e8 73461849 00000000 00000000 709e19c0
vbscript!COleScript::ExecutePendingScripts+0x13e
0628fa04 709e2ada 03326528 03326528 02c22f70
vbscript!COleScript::SetScriptState+0x150
0628fa30 709e2a9c 00000000 709e19c0 0628fb38
asp!CActiveScriptEngine::TryCall+0x19
0628fa6c 709e26d0 00000000 6472474e 02f21f28
asp!CActiveScriptEngine::Call+0x31
0628fa88 709e25d4 0628fb0c 00000000 00000000
asp!CallScriptFunctionOfEngine+0x5b
0628fadc 709e24ff 03421e90 00000000 0628fb68 asp!ExecuteRequest+0x17e
0628fb44 709e23f7 03421e90 02f21f28 0628fb68 asp!Execute+0x249
0628fb98 709e2753 00000000 00000000 059d2fa0
asp!CHitObj::ViperAsyncCallback+0x3f3
0628fbb4 4a77b5ea 02fa26b0 0008c398 0628fd74
asp!CViperAsyncRequest::OnCall+0x92
0628fbd0 77720d30 059d2fa0 000e8450 00000000 comsvcs!CoCreateActivity+0x4b28
0628fc1c 777217dc 00000000 000e8450 4a77b5b8 ole32!EnterForCallback+0xc4
0628fd7c 776f03b4 0628fc54 4a77b5b8 059d2fa0 ole32!SwitchForCallback+0x1a3
0628fda8 7769c194 000e8450 4a77b5b8 059d2fa0 ole32!PerformCallback+0x54
0628fe40 7772433a 0008c398 4a77b5b8 059d2fa0
ole32!CObjectContext::InternalContextCallback+0x159
0628fe60 4a77b78c 0008c398 4a77b5b8 059d2fa0
ole32!CObjectContext::DoCallback+0x1c
0628fecc 4a77bcf2 04f340b8 04f34098 053f8bbc comsvcs!CoCreateActivity+0x4cca
0628fee4 4a77c7de 059d2fa0 00000001 04f34098 comsvcs!DllUnregisterServer+0x180
0628ff04 4a77cabf 00000000 01be57d8 01bddec8 comsvcs!DllUnregisterServer+0xc6c
0628ff84 77bcb530 04f34098 00000000 00000000 comsvcs!DllUnregisterServer+0xf4d
0628ffb8 77e64829 01bddec8 00000000 00000000 msvcrt!_endthreadex+0xa3
0628ffec 00000000 77bcb4bc 01bddec8 00000000 kernel32!GetModuleHandleA+0xdf


FOLLOWUP_IP:
msvbvm60!_vbaNew+21
73649c9d 8d4de0 lea ecx,[ebp-20h]

SYMBOL_STACK_INDEX: d

SYMBOL_NAME: msvbvm60!_vbaNew+21

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: msvbvm60

IMAGE_NAME: msvbvm60.dll

STACK_COMMAND: ~26s ; kb

BUCKET_ID: WRONG_SYMBOLS

FAILURE_BUCKET_ID:
msvbvm60.dll!base_address_80000007_APPLICATION_HANG_BusyHang

Followup: MachineOwner
---------


I am unsure as to how to proceed to determine what the parameters are on
this stack trace. If I could figure that out I would be a lot closer to
determining the issue.

Eric

Re: IIS Consuming 100% CPU

am 03.12.2007 19:36:31 von patfilot

It is a bit tricky. Before I go into the full analysis, a few observations:

1) You are missing the system symbols (and the VB COM symbols), so there is
a fairly chance that the thread is not 100% accurately represented.
2) The best we can do in this case is to give a general idea of what is
happening

But you read threads from the bottom to the top.

Chunk1:
> 0628fbd0 77720d30 059d2fa0 000e8450 00000000
> comsvcs!CoCreateActivity+0x4b28
> 0628fc1c 777217dc 00000000 000e8450 4a77b5b8 ole32!EnterForCallback+0xc4
> 0628fd7c 776f03b4 0628fc54 4a77b5b8 059d2fa0 ole32!SwitchForCallback+0x1a3
> 0628fda8 7769c194 000e8450 4a77b5b8 059d2fa0 ole32!PerformCallback+0x54
> 0628fe40 7772433a 0008c398 4a77b5b8 059d2fa0
> ole32!CObjectContext::InternalContextCallback+0x159
> 0628fe60 4a77b78c 0008c398 4a77b5b8 059d2fa0
> ole32!CObjectContext::DoCallback+0x1c
> 0628fecc 4a77bcf2 04f340b8 04f34098 053f8bbc
> comsvcs!CoCreateActivity+0x4cca
> 0628fee4 4a77c7de 059d2fa0 00000001 04f34098
> comsvcs!DllUnregisterServer+0x180
> 0628ff04 4a77cabf 00000000 01be57d8 01bddec8
> comsvcs!DllUnregisterServer+0xc6c
> 0628ff84 77bcb530 04f34098 00000000 00000000
> comsvcs!DllUnregisterServer+0xf4d
> 0628ffb8 77e64829 01bddec8 00000000 00000000 msvcrt!_endthreadex+0xa3
> 0628ffec 00000000 77bcb4bc 01bddec8 00000000
> kernel32!GetModuleHandleA+0xdf

This is basically just the plumbing for an ASP thread. The bottom 2 calls
are definitely wrong, but basically you can ignore this piece.

Chunk 2:
> asp!CActiveScriptEngine::TryCall+0x19
> 0628fa6c 709e26d0 00000000 6472474e 02f21f28
> asp!CActiveScriptEngine::Call+0x31
> 0628fa88 709e25d4 0628fb0c 00000000 00000000
> asp!CallScriptFunctionOfEngine+0x5b
> 0628fadc 709e24ff 03421e90 00000000 0628fb68 asp!ExecuteRequest+0x17e
> 0628fb44 709e23f7 03421e90 02f21f28 0628fb68 asp!Execute+0x249
> 0628fb98 709e2753 00000000 00000000 059d2fa0
> asp!CHitObj::ViperAsyncCallback+0x3f3
> 0628fbb4 4a77b5ea 02fa26b0 0008c398 0628fd74
> asp!CViperAsyncRequest::OnCall+0x92

This is the ASP engine initializing for the request. Again, not a lot of
interesting bits here in terms of troubleshooting, but being able to
recognize plumbing vs potential code problems may help in the future.

Chunk 3 (starting to get to the interesting bits):
> 0628f3b8 73468ad1 088fe268 05465460 60030005
> vbscript!CatchIDispatchInvoke+0x46
> 0628f3f8 73468a40 088915c8 05465460 60030005
> vbscript!IDispatchInvoke2+0xaf
> 0628f434 734689f2 088915c8 05465460 60030005 vbscript!IDispatchInvoke+0x59
> 0628f548 7346613b 088915c8 05465460 60030005 vbscript!InvokeDispatch+0x13a
> 0628f56c 73466f6c 088915c8 05465460 60030005 vbscript!InvokeByName+0x42
> 0628f848 734633e0 00000000 00000000 088915c8
> vbscript!CScriptRuntime::Run+0x262b
> 0628f940 734637d1 00000000 00000000 00000000
> vbscript!CScriptEntryPoint::Call+0x5c
> 0628f998 73463b9c 0898b9a0 00000000 00000000
> vbscript!CSession::Execute+0xb4
> 0628f9e8 73461849 00000000 00000000 709e19c0
> vbscript!COleScript::ExecutePendingScripts+0x13e
> 0628fa04 709e2ada 03326528 03326528 02c22f70
> vbscript!COleScript::SetScriptState+0x150

This is your ASP script (.asp file & templates) running. The function names
are all wrong, but the DLL name is correct (format =
DLLName!FunctionName+HexOffset, large offsets or repeating function names
are a big hint that symbols are wrong). So far, so good.

Chunk 4
> 0628e97c 77d05186 05465460 05895188 05895198
> istar21!DllCanUnloadNow+0x1e72e
> 0628e9ac 73646a6f 05465460 00000030 00000004 oleaut32!DispCallFunc+0xab
> 0628f308 7363a0d4 05465460 11009ad4 60030005 msvbvm60!_vbaAptOffset+0x68b
> 0628f364 7347d3cb 05465460 60030005 734614f4
> msvbvm60!BASIC_CLASS_Invoke+0x65

The execution has now left VBScript and moved into the COM DLLs. VB run
time (MSVBVM60) always loads before the execution of the VB COM object, so
istar21.dll is a VB dll. The function name is wrong (it isn't trying to
unload, you can see by the _huge_ offset). If you have access to the
project, you can build symbols by checking the box in the build options
(creates a .pdb file of the same name, put it in the directory w/the dll or
place it where WinDBG can find it).

Chunk 5
> ISTemplates!DllUnregisterServer+0xd409
> 0628d510 048d53f5 0628f280 058951e0 11073e4c
> ISTemplates!DllUnregisterServer+0xa80a
> 0628e268 048d8a29 0628e278 049277d8 646f7270
> ISTemplates!DllUnregisterServer+0xfc6a
> 0628e738 110494f8 084dcc34 05aca37c 049277d8
> ISTemplates!DllUnregisterServer+0x1329e

ISTemplates.dll was called directly from the istar.dll.

Chunk 6:
0628bac4 04c0ef45 04f6ce78 08507e2f 08598bef
IStarDataSources!DllCanUnloadNow+0xbfc15
0628bb10 048d2b94 04f6ce78 04ae861c 049277d8
IStarDataSources!DllCanUnloadNow+0xc059b

IStartDataSources called directly from ISTemplates.dll.

Chunk 7 (getting close)
0628b5a4 03fbf93c 0551da60 0628b6c8 0628b6fc CAM!DllCanUnloadNow+0x7598c
0628b730 03fba4d0 05e9cf70 0628b7d0 0628b804 CAM!DllCanUnloadNow+0x3223a
0628b848 03fb94a1 0513edc0 0628b924 0628b904 CAM!DllCanUnloadNow+0x2cdce
0628b940 03fb8691 0513edc0 0628b998 08507e2f CAM!DllCanUnloadNow+0x2bd9f
0628b9bc 04c0e5bf 0513edc0 0628baa4 0628ba8c CAM!DllCanUnloadNow+0x2af8f

CAM.dll is called directly from IStartDataSources. This is where things
look to get a bit flaky. This DLL then starts making a call into the
runtime, and then into the system. Not really sure what exactly it is doing
(lacking symbols), but this is most likely the area that is causing a
problem for you. If you can get symbols for the dll, then you can see the
class & line number and trace the code yourself. Otherwise you can try
placing CAM.dll into a COM+ Server package, which will isolate it into a
different process, and see if the high CPU 'follows'.



Pat


"Eric Hertlein" wrote in message
news:3EA81EC9-5D76-447B-A401-C4A23EF87374@microsoft.com...
>
>
> "Eric Hertlein" wrote:
>
>> I think this is offending thread:
>>
>
> .. snip..
>
>> I am not sure where to go from here. It doesn't even look as though this
>> is
>> a page being processed. I don't see any ASP calls. Any suggestions?
>
> Acutally loading the dump into WinDbg gave me the following thread as the
> offender:
>
> ERROR_CODE: (NTSTATUS) 0x80000007 - {Kernel Debugger Awakened} the system
> debugger was awakened by an interrupt.
>
> DERIVED_WAIT_CHAIN:
>
> Dl Eid Cid WaitType
> -- --- ------- --------------------------
> 26 568.408 Unknown
>
> WAIT_CHAIN_COMMAND: ~26s;k;;
>
> BLOCKING_THREAD: 00000408
>
> DEFAULT_BUCKET_ID: WRONG_SYMBOLS
>
> PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_BusyHang
>
> LAST_CONTROL_TRANSFER: from 7c817c9a to 7c82ccb7
>
> FAULTING_THREAD: 0000001a
>
> STACK_TEXT:
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> 0628b0a8 7c817c9a 0628b0e0 00073674 00000000 ntdll!bsearch+0x37
> 0628b100 7c817bde 000734e8 03f75218 0628b164
> ntdll!RtlFindActivationContextSectionGuid+0x161
> 0628b140 77e6016c 00000001 00000000 000734e8
> ntdll!RtlFindActivationContextSectionGuid+0xa5
> 0628b1a8 776a8578 00000001 00000000 00000004
> kernel32!FindActCtxSectionGuid+0x49
> 0628b20c 776a8aa9 00094bb8 00000000 03f75218
> ole32!CComSxSCatalog::GetClassInfoW+0x25
> 0628b288 776a8a14 77794a74 00000017 00000000
> ole32!CComCatalog::GetClassInfoInternal+0x9c
> 0628b2ac 776a89bd 77794a78 00000017 00000000
> ole32!CComCatalog::GetClassInfoW+0x22
> 0628b2cc 776a8947 03f75218 0628b2e8 00000000
> ole32!GetClassInfoFromClsid+0x2d
> 0628b2ec 776a6852 03f75218 0628b3c0 00000000
> ole32!LookForConfiguredClsid+0x33
> 0628b3d4 776a679a 03f75218 00000000 00000005
> ole32!ICoCreateInstanceEx+0x135
> 0628b408 776a6762 03f75218 00000000 00000000
> ole32!CComActivator::DoCreateInstance+0x6a
> 0628b42c 73653937 03f75218 00000000 00000005 ole32!CoCreateInstanceEx+0x23
> 0628b49c 73649c9d 03f75130 0628b4dc 0628b4b4
> msvbvm60!_vbaBoolErrVar+0x29fd
> 0628b4d4 0400308e 00000000 0628b5b8 0628b6c8 msvbvm60!_vbaNew+0x21
> 0628b5a4 03fbf93c 0551da60 0628b6c8 0628b6fc CAM!DllCanUnloadNow+0x7598c
> 0628b730 03fba4d0 05e9cf70 0628b7d0 0628b804 CAM!DllCanUnloadNow+0x3223a
> 0628b848 03fb94a1 0513edc0 0628b924 0628b904 CAM!DllCanUnloadNow+0x2cdce
> 0628b940 03fb8691 0513edc0 0628b998 08507e2f CAM!DllCanUnloadNow+0x2bd9f
> 0628b9bc 04c0e5bf 0513edc0 0628baa4 0628ba8c CAM!DllCanUnloadNow+0x2af8f
> 0628bac4 04c0ef45 04f6ce78 08507e2f 08598bef
> IStarDataSources!DllCanUnloadNow+0xbfc15
> 0628bb10 048d2b94 04f6ce78 04ae861c 049277d8
> IStarDataSources!DllCanUnloadNow+0xc059b
> 0628d4d8 048cff95 08507e2f 08598bef 00012d2f
> ISTemplates!DllUnregisterServer+0xd409
> 0628d510 048d53f5 0628f280 058951e0 11073e4c
> ISTemplates!DllUnregisterServer+0xa80a
> 0628e268 048d8a29 0628e278 049277d8 646f7270
> ISTemplates!DllUnregisterServer+0xfc6a
> 0628e738 110494f8 084dcc34 05aca37c 049277d8
> ISTemplates!DllUnregisterServer+0x1329e
> 0628e97c 77d05186 05465460 05895188 05895198
> istar21!DllCanUnloadNow+0x1e72e
> 0628e9ac 73646a6f 05465460 00000030 00000004 oleaut32!DispCallFunc+0xab
> 0628f308 7363a0d4 05465460 11009ad4 60030005 msvbvm60!_vbaAptOffset+0x68b
> 0628f364 7347d3cb 05465460 60030005 734614f4
> msvbvm60!BASIC_CLASS_Invoke+0x65
> 0628f3b8 73468ad1 088fe268 05465460 60030005
> vbscript!CatchIDispatchInvoke+0x46
> 0628f3f8 73468a40 088915c8 05465460 60030005
> vbscript!IDispatchInvoke2+0xaf
> 0628f434 734689f2 088915c8 05465460 60030005 vbscript!IDispatchInvoke+0x59
> 0628f548 7346613b 088915c8 05465460 60030005 vbscript!InvokeDispatch+0x13a
> 0628f56c 73466f6c 088915c8 05465460 60030005 vbscript!InvokeByName+0x42
> 0628f848 734633e0 00000000 00000000 088915c8
> vbscript!CScriptRuntime::Run+0x262b
> 0628f940 734637d1 00000000 00000000 00000000
> vbscript!CScriptEntryPoint::Call+0x5c
> 0628f998 73463b9c 0898b9a0 00000000 00000000
> vbscript!CSession::Execute+0xb4
> 0628f9e8 73461849 00000000 00000000 709e19c0
> vbscript!COleScript::ExecutePendingScripts+0x13e
> 0628fa04 709e2ada 03326528 03326528 02c22f70
> vbscript!COleScript::SetScriptState+0x150
> 0628fa30 709e2a9c 00000000 709e19c0 0628fb38
> asp!CActiveScriptEngine::TryCall+0x19
> 0628fa6c 709e26d0 00000000 6472474e 02f21f28
> asp!CActiveScriptEngine::Call+0x31
> 0628fa88 709e25d4 0628fb0c 00000000 00000000
> asp!CallScriptFunctionOfEngine+0x5b
> 0628fadc 709e24ff 03421e90 00000000 0628fb68 asp!ExecuteRequest+0x17e
> 0628fb44 709e23f7 03421e90 02f21f28 0628fb68 asp!Execute+0x249
> 0628fb98 709e2753 00000000 00000000 059d2fa0
> asp!CHitObj::ViperAsyncCallback+0x3f3
> 0628fbb4 4a77b5ea 02fa26b0 0008c398 0628fd74
> asp!CViperAsyncRequest::OnCall+0x92
> 0628fbd0 77720d30 059d2fa0 000e8450 00000000
> comsvcs!CoCreateActivity+0x4b28
> 0628fc1c 777217dc 00000000 000e8450 4a77b5b8 ole32!EnterForCallback+0xc4
> 0628fd7c 776f03b4 0628fc54 4a77b5b8 059d2fa0 ole32!SwitchForCallback+0x1a3
> 0628fda8 7769c194 000e8450 4a77b5b8 059d2fa0 ole32!PerformCallback+0x54
> 0628fe40 7772433a 0008c398 4a77b5b8 059d2fa0
> ole32!CObjectContext::InternalContextCallback+0x159
> 0628fe60 4a77b78c 0008c398 4a77b5b8 059d2fa0
> ole32!CObjectContext::DoCallback+0x1c
> 0628fecc 4a77bcf2 04f340b8 04f34098 053f8bbc
> comsvcs!CoCreateActivity+0x4cca
> 0628fee4 4a77c7de 059d2fa0 00000001 04f34098
> comsvcs!DllUnregisterServer+0x180
> 0628ff04 4a77cabf 00000000 01be57d8 01bddec8
> comsvcs!DllUnregisterServer+0xc6c
> 0628ff84 77bcb530 04f34098 00000000 00000000
> comsvcs!DllUnregisterServer+0xf4d
> 0628ffb8 77e64829 01bddec8 00000000 00000000 msvcrt!_endthreadex+0xa3
> 0628ffec 00000000 77bcb4bc 01bddec8 00000000
> kernel32!GetModuleHandleA+0xdf
>
>
> FOLLOWUP_IP:
> msvbvm60!_vbaNew+21
> 73649c9d 8d4de0 lea ecx,[ebp-20h]
>
> SYMBOL_STACK_INDEX: d
>
> SYMBOL_NAME: msvbvm60!_vbaNew+21
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: msvbvm60
>
> IMAGE_NAME: msvbvm60.dll
>
> STACK_COMMAND: ~26s ; kb
>
> BUCKET_ID: WRONG_SYMBOLS
>
> FAILURE_BUCKET_ID:
> msvbvm60.dll!base_address_80000007_APPLICATION_HANG_BusyHang
>
> Followup: MachineOwner
> ---------
>
>
> I am unsure as to how to proceed to determine what the parameters are on
> this stack trace. If I could figure that out I would be a lot closer to
> determining the issue.
>
> Eric
>

Re: IIS Consuming 100% CPU

am 04.12.2007 21:15:00 von EricHertlein

Thank you very much. I feel like I am making some progress. It took me awhile
but I got the symbol path set correctly in WinDbg and am moving forward.

Here is what the dumps are looking like now:

ChildEBP RetAddr Args to Child
0559b238 7c826deb 77e649f7 0559b2e0 80100080 ntdll!KiFastSystemCallRet
0559b23c 77e649f7 0559b2e0 80100080 0559b27c ntdll!ZwCreateFile+0xc
0559b2d8 77e41a8a 00000000 80000000 00000003 kernel32!CreateFileW+0x377
0559b2fc 7365c6d7 0559b378 80000000 00000003 kernel32!CreateFileA+0x30
0559b340 7364620a 0559b378 00008000 00000040 msvbvm60!_ld12cvt+0xb7
0559b354 73643b1e 0559b378 00008000 00000040 msvbvm60!rtcBstrFromChar+0x34
0559b3ac 77d466d5 00000015 00000002 0559b3f4 msvbvm60!VBAErr::put_Number+0x4
0559b3c4 0014f678 0559b3e0 776bd000 00080000 oleaut32!CbSysStringSize+0x48
WARNING: Frame IP not in any known module. Following frames may be wrong.
0559b3e0 77d04141 77796784 04ba5e28 0014f678 0x14f678
0559b400 77d04113 00000003 00000010 0559b578
oleaut32!APP_DATA::FreeCachedMem+0x30
0559b41c 736560c0 04ba5e2c 00000000 043d4113 oleaut32!SysFreeString+0x6b
0559b560 0438372b 0559b94c 0559b908 0559b904 msvbvm60!_fassign+0x50
0559b564 0559b94c 0559b908 0559b904 00000000
IStarDataSources!ProductListing::OutputProductVars+0x3b8b
[E:\projects\iStar\branches\4.7.1.5\iStarDataSources\Classes \ProductListing.cls @ 466]
0559b568 0559b908 0559b904 00000000 07742ecd 0x559b94c
0559b98c 0437baa7 047ba630 0559b9b0 07742ecd 0x559b908
0559b9d4 04311588 047ba630 07742ecd 05549509
IStarDataSources!ProductListing::OutputVariables+0x70
[E:\projects\iStar\branches\4.7.1.5\iStarDataSources\Classes \ProductListing.cls @ 60]
*** WARNING: Unable to verify checksum for ISTemplates.dll
0559bb18 04112b94 045e0680 042ded24 0429bf00
IStarDataSources!BrowseProducts::IStarDataSource_Execute+0xb 5d
[E:\projects\iStar\branches\4.7.1.5\iStarDataSources\Classes \BrowseProducts.cls @ 179]
0559d4e0 0410ff95 07742ecd 05549509 0000eec5
ISTemplates!CTemplateRuntime::Data+0x518
[E:\projects\iStar\branches\4.7.1.5\ISTemplates\TemplateRunt ime.cpp @ 1092]
0559d518 041153f5 0559f280 06fd7b10 11073e4c
ISTemplates!CTemplateRuntime::Run+0x101
[E:\projects\iStar\branches\4.7.1.5\ISTemplates\TemplateRunt ime.cpp @ 122]
0559e270 04118a29 0559e280 0429bf00 776f7262
ISTemplates!CTemplates::ProcessTemplate+0x42b
[E:\projects\iStar\branches\4.7.1.5\ISTemplates\Templates.cp p @ 133]



If this is the wrong place to ask this question please let me know...

I am looking at these dumps that I have with WinDbg... is there some way for
me to tell the user time these threads are using/have used? That would help
me determine which ones are stuck.

Eric


"Pat [MSFT]" wrote:

> It is a bit tricky. Before I go into the full analysis, a few observations:
>
> 1) You are missing the system symbols (and the VB COM symbols), so there is
> a fairly chance that the thread is not 100% accurately represented.
> 2) The best we can do in this case is to give a general idea of what is
> happening
>
> But you read threads from the bottom to the top.
>
> Chunk1:
> > 0628fbd0 77720d30 059d2fa0 000e8450 00000000
> > comsvcs!CoCreateActivity+0x4b28
> > 0628fc1c 777217dc 00000000 000e8450 4a77b5b8 ole32!EnterForCallback+0xc4
> > 0628fd7c 776f03b4 0628fc54 4a77b5b8 059d2fa0 ole32!SwitchForCallback+0x1a3
> > 0628fda8 7769c194 000e8450 4a77b5b8 059d2fa0 ole32!PerformCallback+0x54
> > 0628fe40 7772433a 0008c398 4a77b5b8 059d2fa0
> > ole32!CObjectContext::InternalContextCallback+0x159
> > 0628fe60 4a77b78c 0008c398 4a77b5b8 059d2fa0
> > ole32!CObjectContext::DoCallback+0x1c
> > 0628fecc 4a77bcf2 04f340b8 04f34098 053f8bbc
> > comsvcs!CoCreateActivity+0x4cca
> > 0628fee4 4a77c7de 059d2fa0 00000001 04f34098
> > comsvcs!DllUnregisterServer+0x180
> > 0628ff04 4a77cabf 00000000 01be57d8 01bddec8
> > comsvcs!DllUnregisterServer+0xc6c
> > 0628ff84 77bcb530 04f34098 00000000 00000000
> > comsvcs!DllUnregisterServer+0xf4d
> > 0628ffb8 77e64829 01bddec8 00000000 00000000 msvcrt!_endthreadex+0xa3
> > 0628ffec 00000000 77bcb4bc 01bddec8 00000000
> > kernel32!GetModuleHandleA+0xdf
>
> This is basically just the plumbing for an ASP thread. The bottom 2 calls
> are definitely wrong, but basically you can ignore this piece.
>
> Chunk 2:
> > asp!CActiveScriptEngine::TryCall+0x19
> > 0628fa6c 709e26d0 00000000 6472474e 02f21f28
> > asp!CActiveScriptEngine::Call+0x31
> > 0628fa88 709e25d4 0628fb0c 00000000 00000000
> > asp!CallScriptFunctionOfEngine+0x5b
> > 0628fadc 709e24ff 03421e90 00000000 0628fb68 asp!ExecuteRequest+0x17e
> > 0628fb44 709e23f7 03421e90 02f21f28 0628fb68 asp!Execute+0x249
> > 0628fb98 709e2753 00000000 00000000 059d2fa0
> > asp!CHitObj::ViperAsyncCallback+0x3f3
> > 0628fbb4 4a77b5ea 02fa26b0 0008c398 0628fd74
> > asp!CViperAsyncRequest::OnCall+0x92
>
> This is the ASP engine initializing for the request. Again, not a lot of
> interesting bits here in terms of troubleshooting, but being able to
> recognize plumbing vs potential code problems may help in the future.
>
> Chunk 3 (starting to get to the interesting bits):
> > 0628f3b8 73468ad1 088fe268 05465460 60030005
> > vbscript!CatchIDispatchInvoke+0x46
> > 0628f3f8 73468a40 088915c8 05465460 60030005
> > vbscript!IDispatchInvoke2+0xaf
> > 0628f434 734689f2 088915c8 05465460 60030005 vbscript!IDispatchInvoke+0x59
> > 0628f548 7346613b 088915c8 05465460 60030005 vbscript!InvokeDispatch+0x13a
> > 0628f56c 73466f6c 088915c8 05465460 60030005 vbscript!InvokeByName+0x42
> > 0628f848 734633e0 00000000 00000000 088915c8
> > vbscript!CScriptRuntime::Run+0x262b
> > 0628f940 734637d1 00000000 00000000 00000000
> > vbscript!CScriptEntryPoint::Call+0x5c
> > 0628f998 73463b9c 0898b9a0 00000000 00000000
> > vbscript!CSession::Execute+0xb4
> > 0628f9e8 73461849 00000000 00000000 709e19c0
> > vbscript!COleScript::ExecutePendingScripts+0x13e
> > 0628fa04 709e2ada 03326528 03326528 02c22f70
> > vbscript!COleScript::SetScriptState+0x150
>
> This is your ASP script (.asp file & templates) running. The function names
> are all wrong, but the DLL name is correct (format =
> DLLName!FunctionName+HexOffset, large offsets or repeating function names
> are a big hint that symbols are wrong). So far, so good.
>
> Chunk 4
> > 0628e97c 77d05186 05465460 05895188 05895198
> > istar21!DllCanUnloadNow+0x1e72e
> > 0628e9ac 73646a6f 05465460 00000030 00000004 oleaut32!DispCallFunc+0xab
> > 0628f308 7363a0d4 05465460 11009ad4 60030005 msvbvm60!_vbaAptOffset+0x68b
> > 0628f364 7347d3cb 05465460 60030005 734614f4
> > msvbvm60!BASIC_CLASS_Invoke+0x65
>
> The execution has now left VBScript and moved into the COM DLLs. VB run
> time (MSVBVM60) always loads before the execution of the VB COM object, so
> istar21.dll is a VB dll. The function name is wrong (it isn't trying to
> unload, you can see by the _huge_ offset). If you have access to the
> project, you can build symbols by checking the box in the build options
> (creates a .pdb file of the same name, put it in the directory w/the dll or
> place it where WinDBG can find it).
>
> Chunk 5
> > ISTemplates!DllUnregisterServer+0xd409
> > 0628d510 048d53f5 0628f280 058951e0 11073e4c
> > ISTemplates!DllUnregisterServer+0xa80a
> > 0628e268 048d8a29 0628e278 049277d8 646f7270
> > ISTemplates!DllUnregisterServer+0xfc6a
> > 0628e738 110494f8 084dcc34 05aca37c 049277d8
> > ISTemplates!DllUnregisterServer+0x1329e
>
> ISTemplates.dll was called directly from the istar.dll.
>
> Chunk 6:
> 0628bac4 04c0ef45 04f6ce78 08507e2f 08598bef
> IStarDataSources!DllCanUnloadNow+0xbfc15
> 0628bb10 048d2b94 04f6ce78 04ae861c 049277d8
> IStarDataSources!DllCanUnloadNow+0xc059b
>
> IStartDataSources called directly from ISTemplates.dll.
>
> Chunk 7 (getting close)
> 0628b5a4 03fbf93c 0551da60 0628b6c8 0628b6fc CAM!DllCanUnloadNow+0x7598c
> 0628b730 03fba4d0 05e9cf70 0628b7d0 0628b804 CAM!DllCanUnloadNow+0x3223a
> 0628b848 03fb94a1 0513edc0 0628b924 0628b904 CAM!DllCanUnloadNow+0x2cdce
> 0628b940 03fb8691 0513edc0 0628b998 08507e2f CAM!DllCanUnloadNow+0x2bd9f
> 0628b9bc 04c0e5bf 0513edc0 0628baa4 0628ba8c CAM!DllCanUnloadNow+0x2af8f
>
> CAM.dll is called directly from IStartDataSources. This is where things
> look to get a bit flaky. This DLL then starts making a call into the
> runtime, and then into the system. Not really sure what exactly it is doing
> (lacking symbols), but this is most likely the area that is causing a
> problem for you. If you can get symbols for the dll, then you can see the
> class & line number and trace the code yourself. Otherwise you can try
> placing CAM.dll into a COM+ Server package, which will isolate it into a
> different process, and see if the high CPU 'follows'.
>
>
>
> Pat
>
>
> "Eric Hertlein" wrote in message
> news:3EA81EC9-5D76-447B-A401-C4A23EF87374@microsoft.com...
> >
> >
> > "Eric Hertlein" wrote:
> >
> >> I think this is offending thread:
> >>
> >
> > .. snip..
> >
> >> I am not sure where to go from here. It doesn't even look as though this
> >> is
> >> a page being processed. I don't see any ASP calls. Any suggestions?
> >
> > Acutally loading the dump into WinDbg gave me the following thread as the
> > offender:
> >
> > ERROR_CODE: (NTSTATUS) 0x80000007 - {Kernel Debugger Awakened} the system
> > debugger was awakened by an interrupt.
> >
> > DERIVED_WAIT_CHAIN:
> >
> > Dl Eid Cid WaitType
> > -- --- ------- --------------------------
> > 26 568.408 Unknown
> >
> > WAIT_CHAIN_COMMAND: ~26s;k;;
> >
> > BLOCKING_THREAD: 00000408
> >
> > DEFAULT_BUCKET_ID: WRONG_SYMBOLS
> >
> > PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_BusyHang
> >
> > LAST_CONTROL_TRANSFER: from 7c817c9a to 7c82ccb7
> >
> > FAULTING_THREAD: 0000001a
> >
> > STACK_TEXT:
> > WARNING: Stack unwind information not available. Following frames may be
> > wrong.
> > 0628b0a8 7c817c9a 0628b0e0 00073674 00000000 ntdll!bsearch+0x37
> > 0628b100 7c817bde 000734e8 03f75218 0628b164
> > ntdll!RtlFindActivationContextSectionGuid+0x161
> > 0628b140 77e6016c 00000001 00000000 000734e8
> > ntdll!RtlFindActivationContextSectionGuid+0xa5
> > 0628b1a8 776a8578 00000001 00000000 00000004
> > kernel32!FindActCtxSectionGuid+0x49
> > 0628b20c 776a8aa9 00094bb8 00000000 03f75218
> > ole32!CComSxSCatalog::GetClassInfoW+0x25
> > 0628b288 776a8a14 77794a74 00000017 00000000
> > ole32!CComCatalog::GetClassInfoInternal+0x9c
> > 0628b2ac 776a89bd 77794a78 00000017 00000000
> > ole32!CComCatalog::GetClassInfoW+0x22
> > 0628b2cc 776a8947 03f75218 0628b2e8 00000000
> > ole32!GetClassInfoFromClsid+0x2d
> > 0628b2ec 776a6852 03f75218 0628b3c0 00000000
> > ole32!LookForConfiguredClsid+0x33
> > 0628b3d4 776a679a 03f75218 00000000 00000005
> > ole32!ICoCreateInstanceEx+0x135
> > 0628b408 776a6762 03f75218 00000000 00000000
> > ole32!CComActivator::DoCreateInstance+0x6a
> > 0628b42c 73653937 03f75218 00000000 00000005 ole32!CoCreateInstanceEx+0x23
> > 0628b49c 73649c9d 03f75130 0628b4dc 0628b4b4
> > msvbvm60!_vbaBoolErrVar+0x29fd
> > 0628b4d4 0400308e 00000000 0628b5b8 0628b6c8 msvbvm60!_vbaNew+0x21
> > 0628b5a4 03fbf93c 0551da60 0628b6c8 0628b6fc CAM!DllCanUnloadNow+0x7598c
> > 0628b730 03fba4d0 05e9cf70 0628b7d0 0628b804 CAM!DllCanUnloadNow+0x3223a
> > 0628b848 03fb94a1 0513edc0 0628b924 0628b904 CAM!DllCanUnloadNow+0x2cdce
> > 0628b940 03fb8691 0513edc0 0628b998 08507e2f CAM!DllCanUnloadNow+0x2bd9f
> > 0628b9bc 04c0e5bf 0513edc0 0628baa4 0628ba8c CAM!DllCanUnloadNow+0x2af8f
> > 0628bac4 04c0ef45 04f6ce78 08507e2f 08598bef
> > IStarDataSources!DllCanUnloadNow+0xbfc15
> > 0628bb10 048d2b94 04f6ce78 04ae861c 049277d8
> > IStarDataSources!DllCanUnloadNow+0xc059b
> > 0628d4d8 048cff95 08507e2f 08598bef 00012d2f
> > ISTemplates!DllUnregisterServer+0xd409
> > 0628d510 048d53f5 0628f280 058951e0 11073e4c
> > ISTemplates!DllUnregisterServer+0xa80a
> > 0628e268 048d8a29 0628e278 049277d8 646f7270
> > ISTemplates!DllUnregisterServer+0xfc6a
> > 0628e738 110494f8 084dcc34 05aca37c 049277d8
> > ISTemplates!DllUnregisterServer+0x1329e
> > 0628e97c 77d05186 05465460 05895188 05895198
> > istar21!DllCanUnloadNow+0x1e72e
> > 0628e9ac 73646a6f 05465460 00000030 00000004 oleaut32!DispCallFunc+0xab
> > 0628f308 7363a0d4 05465460 11009ad4 60030005 msvbvm60!_vbaAptOffset+0x68b
> > 0628f364 7347d3cb 05465460 60030005 734614f4
> > msvbvm60!BASIC_CLASS_Invoke+0x65
> > 0628f3b8 73468ad1 088fe268 05465460 60030005
> > vbscript!CatchIDispatchInvoke+0x46
> > 0628f3f8 73468a40 088915c8 05465460 60030005
> > vbscript!IDispatchInvoke2+0xaf
> > 0628f434 734689f2 088915c8 05465460 60030005 vbscript!IDispatchInvoke+0x59
> > 0628f548 7346613b 088915c8 05465460 60030005 vbscript!InvokeDispatch+0x13a
> > 0628f56c 73466f6c 088915c8 05465460 60030005 vbscript!InvokeByName+0x42
> > 0628f848 734633e0 00000000 00000000 088915c8
> > vbscript!CScriptRuntime::Run+0x262b
> > 0628f940 734637d1 00000000 00000000 00000000
> > vbscript!CScriptEntryPoint::Call+0x5c
> > 0628f998 73463b9c 0898b9a0 00000000 00000000
> > vbscript!CSession::Execute+0xb4
> > 0628f9e8 73461849 00000000 00000000 709e19c0
> > vbscript!COleScript::ExecutePendingScripts+0x13e
> > 0628fa04 709e2ada 03326528 03326528 02c22f70
> > vbscript!COleScript::SetScriptState+0x150
> > 0628fa30 709e2a9c 00000000 709e19c0 0628fb38
> > asp!CActiveScriptEngine::TryCall+0x19
> > 0628fa6c 709e26d0 00000000 6472474e 02f21f28
> > asp!CActiveScriptEngine::Call+0x31
> > 0628fa88 709e25d4 0628fb0c 00000000 00000000
> > asp!CallScriptFunctionOfEngine+0x5b
> > 0628fadc 709e24ff 03421e90 00000000 0628fb68 asp!ExecuteRequest+0x17e
> > 0628fb44 709e23f7 03421e90 02f21f28 0628fb68 asp!Execute+0x249
> > 0628fb98 709e2753 00000000 00000000 059d2fa0
> > asp!CHitObj::ViperAsyncCallback+0x3f3
> > 0628fbb4 4a77b5ea 02fa26b0 0008c398 0628fd74
> > asp!CViperAsyncRequest::OnCall+0x92
> > 0628fbd0 77720d30 059d2fa0 000e8450 00000000
> > comsvcs!CoCreateActivity+0x4b28
> > 0628fc1c 777217dc 00000000 000e8450 4a77b5b8 ole32!EnterForCallback+0xc4
> > 0628fd7c 776f03b4 0628fc54 4a77b5b8 059d2fa0 ole32!SwitchForCallback+0x1a3
> > 0628fda8 7769c194 000e8450 4a77b5b8 059d2fa0 ole32!PerformCallback+0x54
> > 0628fe40 7772433a 0008c398 4a77b5b8 059d2fa0
> > ole32!CObjectContext::InternalContextCallback+0x159
> > 0628fe60 4a77b78c 0008c398 4a77b5b8 059d2fa0
> > ole32!CObjectContext::DoCallback+0x1c
> > 0628fecc 4a77bcf2 04f340b8 04f34098 053f8bbc
> > comsvcs!CoCreateActivity+0x4cca
> > 0628fee4 4a77c7de 059d2fa0 00000001 04f34098
> > comsvcs!DllUnregisterServer+0x180
> > 0628ff04 4a77cabf 00000000 01be57d8 01bddec8
> > comsvcs!DllUnregisterServer+0xc6c
> > 0628ff84 77bcb530 04f34098 00000000 00000000
> > comsvcs!DllUnregisterServer+0xf4d
> > 0628ffb8 77e64829 01bddec8 00000000 00000000 msvcrt!_endthreadex+0xa3
> > 0628ffec 00000000 77bcb4bc 01bddec8 00000000
> > kernel32!GetModuleHandleA+0xdf
> >
> >
> > FOLLOWUP_IP:
> > msvbvm60!_vbaNew+21
> > 73649c9d 8d4de0 lea ecx,[ebp-20h]
> >
> > SYMBOL_STACK_INDEX: d
> >
> > SYMBOL_NAME: msvbvm60!_vbaNew+21
> >
> > FOLLOWUP_NAME: MachineOwner
> >
> > MODULE_NAME: msvbvm60
> >
> > IMAGE_NAME: msvbvm60.dll
> >
> > STACK_COMMAND: ~26s ; kb
> >
> > BUCKET_ID: WRONG_SYMBOLS
> >
> > FAILURE_BUCKET_ID:
> > msvbvm60.dll!base_address_80000007_APPLICATION_HANG_BusyHang
> >
> > Followup: MachineOwner
> > ---------
> >
> >
> > I am unsure as to how to proceed to determine what the parameters are on
> > this stack trace. If I could figure that out I would be a lot closer to
> > determining the issue.

Re: IIS Consuming 100% CPU

am 04.12.2007 21:48:04 von EricHertlein

"Eric Hertlein" wrote:

> Thank you very much. I feel like I am making some progress. It took me awhile
> but I got the symbol path set correctly in WinDbg and am moving forward.
>
> Here is what the dumps are looking like now:
>
> ChildEBP RetAddr Args to Child
> 0559b238 7c826deb 77e649f7 0559b2e0 80100080 ntdll!KiFastSystemCallRet
> 0559b23c 77e649f7 0559b2e0 80100080 0559b27c ntdll!ZwCreateFile+0xc
> 0559b2d8 77e41a8a 00000000 80000000 00000003 kernel32!CreateFileW+0x377
> 0559b2fc 7365c6d7 0559b378 80000000 00000003 kernel32!CreateFileA+0x30
> 0559b340 7364620a 0559b378 00008000 00000040 msvbvm60!_ld12cvt+0xb7
> 0559b354 73643b1e 0559b378 00008000 00000040 msvbvm60!rtcBstrFromChar+0x34
> 0559b3ac 77d466d5 00000015 00000002 0559b3f4 msvbvm60!VBAErr::put_Number+0x4
> 0559b3c4 0014f678 0559b3e0 776bd000 00080000 oleaut32!CbSysStringSize+0x48
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0559b3e0 77d04141 77796784 04ba5e28 0014f678 0x14f678
> 0559b400 77d04113 00000003 00000010 0559b578
> oleaut32!APP_DATA::FreeCachedMem+0x30
> 0559b41c 736560c0 04ba5e2c 00000000 043d4113 oleaut32!SysFreeString+0x6b
> 0559b560 0438372b 0559b94c 0559b908 0559b904 msvbvm60!_fassign+0x50
> 0559b564 0559b94c 0559b908 0559b904 00000000
> IStarDataSources!ProductListing::OutputProductVars+0x3b8b
> [E:\projects\iStar\branches\4.7.1.5\iStarDataSources\Classes \ProductListing.cls @ 466]
> 0559b568 0559b908 0559b904 00000000 07742ecd 0x559b94c
> 0559b98c 0437baa7 047ba630 0559b9b0 07742ecd 0x559b908
> 0559b9d4 04311588 047ba630 07742ecd 05549509
> IStarDataSources!ProductListing::OutputVariables+0x70
> [E:\projects\iStar\branches\4.7.1.5\iStarDataSources\Classes \ProductListing.cls @ 60]
> *** WARNING: Unable to verify checksum for ISTemplates.dll
> 0559bb18 04112b94 045e0680 042ded24 0429bf00
> IStarDataSources!BrowseProducts::IStarDataSource_Execute+0xb 5d
> [E:\projects\iStar\branches\4.7.1.5\iStarDataSources\Classes \BrowseProducts.cls @ 179]
> 0559d4e0 0410ff95 07742ecd 05549509 0000eec5
> ISTemplates!CTemplateRuntime::Data+0x518
> [E:\projects\iStar\branches\4.7.1.5\ISTemplates\TemplateRunt ime.cpp @ 1092]
> 0559d518 041153f5 0559f280 06fd7b10 11073e4c
> ISTemplates!CTemplateRuntime::Run+0x101
> [E:\projects\iStar\branches\4.7.1.5\ISTemplates\TemplateRunt ime.cpp @ 122]
> 0559e270 04118a29 0559e280 0429bf00 776f7262
> ISTemplates!CTemplates::ProcessTemplate+0x42b
> [E:\projects\iStar\branches\4.7.1.5\ISTemplates\Templates.cp p @ 133]
>
>
>
> If this is the wrong place to ask this question please let me know...
>
> I am looking at these dumps that I have with WinDbg... is there some way for
> me to tell the user time these threads are using/have used? That would help
> me determine which ones are stuck.
>
> Eric
>
.. snip ..


Well I just found the !runaway command in WinDbg. That gave me some good
output. I will do a little more digging on my own.

Thanks again Pat.

Re: IIS Consuming 100% CPU

am 05.12.2007 22:25:41 von patfilot

OK.

The thread below has actually transitioned into the kernel, after making an
IO call. It is possible that there is a conflict here w/your AV software or
a driver problem.


Pat


"Eric Hertlein" wrote in message
news:7A8C0CC3-2701-4B9E-85AE-25D54AA2A90A@microsoft.com...
>
>
> "Eric Hertlein" wrote:
>
>> Thank you very much. I feel like I am making some progress. It took me
>> awhile
>> but I got the symbol path set correctly in WinDbg and am moving forward.
>>
>> Here is what the dumps are looking like now:
>>
>> ChildEBP RetAddr Args to Child
>> 0559b238 7c826deb 77e649f7 0559b2e0 80100080 ntdll!KiFastSystemCallRet
>> 0559b23c 77e649f7 0559b2e0 80100080 0559b27c ntdll!ZwCreateFile+0xc
>> 0559b2d8 77e41a8a 00000000 80000000 00000003 kernel32!CreateFileW+0x377
>> 0559b2fc 7365c6d7 0559b378 80000000 00000003 kernel32!CreateFileA+0x30
>> 0559b340 7364620a 0559b378 00008000 00000040 msvbvm60!_ld12cvt+0xb7
>> 0559b354 73643b1e 0559b378 00008000 00000040
>> msvbvm60!rtcBstrFromChar+0x34
>> 0559b3ac 77d466d5 00000015 00000002 0559b3f4
>> msvbvm60!VBAErr::put_Number+0x4
>> 0559b3c4 0014f678 0559b3e0 776bd000 00080000
>> oleaut32!CbSysStringSize+0x48
>> WARNING: Frame IP not in any known module. Following frames may be wrong.
>> 0559b3e0 77d04141 77796784 04ba5e28 0014f678 0x14f678
>> 0559b400 77d04113 00000003 00000010 0559b578
>> oleaut32!APP_DATA::FreeCachedMem+0x30
>> 0559b41c 736560c0 04ba5e2c 00000000 043d4113 oleaut32!SysFreeString+0x6b
>> 0559b560 0438372b 0559b94c 0559b908 0559b904 msvbvm60!_fassign+0x50
>> 0559b564 0559b94c 0559b908 0559b904 00000000
>> IStarDataSources!ProductListing::OutputProductVars+0x3b8b
>> [E:\projects\iStar\branches\4.7.1.5\iStarDataSources\Classes \ProductListing.cls
>> @ 466]
>> 0559b568 0559b908 0559b904 00000000 07742ecd 0x559b94c
>> 0559b98c 0437baa7 047ba630 0559b9b0 07742ecd 0x559b908
>> 0559b9d4 04311588 047ba630 07742ecd 05549509
>> IStarDataSources!ProductListing::OutputVariables+0x70
>> [E:\projects\iStar\branches\4.7.1.5\iStarDataSources\Classes \ProductListing.cls
>> @ 60]
>> *** WARNING: Unable to verify checksum for ISTemplates.dll
>> 0559bb18 04112b94 045e0680 042ded24 0429bf00
>> IStarDataSources!BrowseProducts::IStarDataSource_Execute+0xb 5d
>> [E:\projects\iStar\branches\4.7.1.5\iStarDataSources\Classes \BrowseProducts.cls
>> @ 179]
>> 0559d4e0 0410ff95 07742ecd 05549509 0000eec5
>> ISTemplates!CTemplateRuntime::Data+0x518
>> [E:\projects\iStar\branches\4.7.1.5\ISTemplates\TemplateRunt ime.cpp @
>> 1092]
>> 0559d518 041153f5 0559f280 06fd7b10 11073e4c
>> ISTemplates!CTemplateRuntime::Run+0x101
>> [E:\projects\iStar\branches\4.7.1.5\ISTemplates\TemplateRunt ime.cpp @
>> 122]
>> 0559e270 04118a29 0559e280 0429bf00 776f7262
>> ISTemplates!CTemplates::ProcessTemplate+0x42b
>> [E:\projects\iStar\branches\4.7.1.5\ISTemplates\Templates.cp p @ 133]
>>
>>
>>
>> If this is the wrong place to ask this question please let me know...
>>
>> I am looking at these dumps that I have with WinDbg... is there some way
>> for
>> me to tell the user time these threads are using/have used? That would
>> help
>> me determine which ones are stuck.
>>
>> Eric
>>
> .. snip ..
>
>
> Well I just found the !runaway command in WinDbg. That gave me some good
> output. I will do a little more digging on my own.
>
> Thanks again Pat.
>