崩潰待查

轉儲我有我的應用程序上的錯誤（從WinDbg中）以下調用堆棧崩潰：崩潰待查

ntdll!ZwWaitForMultipleObjects+0xa 
KERNELBASE!WaitForMultipleObjectsEx+0xe8 
kernel32!WaitForMultipleObjectsExImplementation+0xb3 
clr!WaitForMultipleObjectsEx_SO_TOLERANT+0x91 
clr!Thread::DoAppropriateAptStateWait+0x56 
clr!Thread::DoAppropriateWaitWorker+0x1b1 
clr!Thread::DoAppropriateWait+0x73 
clr!CLREvent::WaitEx+0xc1 
clr!CLREventWaitWithTry+0x5c 
clr! ?? ::FNODOBFM::`string'+0x6286a 
clr!AssemblySecurityDescriptor::UpgradePEFileEvidenceToAssemblyEvidence+0x11d 
clr!Assembly::ExecuteMainMethod+0xcb 
clr!SystemDomain::ExecuteMainMethod+0x452 
clr!ExecuteEXE+0x43 
clr!CorExeMainInternal+0xc4 
clr!CorExeMain+0x15 
mscoreei!CorExeMain+0x41 
mscoree!CorExeMain_Exported+0x57 
kernel32!BaseThreadInitThunk+0xd 
ntdll!RtlUserThreadStart+0x1d

這是一個託管應用程序，並根據WinDbg的有來自運行61個進程/線程應用。在WinDbg中，鍵入！線程時，它表示沒有找到導出線程。它沒有說明是什麼錯誤造成的（在Visual Studio 2010中，它表示一個NullReferenceException）。我認爲這是與USB串行控制器有關，但我把它放到另一個應用程序中，它仍然崩潰（儘管不像以前那樣100％，而是像80％）。

這個異常/錯誤完全無法解決我，我無法弄清楚如何解決它。

更新，使用.loadby SOS CLR：

0:000> !threads 
ThreadCount:  23 
UnstartedThread: 0 
BackgroundThread: 17 
PendingThread: 0 
DeadThread:  4 
Hosted Runtime: no 
              PreEmptive             Lock 
     ID OSID  ThreadOBJ  State GC  GC Alloc Context     Domain   Count APT Exception 
    0 1 1678 00000000023dbfe0 201a228 Enabled 0000000000000000:0000000000000000 00000000004a5510  0 MTA 
    2 2 1b4 000000000243a230  b228 Enabled 0000000000000000:0000000000000000 00000000004a5510  0 MTA (Finalizer) 
XXXX 4  0000000004039010  19820 Enabled 0000000000000000:0000000000000000 00000000004a5510  0 MTA 
XXXX 5  0000000004099f50  19820 Enabled 0000000000000000:0000000000000000 00000000004a5510  0 Ukn 
    7 6 148c 00000000024bc5f0  228 Enabled 0000000000000000:0000000000000000 00000000004a5510  0 Ukn 
    9 7 19bc 00000000040e1420  b028 Enabled 0000000000000000:0000000000000000 00000000004a5510  0 MTA 
    4 8 1ba8 00000000040a4ff0  228 Enabled 0000000000000000:0000000000000000 00000000004a5510  0 Ukn 
    10 9 17f8 00000000040ab760  8b228 Enabled 0000000000000000:0000000000000000 00000000004a5510  0 MTA 
    11 a 10a0 00000000040b4890  87028 Enabled 000000000f411ff0:000000000f4120e0 00000000004a5510  0 STA System.ServiceModel.CommunicationObjectFaultedException (000000000f403608) 
XXXX 3  00000000040b58a0  19820 Enabled 0000000000000000:0000000000000000 00000000004a5510  0 Ukn 
XXXX b  0000000007e03220  19820 Enabled 0000000000000000:0000000000000000 00000000004a5510  0 Ukn 
    26 c b48 0000000007eee6b0 2000228 Enabled 000000000f417780:000000000f4180e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f35c0f8) 
    27 d 22c 0000000007e149c0  80228 Enabled 000000000f3d18f8:000000000f3d20e0 00000000004a5510  1 Ukn System.NullReferenceException (000000000f35a0f8) 
    40 16 116c 0000000027db3db0  80228 Enabled 000000000f419300:000000000f41a0e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f34c0f8) 
    38 17 18c8 0000000027db44c0 2000228 Enabled 000000000f4054d8:000000000f4060e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f34a0f8) 
    37 15 a78 0000000027db36a0 2000228 Enabled 000000000f40bac8:000000000f40c0e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f3540f8) 
    41 13 112c 0000000027db2880 2000228 Enabled 000000000f415c00:000000000f4160e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f34e0f8) 
    30 f 938 000000000415b590  80228 Enabled 000000000f4081f0:000000000f40a0e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f3520f8) 
    36 14 4f0 0000000027db2f90  80228 Enabled 000000000f412f70:000000000f4140e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f3500f8) 
    28 10 88c 0000000007ef2500 2000228 Enabled 000000000f3e9238:000000000f3ea0e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f35e0f8) 
    31 11 180c 0000000027aac5a0  80228 Enabled 000000000f41bb28:000000000f41c0e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f3580f8) 
    33 12 1b2c 0000000027db2170 2000228 Enabled 000000000f3bb238:000000000f3bc0e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f3560f8) 
    29 e 1968 0000000007eeca60 2000228 Enabled 000000000f3e2cc8:000000000f3e40e0 00000000004a5510  0 Ukn System.NullReferenceException (000000000f3600f8) 
*** WARNING: Unable to verify checksum for System.ni.dll 
*** WARNING: Unable to verify checksum for System.Transactions.ni.dll

通信異常被抓（發生這種情況，當WCF主機不起來，而且可能發生在斷開硬件）。我懷疑這是導致我的崩潰的原因，因爲在Visual Studio中，它總是與NullReferenceException一起崩潰，但沒有可用的CallStack/Disassembly。

當我看到例如線程OSID 22C（一個帶一個NullReferenceException），調用堆棧是

ntdll!ZwWaitForSingleObject+0xa 
KERNELBASE!WaitForSingleObjectEx+0x79 
clr!Thread::LeaveRuntimeNoThrow+0x7c 
clr!Thread::LeaveRuntimeNoThrow+0xec 
clr!CLREvent::WaitEx+0x5e 
clr!Thread::WaitSuspendEventsHelper+0xcf 
clr!Thread::WaitSuspendEvents+0x11 
clr! ?? ::FNODOBFM::`string'+0x628f1 
clr!Thread::RareDisablePreemptiveGC+0xfa 
clr!GCHolderEEInterface<0,1,0>::~GCHolderEEInterface<0,1,0>+0x19 
clr!Debugger::SendLogMessage+0xb7 
clr!DebugDebugger::Log+0x223 
System_ni+0x2b5f71 
System_ni+0x243c3a 
System_ni+0x714851 
System_ni+0x70d7a7 
System_Transactions_ni!_dyn_tls_init_callback <PERF> (System_Transactions_ni+0x738ec) 
System_Transactions_ni!_dyn_tls_init_callback <PERF> (System_Transactions_ni+0x72b13) 
clr!CallDescrWorker+0x84 
clr!CallDescrWorkerWithHandler+0xa9 

0:027> ~40 
    40 Id: 1278.116c Suspend: 0 Teb: 000007ff`ffbfa000 Unfrozen 
     Start: Loading symbols for 00000000`709b0000  msvcr100.dll -> msvcr100.dll 
msvcr100!endthreadex+0x60 (00000000`709d1dbc) 
     Priority: 0 Priority class: 32 Affinity: f 
0:027> !pe 
Exception object: 000000000f35a0f8 
Exception type: System.NullReferenceException 
Message:   Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. 
InnerException: <none> 
StackTrace (generated): 
    SP    IP    Function 
    000000002759FC60 0000000000000001 mscorlib_ni!System.StubHelpers.StubHelpers.CheckCollectedDelegateMDA(IntPtr)+0x2 

StackTraceString: <none> 
HResult: 80004003

來源

2013-04-15 SinisterMJ

你有任何代碼，你知道它崩潰嗎？或者，你打算髮現什麼？ – ThaMe90

這是完全我的代碼，除了我使用的相機API。我想知道，它爲什麼會崩潰（關閉連接到系統的硬件）。如果我可以通過如何與相機進行通信來了解它是否出現錯誤，或者我如何與MicroController（通過WCF和第二個應用程序）進行通信，或者導致死鎖的其他事情，或者其他任何情況。我想知道，爲什麼它首先崩潰。 – SinisterMJ

這個堆棧跟蹤看起來很無辜。 WinDbg中是否啓用了Win32異常？我已經看到託管應用程序在Win32調用中崩潰的位置，而WinDbg不會顯示崩潰的來源，因爲默認情況下Win32不由WinDbg處理。 – StarPilot

似乎你已經發布的堆棧跟蹤不崩潰有關係，因爲它是在睡覺狀態，等待什麼。

您可以查看一下Windows事件日誌，有時CLR會在應用程序崩潰時將有意義的消息放在那裏。另外，如果您使用的是.Net 4或更高版本，在Visual Studio中分析託管過程轉儲更方便，因爲您可以輕鬆地在線程之間導航，甚至可以構建僅顯示不同部分的複合線程圖在他們的調用堆棧中。

來源

2013-04-15 14:06:33 alex

這個堆棧跟蹤看起來很無辜。嘗試在WinDbg中啓用Win32異常。我看到託管應用程序在其底層Win32調用中崩潰，並且WinDbg不會正確顯示崩潰的來源，因爲默認情況下不處理Win32異常。

來源

2013-04-15 14:41:00 StarPilot

回答

相關問題