Справочник по коду динамического дампа ядра
В этом разделе содержатся описания распространенных кодов динамического дампа ядра, которые могут возникнуть. Динамические дампы не сбрасывают ОС, но позволяют записывать сведения о памяти для ненормальных ситуаций, когда операционная система может продолжаться.
Примечание.
Этот раздел предназначен для программистов. Если вы являетесь клиентом, система которого отображала синий экран с кодом проверки ошибок, см. статью "Устранение неполадок синим экраном".
Динамический дамп ядра по сравнению с проверкой ошибок
При традиционной проверке ошибок компьютер сбрасывается и работа пользователя нарушается. Цель динамического дампа ядра — собрать данные для возникновения проблем с ненормальными ситуациями, но разрешить операционной системе продолжать работу. Это сокращает время простоя по сравнению с проверкой ошибок для "неустранимая", но сбои с высоким воздействием и зависания. Динамические дампы ядра используются, когда можно восстановить ОС до известного хорошего состояния. Например, сброс оборудования подсистемы, например видео/дисплей, USB3 или Wi-Fi, может позволить этим системам вернуться к известному хорошему состоянию с минимальным воздействием пользователя.
Динамический дамп ядра создает согласованный моментальный снимок памяти ядра и сохраняет его в файл дампа для дальнейшего анализа. Чтобы свести к минимуму влияние на производительность, методы копирования памяти используются для создания файла дампа в короткий период времени. Кроме того, сбор динамических дампов регулируется таким образом, чтобы влияние пользователей было сведено к минимуму.
Динамический дамп ядра действует для категории проблем, где что-то занимает много времени, и все же ничего технически не удается. Таймер наблюдателя можно инициализировать при запуске операции. Если срок действия сторожевой системы истекает до завершения операции в ожидаемое время, можно выполнить динамический дамп системы. Затем дампа можно проанализировать путем обхода стека вызовов и связанной цепочки ожидания для этой операции, чтобы изучить, почему она не завершается с ожидаемым временным интервалом.
Системные журналы работают хорошо, если что-то завершается сбоем, и владелец кода записал причину сбоя и может определить причину. Динамические дампы, использующие таймеры наблюдателя, пытаются поймать пути сбоя, которые не ожидались и регистрировались. Но как и при каждом сбое, системные журналы могут выявить другие проблемы, которые могут дать ключи к определенной первопричине сбоя.
Содержимое файла динамического дампа ядра
Как и в обычных файлах дампа, файлы динамического дампа могут содержать мини-дампы (с дополнительными данными) и полные дампы ядра, которые также могут включать память в режиме пользователя, аналогичную активным дампам. Общие сведения о содержимом файла дампа см. в разделе "Разновидности файлов дампа в режиме ядра". Некоторые динамические дампы пытаются захватывать мини-дампы, так как они предназначены для сбора определенных аппаратных данных, в то время как другие могут попытаться записать более крупный динамический дамп ядра.
Для производительности, размера файла и надежности записей дампа некоторые сведения не включаются, например страницы из автономного списка и кэша файлов.
Файлы динамического дампа обычно содержат страницы памяти, такие как:
- KdDebuggerBlock
- Список загруженных модулей
Для каждого процессора в дампах ядра записывается следующая информация:
- KiProcessorBlock
- PRCBs
- Текущий стек
- Текущая таблица каталогов страниц
- KI_USER_SHARED_DATA
- Образ ядра NTOS
- Изображение HAL
Дополнительные сведения в дампах ядра могут включать:
- Состояние потока и памяти
- Ведение журнала в памяти
Некоторые динамические дампы могут содержать страницы процесса в пользовательском режиме.
Дополнительные данные конкретного домена, например данные USB для сбоев USB, могут быть включены для некоторых динамических дампов.
Файл динамического дампа частичного ядра
Файл динамического дампа ядра может быть создан в ситуациях, когда динамический дамп не может надежно записывать все предполагаемые страницы памяти. Данные, захваченные в частичном дамле, фильтруются и определяются приоритетами, записывая страницы, содержащие важные данные, необходимые для создания допустимого дампа перед другими страницами. Например, страницы ядра определяются приоритетом по сравнению с пользовательскими страницами, когда динамический дампы включает в себя пользовательские страницы. В некоторых ситуациях недостаточно ресурсов для записи всех предполагаемых необязательных страниц памяти, поэтому память может быть отсутствует в файле дампа. Файл дампа по-прежнему должен быть распознан отладчиком WinDbg, но может отображать ошибки при попытке дампа памяти. Если отладчик отображает ошибку при попытке дампа памяти по адресу, можно использовать расширение !pte для проверки допустимости PTE для адреса. Это может помочь определить, является ли адрес памяти действительно недопустимым, или если страница действительна, но просто недоступна в файле дампа.
Анализ файлов динамического дампа
При возникновении динамического дампа файл дампа можно проанализировать с помощью методов, используемых для других файлов дампа памяти. Чтобы понять содержимое памяти во время сбоя, требуется знание регистров памяти процессора и программирования сборки.
Дополнительные сведения см. в разделе:
Использование WinDbg для отображения сведений о коде остановки динамического дампа
Если в этом разделе не отображается определенный код динамического дампа, используйте расширение !analyze в отладчике Windows (WinDbg) со следующим синтаксисом (в режиме ядра), заменив <code> динамический код дампа:
!analyze -show <code>
При вводе этой команды WinDbg отображает сведения о указанном коде динамического дампа. Если база номеров по умолчанию (radix) не равен 16, префикс <code> с 0x.
Укажите параметры кода динамического дампа команде !analyze, чтобы отобразить все доступные сведения о параметрах. Например, чтобы отобразить сведения о проверке ошибок 0x144 BUGCODE_USB3_DRIVER с параметром 1 0x3003, используйте !analyze -show 0x144 0x3003 , как показано здесь.
0: kd> !analyze -show 0x144 0x3003
BUGCODE_USB3_DRIVER (144)
This bugcheck usually happens when the USB3 core stack detects an invalid
operation being performed by a USB client. This bugcheck may also occur
due to hardware failure on a USB Boot Device.
Arguments:
Arg1: 0000000000003003, USB3_WER_BUGCODE_USBHUB3_DEVICE_ENUMERATION_FAILURE
A USB device failed enumeration.
Arg2: 0000000000000000, USBHUB3_LIVEDUMP_CONTEXT
Arg3: 0000000000000000, 0
Arg4: 0000000000000000, 0
Чтобы скачать WinDbg, см. статью "Средства отладки для Windows". Дополнительные сведения о средствах разработки WinDbg см. в статье "Начало работы с отладкой Windows".
Расположения файлов динамического дампа
Динамические дампы по умолчанию хранятся в каталоге C:\WINDOWS\LiveKernelReports.
Полные дампы: %systemroot%\LiveKernelReports\*.dmp
Мини-dumps: %systemroot%\LiveKernelReports\<ComponentName>\*.dmp
Структура каталогов используется для хранения динамических дампов для различных компонентов.
NDIS
PDCRevocation
PoW32kWatchdog
USBHUB3
WATCHDOG
Разделы реестра динамического дампа
Дополнительные сведения о параметрах конфигурации для системных отчетов динамического ядра см. в разделе "Параметры WER".
Использование PowerShell для запуска динамического дампа вручную
Откройте запрос PowerShell и администрирования.
Получите понятное имя StorageSubsystem с помощью команды Get-StorageSubSystem PowerShell.
C:\> Get-StorageSubSystem
FriendlyName HealthStatus OperationalStatus
------------ ------------ -----------------
Windows Storage on 10-2411-PC Healthy OK
- Используйте Get-StorageDiagnosticInfo для создания динамического дампа для приведенной выше подсистемы (а также других журналов диагностики). Дополнительные сведения см. в статье Get-StorageDiagnosticInfo.
C:\> Get-StorageDiagnosticInfo -StorageSubSystemFriendlyName "Windows Storage on 10-2411-PC" -IncludeLiveDump -DestinationPath C:\destinationfolder
- Выходные данные указывают на то, что запрашиваемые сведения создаются.
Gathering storage subsystem diagnostic information
Running
[oooooooooooo ]
- Дампа будет внутри
[DestinationPath]\localhost.
C:\> dir C:\destinationfolder\localhost\*.dmp
Directory: C:\destinationfolder\localhost
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 5/5/2016 1:08 PM 867135488 LiveDump.dmp
- Использование отладчика для запуска !analyze в файле дампа указывает, что это динамический код дампа LIVE_SYSTEM_DUMP (161).
Коды динамического дампа ядра
В следующей таблице приведены ссылки на коды динамических дампов ядра.
Эти коды остановки можно использовать для динамических дампов или для проверки устройства.
| Код | Имя. |
|---|---|
| 0x00000124 | WHEA_UNCORRECTABLE_ERROR |
| 0x00000144 | BUGCODE_USB3_DRIVER |
| 0x00000164 | WIN32K_CRITICAL_FAILURE |
См. также
Bug Check Code Reference (Справочник с кодами критических ошибок)