Discarica con origine sconosciuta

Ho la mia applicazione si blocca con il seguente CallStack sull’errore (da 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 

Questa è un’applicazione gestita e, secondo WinDbg, ci sono 61 processi / thread in esecuzione da tale applicazione. In WinDbg, quando si digitano! Thread, si dice che non sono stati trovati thread di esportazione. Non dice quale errore abbia causato ciò (in Visual Studio 2010, si dice una NullReferenceException).

Sto impazzendo, pensavo che fosse collegato a un controller seriale USB, ma l’ho inserito in un’altra applicazione, e si blocca ancora (anche se non con il 100% come prima, ma piuttosto con l’80%).

Questa eccezione / errore mi sfugge completamente e non riesco a capire come risolverlo.

Aggiornamento, utilizzando .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 

L’eccezione di comunicazione viene rilevata (questo accade quando l’host WCF non è attivo e può accadere quando si disconnette l’hardware). Dubito che questa sia la causa del mio arresto poiché in Visual Studio si blocca sempre con una NullReferenceException, ma non è disponibile CallStack / Disassembly.

Quando guardo per esempio thread OSID 22C (uno con una NullReferenceException), CallStack è

 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::~GCHolderEEInterface+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  (System_Transactions_ni+0x738ec) System_Transactions_ni!_dyn_tls_init_callback  (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:  StackTrace (generated): SP IP Function 000000002759FC60 0000000000000001 mscorlib_ni!System.StubHelpers.StubHelpers.CheckCollectedDelegateMDA(IntPtr)+0x2 StackTraceString:  HResult: 80004003 

La traccia dello stack che hai pubblicato non sembra essere correlata al crash, in quanto è in uno stato di sospensione, in attesa di qualcosa.

Puoi dare un’occhiata al registro eventi di Windows, a volte CLR invia un messaggio significativo lì quando l’applicazione si blocca.

Inoltre, se si utilizza .Net 4 o versione successiva, è molto più comodo analizzare i dump dei processi gestiti in Visual Studio, poiché è ansible navigare facilmente tra i thread e persino creare un diagramma di thread composito che mostrerà solo parti diverse nei loro stack di chiamate .

Questa traccia di stack sembra innocente. Prova a abilitare le eccezioni Win32 in WinDbg. Ho visto le applicazioni gestite bloccarsi nelle loro chiamate Win32 sottostanti e WinDbg non mostrava correttamente l’origine del crash perché per impostazione predefinita le eccezioni Win32 non vengono gestite.