Exqueue показывает только ожидающие рабочие потоки на дампе принудительной памяти

Я отлаживаю проблему зависания/зависания системы, вызывая полный дамп памяти (ctrl + scrl + scrl method), и я не понимаю некоторые данные. !Exqueue показывает только ожидающие рабочие потоки на дампе принудительной памяти

Когда я бег exqueue 6 Я вижу 6 Critical, 8 Отложенных и 1 гиперкритической нить, но каждый из них содержит подобные стек только с следующими вызовами:

nt!KiSwapContext+0x7a 
nt!KiCommitThreadWait+0x1d2 
nt!KeRemoveQueueEx+0x323 
nt!ExpWorkerThread+0xe9 
nt!PspSystemThreadStartup+0x5a 
nt!KxStartSystemThread+0x16

Насколько мне известно, все эти темы, которые были созданы но не дали никакой работы, правильно?

Это то, что на самом деле происходит в системе во время дампа, или это просто последствия форсирования дампа с помощью этого метода?

Это также почему единственные бегущие потоки на самом деле являются intelppm под Idle PID и точкой останова?

     [fffff80003617180 Idle] 
    0.000000 fffff80003616cc0 ffff8835 RUNNING nt!KeBugCheckEx 
    0.000000 fffff880009f9fc0 ffff92bb RUNNING intelppm!MWaitIdle+0x19 
    0.000000 fffff88002f6ffc0 ffff9191 RUNNING intelppm!MWaitIdle+0x19 
    0.000000 fffff88002fe1fc0 ffff93c4 RUNNING intelppm!MWaitIdle+0x19

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

Любая помощь будет оценена по достоинству.

источник

2016-03-09 GamerJ5

! Exqueue показывает потоки, которые находятся в состоянии ожидания в очереди рабочего потока, будет проблемой только в том случае, если текущее значение> максимум (отображение старого ветрового индикатора) или коэффициент параллелизма> 1 (новый дисплей windbg), все ожидающие потоки, вероятно, будут иметь тот же стек – blabb

Awesome, спасибо. Таким образом, по существу очередь работы системы выглядит так, будто у нее действительно ничего не было, ожидая, что указывает на то, что другие потоки работают гладко - не так ли? – GamerJ5

это означает, что проблема не находится в очереди рабочего потока. Некоторый поток, который не является рабочим потоком, может не работать плавно и/или блокировка, существует несколько команд вроде блокировок и т. Д., Которые вы можете использовать для исследования – blabb

Во время загрузки система автоматически создаст ряд системных потоков. Позже система может создавать больше системных потоков, если она сочтет это необходимым на основе нагрузки. Системные потоки, которые вы показываете, сейчас не имеют ничего общего, но они, возможно, были заняты раньше. Я не думаю, что (6, 8, 1) нити указывают на что-то ненормальное. нагрузки.

3 потока, которые выполняли intelppm, простаивали, а затем, скорее всего, рухнули.

Могут быть другие причины, по которым система становится невосприимчивой, чем высокая нагрузка. Иногда все, что требуется, - это одна нить, которая зашла в тупик. Поэтому, возможно, посмотрите, что делали другие потоки, и если у кого-то из них есть «подозрительный» стек вызовов. Кроме того, ядро 0 (которое выполнило ошибку) сделало что-нибудь особенное, прежде чем выполнить bugcheck?

источник

2016-03-10 08:58:18 Rhansen

Это один из элементов, из-за которого я подозреваю, что свалка клавиатуры мутная вода. Отображение стека для ~ 0 содержит только тот поток, который запускался и заканчивался кодом дампа клавиатуры. ! ready ничего не показывает, и! running показывает только те холостые потоки (которые я также считаю подозрительными). Очевидно, что-то еще работало на 0, когда ctrl-scrl-scrl был поражен, и этот поток был достаточно низким IRQL, что он заблокировал его. Но как это прослеживается? – GamerJ5

Итак, стек для ядра 0 начался с «nt! KiIdleLoop» и попал в «bugcheck»? Я не думаю, что клавиатура crashdump каким-то образом загрязняет воду. Существует прерывание и USB-драйвер очереди DPC, который заканчивает вызов bugcheck. Похоже, что нить на ядре 0 тоже не работает! – Rhansen

Итак, прерывание должно происходить в потоке, запущенном в то время, а не в создании нового потока, который блокирует то, что было запущено?Таким образом, если что-то действительно работает, стек для этого потока должен быть прерван USBPORT Xdpc_Worker? – GamerJ5

Exqueue показывает только ожидающие рабочие потоки на дампе принудительной памяти

ответ

Смежные вопросы