logo标签列表

来源未知的崩溃转储文件

c#debuggingexceptionwindbg
4

我的应用程序出现崩溃，并在错误信息中显示以下的调用堆栈(来自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串口控制器有关，但我把它放到另一个应用程序中，它仍然会崩溃（虽然不像之前那样严重，而是大约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）时，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<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
你有任何会崩溃的代码吗？还是说你想要找出这样的代码？ - ThaMe90
这个堆栈跟踪看起来很无辜。你在WinDbg中启用了Win32异常吗？我曾经见过一些托管应用程序在其Win32调用中崩溃，而WinDbg不会显示崩溃的源，因为默认情况下Win32不受WinDbg处理。 - StarPilot
1
关于无法运行 !threads 命令，您是否在运行该命令之前先加载了 SOS？（通过 .loadby sos clr 用于 .NET4 或 .loadby sos mscorwks 用于 .NET2）？ - Iridium
哦，谢谢你提供的.loadby提示。现在大约有15-20个线程显示出了NullReferenceException异常。 - SinisterMJ
1
如果可能，请在WinDbg下重新运行您的应用程序并启用CLR异常断点。等待错误发生，然后您就能够使用 !pe 和 !clrstack -a 来显示带有参数（包括传递给MDA的IntPtr）的调用堆栈。 - Iridium
显示剩余4条评论
2个回答
4

您所发布的堆栈跟踪似乎与崩溃无关，因为它处于睡眠状态，等待某些东西。

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

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

1
这个堆栈跟踪看起来很无辜。尝试在WinDbg中启用Win32异常。我曾经见过托管应用程序在其底层的Win32调用中崩溃，而WinDbg不会正确显示崩溃源，因为默认情况下不处理Win32异常。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接