Debug a .NET dump using windbg

Question

I made a dump (using -ma option and a trigger for high CPU in procdump.exe) of a .NET process and I want to see the clues in a running thread about what my code was doing. I get this:

*** procdump  -ma -c 65 -s 2 -n 3 service.exe
*** Process exceeded 65% CPU for 2 seconds. Thread consuming CPU: 4396 (0x112c)'

The indicated thread was executing that at the dump time:

0:022> k
ChildEBP RetAddr  
WARNING: Frame IP not in any known module. Following frames may be wrong.
0990f104 040666ab 0x40656f8
0990f124 04066465 0x40666ab
0990f14c 040655e2 0x4066465
0990f160 040651f4 0x40655e2
0990f178 04065032 0x40651f4
0990f1a4 04064ee5 0x4065032
0990f1c8 04062705 0x4064ee5
0990f20c 04062512 0x4062705
*** WARNING: Unable to verify checksum for System.ServiceModel.ni.dll
0990f31c 6caf0cab 0x4062512
0990f3d0 6caeebf6 System_ServiceModel_ni+0x3b0cab
0990f43c 6caee962 System_ServiceModel_ni+0x3aebf6
0990f474 6caee5cb System_ServiceModel_ni+0x3ae962
0990f488 6caed407 System_ServiceModel_ni+0x3ae5cb
0990f4d4 6cb07a4d System_ServiceModel_ni+0x3ad407
0990f4f4 6d24c989 System_ServiceModel_ni+0x3c7a4d
0990f510 6d24c966 System_ServiceModel_ni+0xb0c989
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0990f584 6f8c4096 System_ServiceModel_ni+0xb0c966
0990f598 6f8ee1a0 mscorlib_ni+0x364096
0990f5b4 6f8ed949 mscorlib_ni+0x38e1a0
0990f604 6f8ed7f5 mscorlib_ni+0x38d949
0990f614 705a3315 mscorlib_ni+0x38d7f5
0990f668 705a6cdf clr!CallDescrWorkerWithHandler+0x6b
0990f6dc 70741281 clr!MethodDescCallSite::CallTargetWorker+0x152
0990f754 706082f7 clr!QueueUserWorkItemManagedCallback+0x1f
0990f76c 70608365 clr!Thread::DoExtraWorkForFinalizer+0x1ca
0990f814 70608432 clr!Thread::DoExtraWorkForFinalizer+0x256
0990f870 7060849f clr!Thread::DoExtraWorkForFinalizer+0x615
0990f894 70741219 clr!Thread::DoExtraWorkForFinalizer+0x6b2
0990f948 70740b31 clr!ManagedPerAppDomainTPCount::DispatchWorkItem+0xc5
0990f95c 70741711 clr!ThreadpoolMgr::ExecuteWorkRequest+0x42
0990f9c4 707236f8 clr!ThreadpoolMgr::WorkerThreadStart+0x353
0990fddc 76f9336a clr!Thread::intermediateThreadProc+0x4d
0990fde8 77bd9f72 kernel32!BaseThreadInitThunk+0xe
0990fe28 77bd9f45 ntdll!__RtlUserThreadStart+0x70
0990fe40 00000000 ntdll!_RtlUserThreadStart+0x1b

The problems is that I don't see any of "my code" in the stack, while threadpool thread executes, to have a clue at what it was doing.

Kindrakindred

Answer 1

Unfortunately .net doesn't play by the rules laid down by the Windows division, it does its own thing (like a lot of the stuff the Developer division at Microsoft did). As a result, you don't get the debugging information written out the same as for native applications.

Its a cause of much head-shaking from me when I use windbg, spy or dumpbin - tools that were invaluable in the past. But never mind, you can get something out of it:

First you need to load the sos info, then you can use !clrstack to see the .net stack trace.

.loadby sos mscorwks (for .net 2)
.loadby sos clr (for .net 4, of course :( )
!clrstack

There's a cheat sheet with some useful commands.

Decarbonate

Indeed, using Son of Strike is essential to making sense of .NET in WinDbg. – Woodbridge

Yeah, I would rather say "save our ..." because without it you are clueless in .net apps – Kindrakindred

Answer 2

I don't think "k" displays the call stacks from all threads. Did you try ~* k ?

Volny

I displayed the stack for high cpu thread. that thread id was set by the procdump when dumping – Kindrakindred