Справочник по коду динамического дампа ядра
В этом разделе содержатся описания распространенных кодов динамического дампа ядра, которые могут возникнуть. Динамические дампы не сбрасывают операционную систему, но позволяют записывать сведения о памяти в ненормальных ситуациях, когда операционная система может продолжить работу.
Примечание
Этот раздел предназначен для программистов. Если вы являетесь клиентом, система которого отображает синий экран с ошибкой проверка коде, см. статью Устранение ошибок синего экрана.
Динамический дамп ядра по сравнению с проверка ошибок
При традиционной проверка ошибок компьютер сбрасывается и работа пользователя прерывается. Целью динамического дампа ядра является сбор данных, чтобы устранить неполадки в нештатной ситуации, но позволить ОС продолжить работу. Это сокращает время простоя по сравнению с проверка ошибок для "неустранимых", но с высокой степенью влияния сбоев и зависаний. Динамические дампы ядра используются, когда можно восстановить ОС до известного работоспособного состояния. Например, сброс оборудования подсистемы, такой как видео/дисплей, USB3 или Wi-Fi, может позволить этим системам вернуться в известное состояние работоспособности с минимальным воздействием на пользователя.
Динамический дамп ядра создает согласованный snapshot памяти ядра и сохраняет его в файл дампа для последующего анализа. Чтобы свести к минимуму влияние на производительность, используются методы копирования памяти для создания файла дампа в течение короткого периода времени. Кроме того, коллекция динамических дампов регулируется, чтобы свести к минимуму влияние на пользователей.
Динамический дамп ядра эффективен для категории проблем, в которых что-то занимает много времени, а технически ничего не завершается сбоем. Таймер наблюдения можно инициализировать при запуске операции. Если срок действия объекта наблюдения истекает до завершения операции с в ожидаемое время, можно создать динамический дамп системы. Затем дампа можно проанализировать, обходя стек вызовов и связанную цепочку ожидания для этой операции, чтобы выяснить, почему она не завершается с ожидаемым интервалом времени.
Системные журналы работают хорошо, если что-то завершается сбоем, а владелец кода записал причину сбоя и может определить причину. Динамические дампы, использующие таймеры наблюдения, пытаются перехватывать пути сбоев, которые не были ожидаемы и зарегистрированы. Но, как и при каждом сбое, системные журналы могут выявлять другие проблемы, которые могут дать ключ к конкретной первопричине сбоя.
Содержимое файла динамического дампа ядра
Как и в случае с обычными файлами дампа, динамические файлы дампа могут содержать минидампы (со вторичными данными) и полные дампы ядра, которые также могут включать память в пользовательском режиме, аналогично активным дампам. Общие сведения о содержимом файла дампа см. в разделе Варианты файлов дампа Kernel-Mode. Некоторые динамические дампы пытаются захватывать только минидампы, так как они предназначены для сбора конкретных данных, связанных с оборудованием, в то время как другие могут попытаться захватить более крупный динамический дамп ядра.
Для производительности, размера файла и надежности записи дампа некоторые сведения не включаются, например страницы из списка stand by и файловых кэшей.
Динамические файлы дампа обычно содержат страницы памяти, такие как:
- KdDebuggerBlock
- Список загруженных модулей
Для каждого процессора в дампах ядра записываются следующие сведения:
- KiProcessorBlock
- PRCB
- Текущий стек
- Таблица каталогов текущей страницы
- KI_USER_SHARED_DATA
- Образ ядра NTOS
- Образ HAL
Дополнительные сведения в дампах ядра могут включать:
- Состояние потока или памяти
- Ведение журнала в памяти
Некоторые динамические дампы могут содержать страницы процессов в пользовательском режиме.
Для некоторых динамических дампов могут быть включены дополнительные данные, относящиеся к домену, например данные usb для сбоев USB.
Файл динамического дампа частичного ядра
Частичный файл динамического дампа ядра может быть создан в ситуациях, когда динамический дамп не может надежно записать все предполагаемые страницы памяти. Сведения, которые записываются в частичном дампе, фильтруются и расставляются по приоритету путем записи страниц, содержащих важные данные, необходимые для создания допустимого дампа перед другими страницами. Например, страницы ядра имеют приоритет над пользовательскими страницами, если динамический дамп включает пользовательские страницы. В некоторых ситуациях недостаточно ресурсов для записи всех предполагаемых необязательных страниц памяти, поэтому в файле дампа может отсутствовать память. Файл дампа по-прежнему должен распознаваться отладчиком WinDbg, но при попытке дампа памяти могут отображаться ошибки. Если отладчик отображает ошибку при попытке дампа памяти по адресу, можно использовать расширение !pte, чтобы проверка, является ли допустимым PTE для адреса. Это поможет определить, действительно ли адрес памяти недопустим или страница действительна, но просто недоступна в файле дампа.
Анализ динамических файлов дампа
При возникновении динамического дампа файл дампа можно проанализировать, используя те же методы, что и для других файлов дампа памяти. Чтобы понять содержимое памяти во время сбоя, необходимо знание регистров памяти процессора и программирования сборок.
Дополнительные сведения см. в разделе:
Использование WinDbg для отображения сведений о коде остановки динамического дампа
Если конкретный код динамического дампа не отображается в этом разделе, используйте расширение !analyze в отладчике Windows (WinDbg) со следующим синтаксисом (в режиме ядра), заменив <code> на код динамического дампа:
!analyze -show <code>
Ввод этой команды приводит к тому, что WinDbg отобразит сведения об указанном коде динамического дампа. Если числовой базой по умолчанию (радиксом) не является 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
Минидампы: %systemroot%\LiveKernelReports\<ComponentName>\*.dmp
Структура каталогов используется для хранения динамических дампов для различных компонентов.
NDIS
PDCRevocation
PoW32kWatchdog
USBHUB3
WATCHDOG
Разделы реестра динамического дампа
Дополнительные сведения о параметрах конфигурации для создаваемых системой динамических отчетов ядра см. в разделе Параметры WER.
Использование PowerShell для запуска динамического дампа вручную
Откройте командную строку PowerShell для администратора.
Получите понятное имя StorageSubsystem с помощью команды PowerShell Get-StorageSubSystem .
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 (Справочник с кодами критических ошибок)
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по