CODEWITHSUNDEEP
c#debuggingexceptionwindbg
SinisterMJ
SinisterMJ

Reputation: 3509

Crash dump with unknown origin

I have my application crashing with following CallStack on the error (from 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

This is a managed application, and according to WinDbg there are 61 processes / threads running from that application. In WinDbg, when typing !threads, it says there are no export threads found. It doesn't say what error caused this (in Visual Studio 2010, it says a NullReferenceException).

I am going nuts, I thought this was related to a USB Serial Controller, but I put that into another application, and it still crashes (although not with 100% as earlier, but rather with like 80%).

This exception / error completely eludes me, and I can't figure out how to fix it.

Update, using .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

The communication exception is being caught (this happens, when the WCF Host is not up, and may happen on disconnecting the hardware). I doubt that this is the cause for my crash since in Visual Studio it always crashes with a NullReferenceException, but no CallStack / Disassembly available.

When I look at for example thread OSID 22C (one with a NullReferenceException), the CallStack is

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

Upvotes: 4

Views: 2647

Answers (2)

StarPilot
StarPilot

Reputation: 2272

This stack trace looks innocent. Try enabling Win32 exceptions in WinDbg. I have seen managed applications crashing in their underlying Win32 calls, and WinDbg wouldn't show the source of the crash correctly because by default Win32 exceptions aren't handled.

Upvotes: 1

alex
alex

Reputation: 12654

The stack trace you've posted does not seem to be related to crash, as it is in a sleeping state, waiting for something.

You can take a look at windows event log, sometimes CLR places a meaningful message there when application crashes.

Also, if you are using .Net 4 or higher, it is much more convenient to analyze managed process dumps in visual studio, as you can easily navigate between threads and even build a composite thread diagram that will show only different parts in their call stacks.

Upvotes: 4

Related Questions