我正在使用SOS使用WinDbg探索ASP.NET进程的minidump。如果我列出托管线程，我会看到正常的线程列表：
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)
但是，如果我尝试切换到线程7（具有例外的那个），我得到这个：
0:000> ~7s
^ Illegal thread error in '~7s'
尝试切换到任何托管线程时会发生这种情况。我不知道从哪里开始。我真正需要做的是从该托管线程中查看堆栈跟踪。
答案 0 :(得分：10)
!threads的输出显示了三个不同的线程ID（WinDbg的ID，托管ID和本机ID）。你需要使用的是最左边的。正如您所看到的，转储中的所有线程都已标记为XXXX，这意味着它们不再可用。这是正常的，但我觉得奇怪的是所有线程都标记为这样。在流程关闭期间是否进行了转储？
根据评论更新
你绝对应该能够使用adplus -crash获得一个有用的转储，但显然一切都搞砸了，因为即使终结器线程也被终止了。我注意到其中一个线程有一个StackoverflowException，这可能就是你所追求的。为此，你可以在第一次机会异常时创建转储，看看你是否能以这种方式获得更多有用的东西。 Adplus有一个FullOnFirst标志。
额外更新
好的， 很奇怪。还有其他一些尝试。
在崩溃前附加到流程，然后让它g。这应该在异常时打入调试器。如果需要，可以设置事件以仅打印控制台的任何异常。使用sxe -c "!pe; !clrstack; gn" clr。
Adplus曾经是一个vbs脚本，但它在一段时间后被重写为可执行文件。我看过新版本的一些小问题，但没有这样的。您可以尝试使用仍然可用的旧脚本adplus_old.vbs。
从sysinternals尝试procdump。它支持与Adplus相同类型的转储选项（以及更多）。