Csharp/C#教程:起源不明的故障转储分享


起源不明的故障转储

我的应用程序崩溃跟随CallStack出错(来自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中,当键入!threads时,它表示没有找到导出线程。 它没有说明是什么错误造成的(在Visual Studio 2010中,它表示NullReferenceException)。

我很疯狂,我认为这与USB串行控制器有关,但我把它放到另一个应用程序中,它仍然崩溃(尽管不像之前那样100%,而是80%)。

这个exception/错误完全没有我,我无法弄清楚如何解决它。

使用.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 

正在捕获通信exception(当WCF主机未启动时,会发生这种情况,并且可能在断开硬件连接时发生)。 我怀疑这是我崩溃的原因,因为在Visual Studio中它总是崩溃并出现NullReferenceException,但没有可用的CallStack / Disassembly。

当我查看例如线程OSID 22C(一个带有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 

您发布的堆栈跟踪似乎与崩溃无关,因为它处于hibernate状态,等待某些事情。

您可以查看Windows事件日志,有时CLR会在应用程序崩溃时在其中放置有意义的消息。

此外,如果您使用的是.Net 4或更高版本,在Visual Studio中分析托管进程转储会更方便,因为您可以轻松地在线程之间导航,甚至可以构建一个复合线程图,它只显示其调用堆栈中的不同部分。

这个堆栈跟踪看起来很无辜。 尝试在WinDbg中启用Win32exception。 我已经看到托管应用程序在其基础Win32调用中崩溃,并且WinDbg不会正确显示崩溃的来源,因为默认情况下不会处理Win32exception。

上述就是C#学习教程:起源不明的故障转储分享的全部内容,如果对大家有所用处且需要了解更多关于C#学习教程,希望大家多多关注—计算机技术网(www.ctvol.com)

本文来自网络收集,不代表计算机技术网立场,如涉及侵权请点击右边联系管理员删除。

如若转载,请注明出处:https://www.ctvol.com/cdevelopment/952135.html

(0)
上一篇 2021年11月19日
下一篇 2021年11月19日

精彩推荐