分析WinDbg中的崩潰

我有一個.NET應用程序在退出時有時會崩潰。在引擎蓋下面還有一堆COM和原生的東西。它是在Windows 7 x64上運行的x86應用程序。分析WinDbg中的崩潰

我已經運行了一些WinDbg教程，我認爲我正在執行合理的步驟來獲取有用的信息，但堆棧跟蹤本身並沒有響動任何響鈴。

其它一些信息：

我可以重現這個漂亮的一致，說的時間
如果我清理線程（很多Thread.Abort()）75％，這是可重複的，也許20％時間
運行同樣的程序，我見過比下面的一個完全不同的堆棧跟蹤，太

我使用的是32位的WinDbg。這是我一直在使用的一般過程：

直接從WinDbg中打開可執行
組符號路徑爲：SRV*c:\sym*http://msdl.microsoft.com/download/symbols
類型：.loadby sos clr
使用的應用程序，並讓它崩潰

右鍵撞車後，我得到的輸出：

(a38.1424): CLR exception - code e0434352 (first chance) 
(a38.1424): CLR exception - code e0434352 (first chance) 
(a38.1fd0): Unknown exception - code c000000d (first chance) 
(a38.1fd0): Unknown exception - code c000000d (!!! second chance !!!) 
eax=00000000 ebx=004dea1c ecx=7efdd000 edx=00000057 esi=7264d0c0 edi=07f2a248 
eip=778715de esp=004dea08 ebp=004def50 iopl=0   nv up ei pl zr na pe nc 
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b    efl=00000246 
ntdll!ZwRaiseException+0x12: 
778715de 83c404   add  esp,4

如果我在~型我只得到一個線索： . 0 Id: a38.1fd0 Suspend: 1 Teb: 7efdd000 Unfrozen

現在，如果我在!analyze -v型我得到一個大的堆棧跟蹤：

******************************************************************************* 
*                    * 
*      Exception Analysis         * 
*                    * 
******************************************************************************* 
[ a bunch of symbol stuff loading here ] 

FAULTING_IP: 
ntdll!TpReleaseCleanupGroupMembers+276 
778e4f52 a1b4009577  mov  eax,dword ptr [ntdll!TppLogpRoutine (779500b4)] 

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) 
ExceptionAddress: 778e4f52 (ntdll!TpReleaseCleanupGroupMembers+0x00000276) 
    ExceptionCode: c000000d 
    ExceptionFlags: 00000000 
NumberParameters: 0 

FAULTING_THREAD: 00001fd0 

PROCESS_NAME: XXXXX.exe 

ERROR_CODE: (NTSTATUS) 0xc000000d - An invalid parameter was passed to a service or function. 

EXCEPTION_CODE: (NTSTATUS) 0xc000000d - An invalid parameter was passed to a service or function. 

NTGLOBALFLAG: 70 

APPLICATION_VERIFIER_FLAGS: 0 

CONTEXT: 004dea6c -- (.cxr 0x4dea6c) 
eax=004deee0 ebx=00000001 ecx=7efdd000 edx=00000057 esi=7264d0c0 edi=07f2a248 
eip=778e4f52 esp=004deed0 ebp=004def50 iopl=0   nv up ei ng nz ac pe cy 
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b    efl=00000297 
ntdll!TpReleaseCleanupGroupMembers+0x276: 
778e4f52 a1b4009577  mov  eax,dword ptr [ntdll!TppLogpRoutine (779500b4)] ds:002b:779500b4=00000000 
Resetting default scope 

STACK_ADDR_RAW_STACK_SYMBOL: 4deb4c 

ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[ffffffff] 

LAST_CONTROL_TRANSFER: from 00000000 to 77883c04 

DEFAULT_BUCKET_ID: STATUS_INVALID_PARAMETER 

PRIMARY_PROBLEM_CLASS: STATUS_INVALID_PARAMETER 

BUGCHECK_STR: APPLICATION_FAULT_STATUS_INVALID_PARAMETER 

STACK_TEXT: 
778e4f52 ntdll!TpReleaseCleanupGroupMembers+0x276 
72630d69 AUDIOSES!DllCanUnloadNow+0x42 
7565b5f4 ole32!CClassCache::CDllPathEntry::CanUnload_rl+0x3b 
7565b771 ole32!CClassCache::FreeUnused+0x83 
7565b68f ole32!CoFreeUnusedLibrariesEx+0x36 
756a0ccb ole32!CoFreeUnusedLibraries+0x9 
15e2f549 GxMetadata+0xf549 
15e45e3d GxMetadata!DllCanUnloadNow+0x1686d 
77889950 ntdll!LdrpCallInitRoutine+0x14 
7789d6b2 ntdll!LdrShutdownProcess+0x1aa 
7789d554 ntdll!RtlExitUserProcess+0x74 
754279f4 KERNEL32!ExitProcessStub+0x12 
720642f0 mscoreei!RuntimeDesc::ShutdownAllActiveRuntimes+0x29c 
72064321 mscoreei!CLRRuntimeHostInternalImpl::ShutdownAllRuntimesThenExit+0x15 
5ea18580 clr!EEPolicy::ExitProcessViaShim+0x66 
5ea1862f clr!SafeExitProcess+0x122 
5e9638a9 clr!DisableRuntime+0x120 
5e963905 clr!EEPolicy::HandleExitProcess+0x5c 
5e9b8af8 clr!_CorExeMainInternal+0xdd 
5e9b3a30 clr!_CorExeMain+0x4e 
720555ab mscoreei!_CorExeMain+0x38 
72f67f16 MSCOREE!ShellShim__CorExeMain+0x99 
72f64de3 MSCOREE!_CorExeMain_Exported+0x8 
7542339a KERNEL32!BaseThreadInitThunk+0xe 
77889ef2 ntdll!__RtlUserThreadStart+0x70 
77889ec5 ntdll!_RtlUserThreadStart+0x1b 


FOLLOWUP_IP: 
AUDIOSES!DllCanUnloadNow+42 
72630d69 ff3514d06472 push dword ptr [AUDIOSES!_AudioClientThreadpoolCleanupGroup (7264d014)]

編輯1：（附加信息）

！clrstack

OS Thread Id: 0x1fd0 (0) 
Child SP IP  Call Site 
GetFrameContext failed: 1

！日讀

ThreadCount:  7 
UnstartedThread: 0 
BackgroundThread: 4 
PendingThread: 0 
DeadThread:  3 
Hosted Runtime: no 
            PreEmptive GC Alloc    Lock 
     ID OSID ThreadOBJ State GC   Context  Domain Count APT Exception 
    0 1 1fd0 005afe88  16220 Enabled 03051294:03051e6c 00578550  0 STA 
XXXX 2 e5c 005801d0  b220 Enabled 0305a22c:0305be6c 00578550  0 MTA (Finalizer) 
XXXX 3  00641258  19820 Enabled 00000000:00000000 00578550  0 Ukn 
XXXX 4  06e4b800 819820 Enabled 00000000:00000000 00578550  0 Ukn 
XXXX 5 18a0 081be620 200b220 Enabled 00000000:00000000 00578550  1 MTA 
XXXX 8  081d5e18 819820 Enabled 00000000:00000000 00578550  0 Ukn 
XXXX 7 158 07ed78d8  220 Enabled 00000000:00000000 00578550  0 Ukn

來源

2012-08-28 jglouie

該堆棧中有.NET方法。您可能還想執行'！clrstack'並檢查結果 - 也許還會在這裏發佈它們。 – driis

'〜'命令顯示非管理線程。你也可以通過'！看到託管線程。線程'命令。 – Rost

我添加了'！clrstack'和'！threads'輸出 – jglouie

貌似ntdll!TpReleaseCleanupGroupMembers（同爲kernel32!CloseThreadpoolCleanupGroupMembers - 你可以看看它的MSDN）功能（從故障堆棧的頂部），不喜歡被稱爲當進程被關閉 - 這在這種情況下拋出你看到的異常（無效參數）。

從兩個庫的堆棧上的存在（audioses和gxmetadata）我猜一些對象被銷燬/釋放太晚。 audioses.dll似乎是核心音頻API庫，不知道gxmetadata.dll - 你能解釋這些用法嗎？

來源

2012-08-29 14:22:28 deemok

我對這些沒有任何解釋，儘管它們完全可能被我們從第三方使用的某些庫使用 – jglouie

這可能與自由使用Thread.Abort（）有關嗎？（我清理了一堆，但不是全部，這似乎降低了重現性，但我無法確定這是掩蓋了問題還是可能解決問題）。 – jglouie

此刻很難說。你可以在windbg中運行'lm vm gxmetadata *'來獲取供應商信息，所以至少可以清楚我們正在談論什麼類型的COM對象？ – deemok

分析WinDbg中的崩潰

回答

相關問題