Я когда-то писал в блоге про kdfe.cmd и BlueScreenView. Эти решения по-разному и со своими недостатками пытались решить задачу определения драйвера, вызвавшего критическую ошибку. Теперь они не нужны.
Автор утилиты MiniDumper ограничил ее загрузку и работу для пользователей из РФ и РБ без VPN.
Сегодня я расскажу про утилиту MiniDumper (скачать), которая создавалась с учетом пожеланий специалистов, оказывающих поддержку в форуме устранения критических ошибок Windows. Ее автор – участник форума OSZone simplix.
[+] Сегодня в программе
Сведения для обычных пользователей
При запуске утилита автоматически анализирует найденные в системе дампы за последний год и открывает отчет в текстовом редакторе.
Вы также можете перетащить на исполняемый файл утилиты отдельный дамп или папку с дампами.
Дамп: 101017-7753-01.dmp (10.10.2017 17:57) Код: 0x3B - SYSTEM_SERVICE_EXCEPTION Процесс: avp.exe, вероятно вызвано: NETIO.SYS Сторонние модули в стеке: klwtp.sys Сторонние модули в Raw-стеке: nvlddmkm.sys, klim6.sys, klwtp.sys, adgnetworkwfpdrv.sys, klflt.sys, klif.sys
С именем драйвера уже можно идти в гуглояндекс. Если дело в сторонней программе или драйвере, надо начинать с их удаления / обновления. В примере выше – драйвер ЛК.
В более сложных случаях следует обращаться в форум.
Сведения для специалистов поддержки
Ряд фич MiniDumper реализован по просьбам моего коллеги по форуму Petya V4sechkin. Поэтому утилита очень удобна для техподдержки.
Возможности утилиты
MiniDumper работает в Windows 7 (с обновлениями) и более новых ОС. В состав программы входят Debugging Tools for Windows. Все команды, которые передаются отладочной утилите, формируются динамически в зависимости от кода ошибки и результатов предыдущих команд. Помимо !analyze -v MiniDumper:
- Анализирует как обычный стек, так и Raw-стек (командой dps) на предмет сторонних модулей. Raw-стек имеет меньшую достоверность, чем обычный стек, поскольку может содержать не относящиеся к сбою фрагменты предыдущих цепочек вызовов. Но во многих случаях он оказывается полезен (например, когда обычный стек неполон или повреждён).
- Выполняет особую обработку для кодов 0x7A, 0x77 и части 0xF4 (связаны с ошибками дисковой подсистемы), а также для 0x9F.
- Сохраняет журнал отладочных команд в папке с дампом, в том числе сведения о конфигурации (!sysinfo) и информацию о проблемных драйверах (lmvm).
- Выводит сводные результаты анализа по всем обработанным дампам в файл MiniDumper.log, который сохраняется в папке с утилитой (пример).
Отладочная информация
При анализе утилита скачивает отладочную информацию (debug symbols) в %temp%\MiniDumper. После закрытия утилиты папка удаляется автоматически.
Если вы регулярно анализируете дампы, можете задать расположение символов с помощью системных переменных среды:
_NT_SYMBOL_PATH=srv*D:\Symbols*https://msdl.microsoft.com/download/symbols _NT_EXECUTABLE_IMAGE_PATH=srv*D:\Symbols*https://msdl.microsoft.com/download/symbols
Запуск из командной строки
В качестве параметров командной строки MiniDumper принимает путь к дампу или папке с дампами, а также ключ /S для тихого режима (указывается перед путем к папке).
Заключение
QR-код с синего или зеленого экрана ведет в статью базы знаний, а там лишь общие рекомендации. Впрочем, недавно Microsoft опубликовала документацию по диагностике BSOD, где приводятся более конкретные советы для некоторых распространенных кодов ошибок, а также базовые инструкции по работе с WinDbg.
MiniDumper полностью автоматизирует анализ, упрощая задачу обычным пользователям и экономя время специалистам. Рекомендую!
Как вы анализируете BSOD?
- BlueScreenView (40%, голосов: 190)
- Ищу в интернете код ошибки (40%, голосов: 187)
- Windbg (6%, голосов: 29)
- Критических ошибок не возникает (5%, голосов: 23)
- MiniDumper (4%, голосов: 17)
- kdfe.cmd (3%, голосов: 12)
- Другое / Моего варианта тут нет (3%, голосов: 12)
- Сразу обращаюсь в форум (0%, голосов: 2)
Проголосовало: 472 [архив опросов]
Загрузка ...
>Теперь они не нужны
Ну вот :(
Александр, не огорчайтесь :) kdfe сослужил хорошую службу, но minidumper удобнее.
Да я наоборот удивляюсь, что о нем еще кто-то помнит.
Целью того моего поста на Sysadmins (и отчасти самого скрипта) было привлечь внимание сисадминов в kd/WinDbg: уж больно много было постов на форумах, связанных с BSOD, а самостоятельный анализ практически никто не делал.
Но эта обертка KD получилась хорошая и зажила своей жизнью :)
:) Я в свое время пытался вас найти, чтобы согласовать публикацию скрипта в блоге. Может, недостаточно активно искал, не помню уже, в итоге выложил как есть.
Вадим, добрый день!
Данную утилиту в большинстве случаев нужно бы использовать на работе. А в основном на работе выход в интернет через прокси. А для MiniDumper необходим прямой интернет. Есть ли решение для этого случая? Спасибо
PS. утилита (версия 1.7) у меня ругается на отсутствие интернета, хотя интернет есть, но через прокси.
Любое ПО в Windows по умолчанию использует для выхода в сеть настройки ОС, которые задаются в IE.
Этого должно быть достаточно.
В вашем случае, видимо, прокси-сервер блокирует соединения по тем портам, с которыми работает утилита.
То, что прокси блокирует выход в интернет — это понятно. Хотелось бы иметь возможность прописать настройки прокси в меню программы или в каком-либо ini файле. А так для меня данная утилита к сожалению (????)
Добавил поддержку прокси из IE, ссылка новой версии не изменилась.
Сначала ищу код ошибки, потом BSView, который, надо сказать, не всегда помогает.
А что можно по коду ошибки найти? Кучу сайтов со сгенерированной бесполезной инфой и не менее бесполезные темы в Answers. Тогда уж лучше сразу фильтровать по коду в форуме критических ошибок на OSZone.
Вадим, добрый день.
Уже много лет для анализа дампов использую ресурс http://www.osronline.com/page.cfm?name=analyze — быстро, удобно и много полезной информации. На ресурс также ссылаются многие производители в своих мануалах.
Ещё больше информации и рекомендаций даёт утилита https://www.sysnative.com/forums/threads/official-update-sysnative-bsod-processing-apps.3219/, но требует время для настройки и установки WinDbg.
За MiniDumper спасибо. Может пригодиться для группового анализа. Но по какой-то причине в вывод не включили символьную строку формата FAILURE_BUCKET_ID: X64_0x24_Ntfs!NtfsAcquireExclusiveFcb+73 — часто, это самый лучший запрос для быстрого поиска аналогичной проблемы.
Первую ссылку видел, однако это просто вывод отладчика, без полезной выжимки для точного определения проблемы. Утилиту по второй ссылке постараюсь посмотреть в работе, и если вы ею пользовались, будет интересно услышать ваше мнение, в чём она хороша или в чём лучше, чем MiniDumper.
И очень хотелось бы увидеть пример дампа, в котором FAILURE_BUCKET_ID даёт больше пользы, чем информация MiniDumper, ведь он уже анализирует строку BUCKET_ID и показывает модуль из неё, если считает эту информацию полезной.
Добрый день.
Утилиту от sysnative раньше (лет 5 назад) использовал для поддержки домашних пользователей с неизвестной конфигурацией и набором ПО. Основное преимущество — наличие своей базы драйверов и статистики BSOD. Показывались даты, версии и названия ПО. Давались рекомендации при наличии версии драйвера, по которым уже регистрировались BSOD. Остальной вывод стандартный в разных вариантах. Сейчас не использую. В корп среде не актуально — есть другие инструменты контроля обновлений.
Пример с FAILURE_BUCKET_ID вспомнился следующий — пару лет назад была массовая проблема с Cisco AnyConnect — в большинстве случаев BSOD возникал при выходе из спящего режима на ноутах. Причина была в совместимости версии приложения с версией драйвера Wi-Fi модуля Intel. К удивлению, даже сохранился пример дампа:
Полный вывод https://paste.ubuntu.com/p/YGZtk36bpJ/ содержит строки
Поиском по ‘X64_0xC5_2_nt!ExDeferredFreePool+100’ легко находятся обсуждения сетевых проблем связанных с Wi-Fi и VPN клиентами. «Pool_Corruption» при этом не информативно. Драйвер касперского, в данном случае, ни при чем.
FAILURE_BUCKET_ID полезен, например, когда возможной причиной указывается какой-то системный процесс (svchost.exe, ntoskrnl и т.п.). Помогает найти максимально похожие случаи.
Добавил вывод FAILURE_BUCKET_ID как он есть.
Андрей, спасибо за ссылки. Первая не попадалась, про вторую знаю, но она не слишком удобна для обычных пользователей / быстрого анализа на чужом ПК.
Автор утилиты читает комментарии, ответит по возможности.
А что делать, если дамп просто не создается при BSOD? 10 Вылетает при загрузке с CRITICAL_PROCESS_DIED, ни логов, ни дампов не обнаруживается.
Начните отсюда, там же и продолжайте.
Это далеко не так.
У нас тоже прокси, и я могу вам привести примеры софта, который не умеет считывать настройки прокси из IE.
Подтверждаю !!!
Наверное, имеет смысл добавить примечание о том, что Raw-стек имеет меньшую достоверность, чем обычный стек (поскольку может содержать не относящиеся к сбою фрагменты предыдущих цепочек вызовов), но во многих случаях оказывается полезен (когда обычный стек неполон или повреждён).
Добавил