2009-06-10 73 views
5

我們的Windows應用程序經常掛在內存中,我試圖用windbg跟蹤 解決問題。我對windbg很陌生,可以使用一些建議(儘管我已經開始閱讀高級Windows調試,但我仍然可以使用 )。診斷未能停止的應用程序

該應用程序是用VB編寫的C++和COM對象的混合。偶爾當您退出時,應用程序似乎會消失,但任務管理器顯示它在內存中掛起大約 ,顯然處於空閒狀態。 !

線程顯示我:

ThreadCount: 2 
UnstartedThread: 0 
BackgroundThread: 2 
PendingThread: 0 
DeadThread: 0 
Hosted Runtime: no 
             PreEmptive GC Alloc   Lock 
     ID OSID ThreadOBJ State  GC  Context  Domain Count APT Exception 
    0 1 175c 001aa040  4220 Enabled 09131b78:09131fe8 001a2b80  0 STA 
    6 2 143c 001b4b48  b220 Enabled 00000000:00000000 001a2b80  0 MTA (Finalizer) 

爲了我的未經訓練的眼睛,它看起來像它被保持活由被阻止通過一個單線程公寓 敲定隊列。這個 看起來是否合理?

〜0KB產量:

ntdll!KiFastSystemCallRet 
user32!NtUserGetMessage+0xc 
mfc80!AfxInternalPumpMessage+0x18 [f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 153] 
mfc80!CWinThread::Run+0x54 [f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 625] 
mfc80!AfxWinMain+0x69 [f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 47] 
WARNING: Stack unwind information not available. Following frames may be wrong. 
OurApp+0x7e8274 
kernel32!BaseProcessStart+0x23 

〜6KB產量:

ntdll!KiFastSystemCallRet 
ntdll!ZwWaitForMultipleObjects+0xc 
kernel32!WaitForMultipleObjectsEx+0x12c 
kernel32!WaitForMultipleObjects+0x18 
mscorwks!WKS::WaitForFinalizerEvent+0x7a 
mscorwks!WKS::GCHeap::FinalizerThreadWorker+0x75 
mscorwks!Thread::UserResumeThread+0xfb 
mscorwks!Thread::DoADCallBack+0x355 
mscorwks!Thread::DoADCallBack+0x541 
mscorwks!ManagedThreadBase_NoADTransition+0x32 
mscorwks!ManagedThreadBase::FinalizerBase+0xb 
mscorwks!WKS::GCHeap::FinalizerThreadStart+0xbb 
mscorwks!Thread::intermediateThreadProc+0x49 
kernel32!BaseThreadStart+0x37 

我將在這裏欣賞一點點修正路線。如果我對 封鎖終結者的猜測看起來合理,請告訴我。我也是 很高興得到一些建議,弄清楚什麼是封鎖。

編輯:

巴蒂爾要求從輸出分析!這實際上是從一個不同的轉儲 - 我有很多,他們都看起來幾乎相同。

 
FAULTING_IP: 
+18a952f00ebdf74 
00000000 ??    ??? 

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) 
ExceptionAddress: 00000000 
    ExceptionCode: 80000007 (Wake debugger) 
    ExceptionFlags: 00000000 
NumberParameters: 0 

BUGCHECK_STR: 80000007 

PROCESS_NAME: OurApp.exe 

OVERLAPPED_MODULE: Address regions for 'OurApp' and 'Unknown_Module_00350062' overlap 

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

EXCEPTION_CODE: (HRESULT) 0x80000007 (2147483655) - Operation aborted 

NTGLOBALFLAG: 0 

APPLICATION_VERIFIER_FLAGS: 0 

MANAGED_STACK: !dumpstack -EE 
OS Thread Id: 0x4490 (0) 
Current frame: 
ChildEBP RetAddr Caller,Callee 

DERIVED_WAIT_CHAIN: 

Dl Eid Cid  WaitType 
-- --- ------- -------------------------- 
    0 48c8.4490 Speculated (Triage) --> 
    5 48c8.4b74 Event     

WAIT_CHAIN_COMMAND: ~0s;k;;~5s;k;; 

BLOCKING_THREAD: 00004b74 

DEFAULT_BUCKET_ID: APPLICATION_HANG_BlockedOn_EventHandle 

PRIMARY_PROBLEM_CLASS: APPLICATION_HANG_BlockedOn_EventHandle 

LAST_CONTROL_TRANSFER: from 7c90df4a to 7c90e514 

FAULTING_THREAD: 00000005 

STACK_TEXT: 
0882fcd0 7c90df4a 7c809590 00000002 0882fcfc ntdll!KiFastSystemCallRet 
0882fcd4 7c809590 00000002 0882fcfc 00000001 ntdll!ZwWaitForMultipleObjects+0xc 
0882fd70 7c80a115 00000002 7a3b8d28 00000000 kernel32!WaitForMultipleObjectsEx+0x12c 
0882fd8c 79f92c5b 00000002 7a3b8d28 00000000 kernel32!WaitForMultipleObjects+0x18 
0882fdac 79f970b8 001b1ad8 0882feb0 001a0b18 mscorwks!WKS::WaitForFinalizerEvent+0x77 
0882fdc0 79e984cf 0882feb0 00000000 00000000 mscorwks!WKS::GCHeap::FinalizerThreadWorker+0x49 
0882fdd4 79e9846b 0882feb0 0882fe5c 79f7762b mscorwks!Thread::DoADCallBack+0x32a 
0882fe68 79e98391 0882feb0 9f3f02e2 00000000 mscorwks!Thread::ShouldChangeAbortToUnload+0xe3 
0882fea4 79eef74c 0882feb0 00000000 001a86c0 mscorwks!Thread::ShouldChangeAbortToUnload+0x30a 
0882fecc 79eef75d 79f9706d 00000008 0882ff14 mscorwks!ManagedThreadBase_NoADTransition+0x32 
0882fedc 79f3c6bc 79f9706d 9f3f0352 00000000 mscorwks!ManagedThreadBase::FinalizerBase+0xd 
0882ff14 79f920a5 00000000 86fb6620 804fb078 mscorwks!WKS::GCHeap::FinalizerThreadStart+0xbb 
0882ffb4 7c80b729 001a0b18 00730074 00610020 mscorwks!Thread::intermediateThreadProc+0x49 
0882ffec 00000000 79f9205f 001a0b18 00000000 kernel32!BaseThreadStart+0x37 


FOLLOWUP_IP: 
mscorwks!WKS::WaitForFinalizerEvent+77 
79f92c5b 85c0   test eax,eax 

SYMBOL_STACK_INDEX: 4 

SYMBOL_NAME: mscorwks!WKS::WaitForFinalizerEvent+77 

FOLLOWUP_NAME: MachineOwner 

MODULE_NAME: mscorwks 

IMAGE_NAME: mscorwks.dll 

DEBUG_FLR_IMAGE_TIMESTAMP: 492b82c1 

STACK_COMMAND: ~5s ; kb 

BUCKET_ID: 80000007_mscorwks!WKS::WaitForFinalizerEvent+77 

FAILURE_BUCKET_ID: APPLICATION_HANG_BlockedOn_EventHandle_80000007_mscorwks.dll!WKS::WaitForFinalizerEvent 

WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/OurApp_exe/6_2_6_1/4a29a184/unknown/0_0_0_0/bbbbbbb4/80000007/00000000.htm?Retriage=1 

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

0:000> !threads 
ThreadCount: 2 
UnstartedThread: 0 
BackgroundThread: 2 
PendingThread: 0 
DeadThread: 0 
Hosted Runtime: no 
             PreEmptive GC Alloc   Lock 
     ID OSID ThreadOBJ State  GC  Context  Domain Count APT Exception 
    0 1 4490 0019de20  4220 Enabled 09003658:09003fe8 001a86c0  0 STA 
    5 2 4b74 001b1b08  b220 Enabled 00000000:00000000 001a86c0  0 MTA (Finalizer) 
+0

您確定所有創建的對象已正確釋放?最簡單的方法是使用一些不同的auto ptr類。如果你沒有這樣做,你應該。 – eran 2009-06-10 19:46:37

+0

我認爲這個掛起是一個泄露的COM對象的結果。似乎認識到應該有一些方法來找到泄漏的物體與windbg。有什麼建議?另外,我是一個聰明的指針的大信徒,只要我可以避免裸指針。 – criddell 2009-06-11 14:12:28

回答

3

終結器線程空閒,正在等待工作 - 它的蹤跡看起來很好。 Theread 0也看起來很好,並且處於空閒狀態 - 它等待下一個UI消息。

你可以提供一些關於如何退出應用程序的細節嗎?鑑於消息循環仍在運行,在我看來,您的關閉應用程序邏輯有些問題。

+0

這是一個MFC Windows應用程序。自從我深入研究代碼以來已經有一段時間了,但我相信應用最終會發布SC_CLOSE或WM_QUIT消息。我猜它是鎖定的,因爲有一些OLE對象仍然在內存中,並且AfxOleCanExitApp()返回false,因爲對象數量大於0.我認爲,如果我能更好地使用windbg,我將能夠找到泄漏的對象。 – criddell 2009-06-11 14:20:52

2

我同意J. Passing。

由於一個線程是託管代碼,您是否嘗試過在windbg中加載SOS調試擴展來獲取託管堆棧跟蹤。你也可以試試windbg的「!analyze -v」命令,看看有什麼說的。