Поиск неудачного процесса
Перед поиском неудачного процесса убедитесь, что вы находитесь в контексте принимающего процессора. Чтобы определить принимающий процессор, используйте расширение !pcr для каждого процессора и ищет процессор, для которого загружен обработчик исключений. Обработчик исключений обработчика принятия имеет адрес, отличный от 0xFFFFFFFF.
Например, так как адрес NtTib.ExceptionList на этом процессоре 0xFFFFFFFF, это не процессор с неудачным процессом:
0: kd> !pcr
PCR Processor 0 @ffdff000
NtTib.ExceptionList: ffffffff
NtTib.StackBase: 80470650
NtTib.StackLimit: 8046d860
NtTib.SubSystemTib: 00000000
NtTib.Version: 00000000
NtTib.UserPointer: 00000000
NtTib.SelfTib: 00000000
SelfPcr: ffdff000
Prcb: ffdff120
Irql: 00000000
IRR: 00000000
IDR: ffffffff
InterruptMode: 00000000
IDT: 80036400
GDT: 80036000
TSS: 80257000
CurrentThread: 8046c610
NextThread: 00000000
IdleThread: 8046c610
DpcQueue:
Однако результаты процессора 1 совершенно отличаются. В этом случае значение NtTib.ExceptionList равно f0823cc0, а не 0xFFFFFFFF, указывая, что это процессор, на котором произошло исключение.
0: kd> ~1
1: kd> !pcr
PCR Processor 1 @81497000
NtTib.ExceptionList: f0823cc0
NtTib.StackBase: f0823df0
NtTib.StackLimit: f0821000
NtTib.SubSystemTib: 00000000
NtTib.Version: 00000000
NtTib.UserPointer: 00000000
NtTib.SelfTib: 00000000
SelfPcr: 81497000
Prcb: 81497120
Irql: 00000000
IRR: 00000000
IDR: ffffffff
InterruptMode: 00000000
IDT: 8149b0e8
GDT: 8149b908
TSS: 81498000
CurrentThread: 81496d28
NextThread: 00000000
IdleThread: 81496d28
DpcQueue:
Если вы находитесь в правильном контексте процессора, расширение !process отображает текущий запущенный процесс.
Наиболее интересными частями дампа процесса являются:
Время (большое значение указывает, что процесс может быть виновным).
Число дескрипторов (это число в скобках после ObjectTable в первой записи).
Состояние потока (многие процессы имеют несколько потоков). Если текущий процесс неактивен, скорее всего, компьютер действительно неактивен или завис из-за какой-то необычной проблемы.
Хотя использование расширения !process 0 7 является лучшим способом найти проблему в зависаемой системе, иногда это слишком много информации для фильтрации. Вместо этого используйте !process 0 0 , а затем !process on the process handle for CSRSS и любые другие подозрительные процессы.
При использовании !process 0 7 многие потоки могут быть помечены как "стек ядра не резидент", так как эти стеки выстраиваются. Если эти страницы по-прежнему находятся в кэше, который находится в переходе, вы можете получить дополнительные сведения с помощью декодептов кэша до !process 0 7:
kd> .cache decodeptes
kd> !process 0 7
Если вы можете определить неудачный процесс, используйте процесс !process>< 7, чтобы отобразить стеки ядра для каждого потока в процессе. Эти выходные данные могут определить проблему в режиме ядра и показать, что вызывает подозрительный процесс.
Помимо !process, следующие расширения могут помочь определить причину неответствующего компьютера:
| Расширение | Действие |
|---|---|
Определяет потоки, готовые к выполнению, в порядке приоритета. |
|
Идентифицирует любые блоки удерживаемого ресурса, если существует взаимоблокировка с истечением времени ожидания розничной торговли. |
|
Проверяет использование виртуальной памяти. |
|
Определяет, является ли один тип выделения пула непропорционально большим (требуется тег пула). |
|
Проверяет состояние физической памяти. |
|
Проверяет допустимость кучы. |
|
Выполняет поиск непагированных пулов для активных irPs. |
Если предоставленные сведения не указывают на необычное условие, попробуйте установить точку останова в ntoskrnl! KiSwapThread , чтобы определить, застрял ли процессор в одном процессе или если он по-прежнему планирования других процессов. Если он не застрял, установите точки останова в общих функциях, например NtReadFile, чтобы определить, завис ли компьютер в определенном пути кода.