Тест поддержки Crashdump (LOGO)
Этот тест проверяет, поддерживает ли драйвер хранилища miniport в Windows создание файла дампа памяти после ошибки остановки системы.
Сведения о тесте
| Характеристики |
|
| Платформы |
|
| Поддерживаемые выпуски |
|
| Ожидаемое время выполнения (в минутах) | 45 |
| Категория | Сценарий |
| Время ожидания (в минутах) | 2700 |
| Требуется перезагрузка | false |
| Требуется специальная конфигурация | Да |
| Тип | automatic |
Дополнительная документация
Тесты в этой области функций могут содержать дополнительную документацию, включая предварительные требования, сведения о настройке и устранении неполадок, которые можно найти в следующих разделах:
- Дополнительная документация по Device.Storage
- Дополнительная документация по System.Fundamentals
- Дополнительная документация по System.Server
Выполнение теста
Перед запуском теста завершите настройку теста, описанную в требованиях к тестированию для типа проверяемого контроллера хранилища. Дополнительные сведения см. в статье Обзор тестирования адаптера хранилища или контроллера.
Для этого теста требуется дополнительное программное обеспечение и оборудование:
Тестируемое устройство
Жесткий диск размером не менее 20 ГБ, доступный в разделе C:.
Перед запуском теста необходимо также выполнить следующие предварительные требования.
Если в тестовой системе установлено подключение к Интернету, никаких действий выполнять не нужно.
Если у тестовой системы нет подключения к Интернету, создайте папку C:\Symbols , а затем скачайте и установите символы операционной системы Windows. Для этого выполните следующие действия:
Примечание
Для анализа файла дампа требуются символы. Сбой установки символов является наиболее распространенной проблемой установки теста, которая приводит к сбою этого теста. Версия символов должна соответствовать версии операционной системы, установленной на тестовом компьютере. Поэтому его необходимо скачать за пределами комплекта.
На компьютере с подключением к Интернету скачайте пакеты символов Windows. Дополнительные сведения см. в разделе Скачивание пакетов символов Windows.
Скопируйте файлы символов на тестовый компьютер в папку C:\Symbols . Так как символы могут быть большими, необходимо скопировать только ntkrnlmp.pdb (для x64 или Arm) или ntkrpamp.pdb (для x86).
Устранение неполадок
Общие сведения об устранении неполадок при тестировании HLK см. в разделе Устранение неполадок при тестировании Windows HLK.
Сведения об устранении неполадок см. в разделе Troubleshooting Device.Storage Testing.
Сообщение об ошибке "Не удалось загрузить правильные символы"
После перезагрузки тест проверяет файл дампа на правильность. Тест выполняет это так же, как и разработчик, с помощью отладчика ядра kd (см. раздел Скачивание и установка средств отладки для Windows). Для анализа файла дампа отладчику требуется доступ к символам (см. раздел Файлы символов). Это словарь для дампа. Они позволяют отладчику анализировать содержимое памяти (или аварийного файла) в отдельные модули (исполняемые файлы, библиотеки, драйверы и т. д.), функции в этих модулях и структуры данных. Как правило, если вы не можете проверить файл дампа с помощью отладчика ядра, тест не может пройти.
Для правильной работы теста необходимо предоставить отладчику символы. Если он не имеет правильных символов, он регистрирует предупреждения во время сбоев журнала на первом этапе анализа тестирования. Текущий механизм для этого — скачать общедоступные пакеты символов (см. раздел Скачивание пакетов символов Windows) и установить их на тестовом компьютере перед запуском теста. Если символы не установлены или не соответствуют тестируемой операционной системе, в журнале тестирования может появиться следующее сообщение:
(x) Не удалось загрузить правильные символы.
(i) Сведения об установке символов операционной системы см. в документации по WDK.
(i) Ваши символы также могут быть устаревшими. Обновите символы с помощью сервера символов Майкрософт.
Это сообщение фактически не приводит к сбою теста, так как в некоторых случаях дамп по-прежнему можно проанализировать с помощью частично совпадающих символов. Если тест продолжается и большее число тестовых случаев завершается сбоем с такими сообщениями, как Ошибка при получении адресов ... или Не удалось получить..., это означает, что отладчик не может проанализировать дамп из-за отсутствия символов. Один из способов обойти символ — дополнить локально установленный символ, упакованный символами, кэшируемыми с сервера символов Интернета. Чтобы кэшировать символы локально, выполните следующие действия.
Убедитесь, что вы уже создали аварийное завершение. Самый простой способ сделать это — запустить тест один раз и позволить ему завершиться ошибкой.
Убедитесь, что у вас установлены средства отладки. Опять же, самый простой способ сделать это — запустить тест один раз. Он установит средства в C:\Debuggers.
Откройте командную строку с повышенными привилегиями.
Введите следующую команду:
c:\Debuggers\kd -z c:\Windows\MEMORY.DMP -y SRV*C:\Symbols*http://msdl.microsoft.com/download/symbolsПри этом дамп загружается в отладчик ядра, используя удаленное хранилище символов в Майкрософт и локальный каталог C:\Symbols в качестве подчиненного хранилища для кэширования символов.
Убедитесь, что для файлов операционной системы, таких как NTOSKRNL и NTDLL, можно найти символы. Эти файлы необходимы для анализа дампа. Это нормально, если ошибки отображают символы загрузки для других модулей, таких как сторонние драйверы.
Теперь у вас должен быть запрос 0: kd>. В этой командной строке введите команду .reload /f. Эта команда заставляет отладчик загружать и кэшировать все символы для модулей, загруженных в дамп.
Чтобы выйти из отладчика, нажмите клавиши CTRL+B , а затем нажмите клавишу ВВОД.
Сообщение об ошибке "Размер файла подкачки слишком мал для целей полного дампа"
В случае сбоя нет уверенности в том, какие части операционной системы по-прежнему будут работать. Драйверы сети или файловой системы могли вызвать сбой; например, запрет доступа к структурам файловой системы для создания файла дампа или сети для удаленного хранения файла. Операционная система обрабатывает это с помощью файла, который ей уже известен (файл подкачки), и выполняет запись непосредственно в экстенты логического блока этого файла на диске. Процесс дампа записывает содержимое физической памяти в файл подкачки на системном диске (обычно c:\pagefile.sys). Файл подкачки должен быть достаточно большим, чтобы он содержал дамп. Самый большой дамп — это полный дамп, для которого требуется размер физической памяти (например, 4096) плюс один дополнительный мегабайт для хранения сведений о заголовке. Для тестирования требуется, чтобы пользователь настроит файл подкачки на соответствующий размер перед выполнением. Если размер файла подкачки недостаточен, тест регистрирует следующую ошибку на этапе инициализации:
(i) Проверка размера файла подкачки.
(x) Размер файла подкачки слишком мал для полного дампа.
(i) Размер файла подкачки: 330989568
(i) Размер физической памяти: 1073094656
(i) Настройте минимальный размер файла подкачки для физического размера ОЗУ + 1 МБ.
Отображается системная stop-ошибка (синий экран), но код проверки ошибок не E2
После проверки некоторых основных параметров тест установит драйвер, который используется для сбоя системы и перезагрузки системы. После перезагрузки тест изменяет параметры управления аварийным завершением (для полного дампа памяти), удаляет все старые файлы дампа и завершает работу системы. В точке сбоя система отобразит экран проверки ошибок (синий экран) с подробными сведениями о характере сбоя. Тип проверки ошибок должен быть MANUALLY_INITIATED_CRASH (e2). Если здесь отображается что-то еще, это означает, что во время записи файла дампа произошла вторая проверка ошибок. Для этого необходимо подключить отладчик ядра к тестовму клиенту и отладить драйвер адаптера хранилища.
В журнале теста выводится сообщение об ошибке "Файл дампа используется другим процессом. HRESULT: 0x80070020"
После записи файла дампа тестовый компьютер должен автоматически перезагрузиться. После загрузки после сбоя операционная система обнаружит наличие сведений о дампе в файле подкачки и начнет процесс записи дампа. Этот процесс выполняется асинхронно во время загрузки компьютера и даже после входа пользователя. Во время этого процесса можно просмотреть ход выполнения, проверив размер файла дампа (C:\windows\memory.dmp) или просмотрев процесс в диспетчере задач (werfault.exe). Тест часто выполняется одновременно с этим процессом, пытаясь получить доступ к тому же файлу дампа. В этом случае в журнале будут отображаться следующие сообщения:
(i) Подключение к DumpFile: C:\Windows\MEMORY. DMP
(i) Файл дампа используется другим процессом. HRESULT: 0x80070020
(i) Обычно memory.dmp по-прежнему записывается из-за большого объема ОЗУ, повторите попытку через 5 минут.
Затем тест должен повторить попытку доступа к файлу. Если код сообщения об ошибке отличается или изменяется (например, 0x80070002 : ERROR_FILE_NOT_FOUND), это означает, что файл не удалось записать на диск. В первую очередь проверка полезных отладочных сведений является журнал системных событий. Чтобы просмотреть журнал событий, нажмите кнопку Пуск, нажмите кнопку Выполнить, а затем введите Compmgmt.msc. В окне управления компьютером выберите Управление компьютером\System Tools\Просмотр событий\System. Просмотрите список событий для события с исходной ошибкой BugCheck. Наиболее распространенной причиной отсутствия файла дампа является нехватка свободного места на диске. Раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash содержит сведения о последнем сбое (перед перезагрузкой), включая файл частичного дампа, если он был создан. Это может быть полезно при отладке других проблем, связанных с отсутствующим дампем.
Дополнительные сведения
Crashdump — это механизм, при котором операционная система вызывает драйвер адаптера хранилища для записи содержимого памяти в файл дампа после ошибки остановки системы. Из-за характера ошибки остановки системы операционная система не может делать никаких предположений о стабильности системы. Таким образом, драйверам хранилища доступно очень мало системных служб. Тест поддержки crashdump проверяет, может ли драйвер адаптера хранилища по-прежнему работать в этих средах с ограниченными ограничениями, и выполняет операции ввода-вывода для успешной записи в дамп.
Операционная система Windows позволяет создавать три разных типа файлов дампа памяти:
Полное
Ядро
Мини
Тест тестирует типы файлов ядра и мини-дампа. Дополнительные сведения об этих типах файлов дампа см. в разделе Файлы дампа в режиме ядра.
Тест завершит следующую последовательность операций:
Установите средства отладки для Windows в каталог %SystemDrive%\Debuggers и инициализируйте систему.
Установите тестовый драйвер для имитации сбоя.
Задайте размер файла подкачки.
Имитация системных стоп-ошибок (синий экран) с помощью кода проверки ошибок 0x000000E2.
Перезагрузите систему и автоматически перезапустите тест.
Проверьте предыдущий сбой, проанализировав файл дампа памяти с помощью отладчика ядра, и убедитесь, что дамп был записан правильно.
Повторите шаги 4–6 для каждого типа файла дампа.
Синтаксис команды
| Get-Help | Описание |
|---|---|
Crashdumptest.exe -c |
Удалите все прошлые сбои. |
crashdumptest.exe -dtm -y [SymbolsDirectory] -ypass |
Инициализируйте тест. |
crashdumptest.exe -autorun -y [SymbolsDirectory] -dtm" |
Запускает тест. |
Список файлов
| Параметр команды | Описание |
|---|---|
Crashdumptest.exe |
[TestBinRoot]\nttest\driverstest\storage\wdk\ |
BugCheck.sys |
[TestBinRoot]\nttest\driverstest\storage\wdk\ |
Параметры
| Имя параметра | Описание параметра |
|---|---|
| ОтладчикКаталог | Каталог для установки отладчиков. |
| SymbolsDirectory | Каталог, в котором уже установлены символы. |
| LLU_LclAdminUsr | Учетная запись пользователя для запуска теста. |
| LLU_NetAccessOnly | Учетная запись пользователя для доступа к тестовой общей папке. |
| PagefileSize | Размер файла подкачки в МБ (поддерживает формат mem+N) |