2009-06-10 8 views
5

Google의 Windows 앱은 종종 메모리에 매달려 있으며 windbg를 사용하여 을 추적하려고합니다. 나는 windbg에 익숙하지 않고 조언을 사용할 수도있다. (나는 고급 윈도우 디버깅을 읽었지만).중단하지 못하는 앱 진단

이 응용 프로그램은 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) 

:

스레드 나에게 이것을 보여줍니다. 이 이 합리적으로 보이나요?

~ 0킬로바이트 수율 :

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 

~ 6킬로바이트 수율 :

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

생성 된 모든 개체가 제대로 출시 되었습니까? 가장 쉬운 방법은 다양한 자동 ptr 클래스 중 일부를 사용하는 것입니다. 당신이 그렇게하지 않았다면, 당신은해야합니다. – eran

+0

이 중단은 누수 된 COM 개체의 결과라고 생각합니다. windbg로 누출 된 객체를 찾는 방법이 있어야한다는 것을 알았습니다. 어떤 충고? 또한, 나는 스마트 포인터를 크고, 큰 신자로 만들 수있을 때마다 맨손으로 포인터를 피합니다. – criddell

답변

3

finalizer 스레드가 유휴 상태이며 작업 대기 중입니다. 추적 기능이 정상적으로 작동합니다. Theread 0도 괜찮아 보이고 유휴 상태입니다. 다음 UI 메시지를 기다립니다.

응용 프로그램을 종료하는 방법에 대해 자세히 설명해 줄 수 있습니까? 메시지 루프가 여전히 실행 중임을 감안할 때 가까운 응용 프로그램 논리에 문제가있는 것 같습니다.

+0

MFC Windows 앱입니다. 코드를 파고 들었으니 꽤 오랜 시간이 걸렸지 만, 앱이 SC_CLOSE 또는 WM_QUIT 메시지를 게시하여 종료한다고 생각합니다. 일부 OLE 개체가 여전히 메모리에 있고 AfxOleCanExitApp() 개체의 개수가> 0 때문에 AfxOleCanExitApp() false를 반환하기 때문에 잠겨있어 것 같아요. 만약 내가 더 나은 windbg 일할 수있는, 내가 누수 된 개체를 찾을 수있을 것이라고 생각합니다. – criddell

2

나는 J. Passing에 동의합니다.

하나의 스레드가 관리 코드이므로 관리 스택 추적을 얻으려면 windbg에 SOS 디버그 확장을로드 해 보았습니다. 또한 windbg의 "!analyze -v"명령을 시도해 볼 수 있습니다.

+0

Shane, 위의 analyze 명령의 결과를 붙여 넣었습니다. 이것 좀 봐 줘서 고마워. – criddell

+0

다른 게시물의 내용을 확인하는 것이 좋습니다.또한 sos 확장을로드 한 후에 '! clrstack'의 출력을 게시 할 수 있습니까? 그것은 조금 도움이 될 수 있습니다. 또한 체크 아웃 http://blogs.msdn.com/tess/archive/2007/12/12/automated-net-hang-analysis.aspx –