Не удается переключиться на управляемый поток в WinDbg

Я изучаю minidump процесса ASP.NET с помощью WinDbg, используя SOS. Если я перечисляю управляемые потоки, я вижу нормальный список потоков:

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'

Это происходит при попытке переключения на любой управляемый поток. Я не знаю, с чего начать. Что мне действительно нужно сделать, так это увидеть трассировку стека из этого управляемого потока.

Ответ 1

Вывод из !threads показывает три разных идентификатора для потоков (WinDbg ID, управляемый идентификатор и собственный идентификатор). Тот, который вам нужно использовать, самый левый. Как видите, все потоки в дампе отмечены как XXXX, что означает, что они больше не доступны. Это нормально, но мне кажется странным, что все потоки отмечены как это. Был ли сброс во время остановки процесса?

ОБНОВЛЕНИЕ на основе комментария

Вы, безусловно, сможете получить полезную дамп с adplus -crash, но, очевидно, все здесь немного перепутано, так как поток финализатора заканчивается. Я заметил, что у одного из потоков есть исключение StackoverflowException, которое, вероятно, вам нужно. Чтобы получить это, вы можете создавать дампы при исключении первого шанса и посмотреть, есть ли у вас что-то более полезное. Для этого Adplus имеет флаг FullOnFirst.

Дополнительный UPDATE

Хорошо, это странно. Еще пару вещей, чтобы попробовать.

Присоединитесь к процессу перед сбоем и просто отпустите g. Это должно вступить в отладчик на исключениях. Если вы хотите, вы можете настроить событие, чтобы просто распечатать любые исключения на консоли. Используйте sxe -c "!pe; !clrstack; gn" clr.
Adplus использовался как vbs script, но он был переписан как исполняемый файл a while назад. Я видел несколько мелких проблем с новой версией, но ничего подобного. Вы можете попробовать старый script, который по-прежнему доступен как adplus_old.vbs.
Попробуйте procdump из sysinternals. Он поддерживает такие же параметры дампа, как Adplus (плюс еще несколько).