Cannot switch to managed thread in WinDbg

Question

I am exploring a minidump of an ASP.NET process with WinDbg, using SOS. If I list the managed threads I see a normal looking list of threads:

0:000> !threads
ThreadCount: 8
UnstartedThread: 0
BackgroundThread: 8
PendingThread: 0
DeadThread: 0
Hosted Runtime: no
                                              PreEmptive                                                Lock
       ID OSID        ThreadOBJ     State   GC     GC Alloc Context                  Domain           Count APT Exception
XXXX    1 12bc 00000000001441f0   1808220 Disabled 0000000140b10fc8:0000000140b12f20 000000000017f6e0     0 Ukn (Threadpool Worker)
XXXX    2 1334 0000000000152f90      b220 Enabled  0000000000000000:0000000000000000 0000000000121b90     0 Ukn (Finalizer)
XXXX    3 138c 000000000017b100    80a220 Enabled  0000000000000000:0000000000000000 0000000000121b90     0 Ukn (Threadpool Completion Port)
XXXX    4  81c 000000000017eb40      1220 Enabled  0000000000000000:0000000000000000 0000000000121b90     0 Ukn
XXXX    5  5e4 00000000001bccd0   880a220 Enabled  0000000000000000:0000000000000000 0000000000121b90     0 Ukn (Threadpool Completion Port)
XXXX    6 11e4 0000000004bee280   180b220 Disabled 0000000000000000:0000000000000000 0000000000121b90     0 Ukn (Threadpool Worker)
XXXX    7  73c 0000000004c267e0   180b220 Disabled 0000000140b0f158:0000000140b10f20 000000000017f6e0     3 Ukn (Threadpool Worker) System.StackOverflowException (000000007fff0138) (nested exceptions)
XXXX    8  21c 00000000001ad1c0   180b220 Enabled  0000000000000000:0000000000000000 0000000000121b90     0 Ukn (Threadpool Worker)

However, if I try to switch to thread 7 (the one with the exception), I get this:

0:000> ~7s
        ^ Illegal thread error in '~7s'

This happens when trying to switch to any managed thread. I'm not sure where to proceed from here. What I really need to do is see the stack trace from that managed thread.

Pinson

Answer 1

The output from !threads show three different IDs for threads (WinDbg's ID, the managed ID and the native ID). The one you need to use is the leftmost. As you can see all the threads in the dump have been marked as XXXX meaning that they are no longer available. This is normal, but I do find it odd that all the threads are marked like that. Was the dump taken during process shutdown?

UPDATE based on comment

You should definitely be able to get a useful dump with adplus -crash, but clearly everything is a bit messed up here since even the finalizer thread is being terminated. I noticed that one of the threads has a StackoverflowException, which is probably what you're after. To get that you could create dumps on first chance exceptions and see if you get something more useful that way. Adplus has a FullOnFirst flag for that.

Additional UPDATE

Okay, that is weird. A couple of other things to try.

• Attach to the process before the crash and just let it g. That should break in to the debugger on exceptions. If you want, you can set up an event to just print any exceptions to the console. Use sxe -c "!pe; !clrstack; gn" clr.

• Adplus used to be a vbs script but it was rewritten as an executable a while back. I've seen a few minor issues with the new version, but nothing like this. You could try the old script which is still available as adplus_old.vbs.

• Try procdump from sysinternals. It supports the same kind of dump options as Adplus (plus a few more).

Autoradiograph

Yes, the dump was taken during a crash (by running ADPlus -crash). Does this mean that I can't look at those threads at all? – Pinson

Thanks for your clear explanation! I just tried this again, using -fullonfirst, and a full dump was created. Unfortunately the result was the same, with all threads being unavailable. I also tried getting the exception directly from the heap, but the message, stack trace, etc. were all null. Do you have any idea why so little information is available? – Pinson

I had this same issue attaching to the process (using windbg). The process died and windbg effectively didnt give me any extra information besides what is given above. (eg !analyze -v, !pe all gave nothing extra, all threads were XXXX) - I also had a stackoverflow exception. So I thought I would try attaching to the process using VS2012 (after restarting my process) and to my surprise this gave me the stack trace i needed. – Gateway