Bluescreenview как поменять язык. BlueScreenView: что это и как пользоваться? Особенности работы BlueScreenView

Отображается в системе Windows после сбоя системы, когда ваша операционная система достигает порога, где она больше не может функционировать безопасно. Ошибка остановки получает свое имя как синяя ошибка экрана, потому что предупреждающее сообщение отображается на синем экране с грустным смайликом и QR-кодом, который предлагает несколько возможных исправлений.

BSOD обычно возникает из-за нескольких причин, таких как поврежденные реестры Windows, плохие драйверы, неправильно сконфигурированные драйверы устройств, поврежденные файлы, устаревший драйвер, проблемы с памятью и проблемы с системным оборудованием. Когда вы столкнетесь с BSOD, ваша система потребует перезагрузки, чтобы продолжить работу. Однако перед перезагрузкой рекомендуется, чтобы пользователи записали сообщение об ошибке и код ошибки.

Ошибка BSOD в основном отображается, когда ваша система не может восстановить ошибку на уровне ядра. Сообщение об ошибке обычно отображает данные драйвера, связанные с ошибкой и другую информацию о проблеме, и их возможные исправления. Также, когда ваша система выходит из строя с ошибкой BSOD, система создает файлы minidump, и все данные памяти с данными об ошибках выгружаются на жесткий диск для дальнейшей отладки. Существует много способов, которыми вы можете прочитать файлы minidump для устранения неполадок. Но самый простой способ - использовать бесплатную и удобную утилиту BlueScreenView, которая позволяет пользователям легко читать отчет об ошибке для устранения неполадок.

BlueScreenView это ориентированная на пользователя утилита, которая автоматически сканирует все файлы minidump, созданные после сбоя BSOD, в одну таблицу. Для каждого сбоя BlueScreenView дает подробную информацию о драйвере, который был загружен во время сбоя, и другую информацию о сбоях, чтобы легко устранить проблемы и найти подозрительные проблемные драйверы. Кроме того, бесплатный инструмент отображает экран ошибки синего экрана, очень похожий на тот, который Windows отображал во время сбоя системы.

Использование Blue Screen View довольно просто. Все, что нужно сделать, - запустить исполняемые файлы, которые автоматически сканируют все файлы minidump, которые были созданы во время сбоя. В основном это отображает файлы дампа, созданные при сбое в верхней панели, и отображает связанные драйверы в нижней панели. В этой статье мы объясним, как использовать BlueScreenView для чтения отчета о сбоях.

После того, как вы скачали и установили его, запустите BlueScreenView.exe запускаемый файл.

После запуска исполняемого файла BlueScreenView автоматически сканирует всю вашу папку minidump, чтобы отобразить детали сбоя. Он отображает файлы дампа, созданные при сбое в верхней панели окна, и отображает связанные драйверы в нижней панели окна.

Чтобы узнать свойства ошибки, дважды щелкните драйверы, отображающие данные об ошибках в формате таблицы.

Пользователи могут также отправить отчет по протоколу HTML для устранения неполадок. Для этого щелкните правой кнопкой мыши на файле дампа и выберите HTML-отчет - все элементы или HTML-отчет - выбранные элементы в раскрывающемся меню.

Вы также можете сохранять отчеты для отладки повторяющихся проблем. Для этого щелкните правой кнопкой мыши на файле дампа и выберите опцию Сохранить выбранные элементы.

BlueScreenView позволяет пользователю настраивать столбцы, которые вы хотите сделать видимыми, и изменить порядок столбцов с помощью Перемещение вверх / перемещение вниз Кнопка.

Он также доступен на других языках. Чтобы изменить язык BlueScreenView, загрузите соответствующий языковой файл zip, извлеките "Bluescreenview_lng.ini" , и поместите его в ту же папку, где вы установили утилиту.

BlueScreenView предназначен для работы в версиях Windows и может читать файлы minidump, созданные как системами 32-бит, так и x64. Утилита доступна на разных языках, и вы можете ее скачать.

Надеюсь, вы найдете это сообщение полезным.

У пользователей ПК есть сильный страх, который всех объединяет – BSOD (Blue Screen of Death, «синий экран смерти») – критическая ошибка, которая приводит к аварийному завершению работы системы без сохранения данных. Рядовому пользователю сложно расшифровать информацию о сбое, если после отображения технической информации компьютер сразу перезагружается. Поэтому рассмотрим, как пользоваться BlueScreenView – приложением, которое сохраняет и расшифровывает сведения о сбое в работе ОС.

О программе

Создание файла дампа

В операционных системах Windows 7, 8, 10 дамп оперативной памяти сохраняется автоматически. Но мы отредактируем настройки создания файла и оптимизируем их под BlueScreenView.

Пройдем по следующим пунктам:

  1. Откройте «Этот компьютер» – «Свойства системы».

  2. Нажмите «Дополнительные параметры системы».

  3. Во вкладке «Дополнительно» кликните на кнопку «Параметры» в блоке «Загрузка и восстановление».
  4. В появившемся окне уберите галочку с пункта «Заменять существующий файл дампа» и в поле «Запись отладочной информации» выберите «Малый дамп памяти (256 KB)».

Справка! Малый дамп памяти содержит необходимую информацию для анализа ошибки и не занимает много дискового пространства. А заменять существующий файл дампа не рекомендуется, т.к. ошибок несколько, а записывается - одна.

Анализ дампа памяти

Первым делом запустите BlueScreenView. Приложение автоматически сканирует папку хранения всех дампов памяти.

Для извлечения необходимой информации нужно:

  1. Выбрать нужный.dmp файл из списка, посмотреть на перечень драйверов и компонентов, загружавшихся во время последнего запуска ОС.

  2. Дважды кликнуть на поле, подсвеченное красным цветом.
  3. Ознакомиться с технической информацией об ошибке.

  4. Кликнув ПКМ на поле дампа памяти, вы можете импортировать данные в файл для последующей отправки специалисту или в службу поддержки. Также предусмотрена возможность поиска решения проблемы напрямую с приложения.

Данная статья продолжает серию публикаций по обзору инструментов анализа аварийных дампов системы. И сегодня мы рассмотрим пожалуй наиболее автономное средство в арсенале специалиста, утилиту с говорящим названием BlueScreenView . Чем это средство так уникально? Не тем, что алгоритм работы программы в какой то степени отличается от алгоритмов программ подобного класса (скорее всего всё крутится вокруг одних и тех же схем), а более из-за того, что программа не использует отладочные символы, что делает её полностью независимой. BlueScreenView представляет собой бесплатное программное обеспечение, которое анализирует содержимое файлов дампов, создаваемых при критическом сбое системы ( , синий экран смерти), и предоставляет информацию пользователю в виде легко интерпретируемой результирующей таблицы. В дополнение ко всему прочему, утилита предоставляет расширенную информацию по свойствам дампов памяти системы. Как уже отмечалось, BlueScreenView полностью автономна и не требует для своей работы никаких дополнительных дынных, как то символы либо отладчики. Скачал, запустил, проанализировал! Автором программы является Nier Sofer, хотел бы сказать спасибо ему огромное за предоставленную чрезвычайно полезную утилиту.
Скачать BlueScreenView можно по вот этой ссылке . При этом, что действительно удобно, так это то, что скачать утилиту можно не только в виде классического установщика (зачем мне инсталлировать временный софт на сервер?), но и в форме отдельного переносимого (portable) приложения (пункт Download BlueScreenView (in Zip file)). Распаковал из архива и запустил, что еще надо? Опять же, это позволяет держать утилиту в наборе своих "инструментов на каждый день". BlueScreenView доступна в двух вариантах кода - в 32- и 64-битном.

Интерфейс BlueScreenView

После старта утилита BlueScreenView сканирует стандартное местоположение дампов памяти:

и находит все дампы, которые располагаются в каталоге по-умолчанию, далее для каждого дампа (по своему собственному алгоритму) перечисляет адреса памяти внутри стека момента сбоя и определяет все драйвера/модули которые могут быть причиной критической ситуации.
По умолчанию BlueScreenView ищет дампы в каталоге %SystemRoot%\Minidump . Однако, данное положение может быть изменено редактированием параметра "Load from the following MiniDump folder" в разделе "Options" - "Advanced Options" (Ctrl + O). В дополнение, вид окна программы легко и удобно настраивается, что позволяет показывать/скрывать определенные столбцы.

Верхнее окно интерфейса программы BluScreenView по-умолчанию выглядит несколько иначе. На моем скриншоте я замаскировал (скрыл) четыре столбца под названием "Parameter 1", "Parameter 2", "Parameter 3", "Parameter 4", которые являются четырьмя аргументами функции KeBugCheckEx .

Как можно наглядно увидеть из скриншота, интерфейс программы разбит на две основные части: список файлов дампов (сверху) и список драйверов, находящихся в ядре на момент сбоя (снизу).
В верхней части интерфейса BlueScreenView отображает список обнаруженных в системе дампов памяти. Здесь я перечислю только основные столбцы верхнего фрейма программы:

Столбец Назначение
Dump File Файл дампа памяти, найденный утилитой в заданной директории. Хранит различную информацию о состоянии системы на момент критической ошибки.
Bug Check String Символическое имя или описание критической ошибки (Bug Check) по классификации Microsoft. В нашем примере это BAD_POOL_HEADER .
Caused By Driver Драйвер или модуль, который, предположительно и вызвал сбой. BluScreenView пытается вычислить драйвер/модуль по стеку момента критического сбоя, который присутствует в дампе. В нашем случае RtkHDAud.sys . Помните, что механизм определения сбойного модуля/драйвера не может со 100% вероятностью определить виновника, и необходимо анализировать более расширенный список в нижнем фрейме окна программы, выделенный розовым цветом. Сам автор предупреждает нас об этом на странице утилиты.
Bug Check Code Идентификатор кода BugCheck или STOP-ошибка. Например, STOP 0x00000019 .
Caused By Address Тоже самое что и колонка "Caused By Driver", однако показывает относительный адрес инструкций, вызвавшей сбой. Относительно начала модуля в котором произошел сбой. В нашей ситуации RtkHDAud.sys+1f93fc .
File Description Описание проблемного файла.
Crash Address Адрес по которому и случилась ошибка. Содержимое регистров EIP/RIP на момент сбоя. В некоторых случаях идентичен адресу из колонки "Caused By Address", в других адрес не совпадает. Пример: ntoskrnl.exe+22f5f .

В нижней части интерфейса BlueScreenView отображает список всех драйверов режима ядра, которые в момент сбоя находились в памяти. И маркирует розовым цветом все драйвера, которые найдены в стеке сбоя. Перечислю в таблице лишь основные столбцы:

Столбец Назначение
Filename Имя драйвера/модуля.
Address In Stack Адрес памяти драйвера, который найден в стеке.
From Address Смещение первого байта драйвера в адресном пространстве ядра. Пара значений From Address / To Address показывает адресное пространство, занимаемое драйвером.
To Address Смещение последнего байта драйвера в адресном пространстве ядра. Пара значений From Address / To Address показывает адресное пространство, занимаемое драйвером.
Size Размер драйвера в памяти.
Product Name Имя продукта, в состав которого входит драйвер. Загружается из поля ресурсов?
File Description Описание файла драйвера. Загружается из поля ресурсов?
File Version Версия файла драйвера. Загружается из поля ресурсов?
Company Имя компании. Загружается из поля ресурсов?.
Full Path Полный путь до файла драйвера в файловой системе.

В один прекрасный момент, анализируя очередной дамп памяти при помощи программы BlueScreenView я обратил внимание на одну интересную особенность. Если Вы внимательно посмотрите на столбец в верхнем фрейме программы под названием "Caused by Address", то увидите, что в нем присутствуют имена модулей/драйверов и относительный адрес инструкции. Так вот, почему же там присутствуют голые числовые значения смещений, но не имена? Причина проста и как мы уже отмечали:

BlueScreenView не использует и не нуждается в них.

То есть он ничего не знает о сопоставлении адресов реальным функциям. Конечно, это не позволяет программисту получить более детальную информацию, однако это абсолютно не нужно рядовому пользователю, которому для решения задачи достаточна и более общая информация о сбое, обобщенная до указания на модуль/драйвер. Как это сказывается на точности определения причины критической ошибки, спросите Вы? Пока что ответить на этот вопрос для меня сложновато, но могу предположить что никак не отражается, поскольку точность определения зависит от корректности работы внутреннего алгоритма BlueScreenView, который опирается на адреса памяти, но никак не зависит от наличия/отсутствия символов системы/модулей/драйверов. Символы нужны для дополнительной информации по внутренним функциям.

Анализ результатов

Собственно, вкратце, общий алгоритм поиска причины сбоя следующий:

  1. (в верхней части окна) ставим курсор на имя интересующего нас минидампа, тем самым выделяя (выбирая) его. Нижняя часть окна автоматически заполняется результатом анализа.
  2. (в верхней части окна) смотрим столбец Caused By Driver , видим там наименование проблемного модуля/драйвера (для нашего случая это RtkHDAud.sys ).
  3. (в нижней части окна) находим этот же драйвер/модуль (столбец Filename), ставим курсор на эту строку и опять перемещаем ползунок вправо, чтобы посмотреть значения в столбцах Product Name , File Description и Full Path . По значениям этих полей мы сможем определить принадлежность модуля/драйвера. Если же поля нам не дали никакой информации, то вбиваем имя модуля/драйвера RtkHDAud.sys в поисковик и ищем информацию уже в Сети.

Изредка встречаются случаи, когда указываемый в верхнем фрейме программой BlueScreenView драйвер не является источником проблемы. Да, ведь сам автор, как я писал уже выше, предупреждает от том, что невозможно сделать точный вывод по сбою в 100% случаев. Однако, не стоит отчаиваться, поскольку драйвер/модуль, который является истинным виновником сбоя, наверняка присутствует среди списка, подсвеченного красным цветом в нижней части окна программы. У нас это: ks.sys , ntoskrnl.exe , portcls.sys , sysaudio.sys , wdmaud.sys . Исходя из отсутствия 100% гарантии определения, в исследовании аварийных дампов я бы не ограничивался применением только лишь утилиты BlueScreenView, а использовал бы и другие продукты для анализа проблемы.

Поскольку она проводит более глубокий анализ и точнее определяет причину проблемы.

Ко мне обратилось сразу несколько человек с вопросом, стоит ли вместо Debugging Tools for Windows использовать для анализа дампов памяти относительно недавно вышедшую утилиту BlueScreenView . Бесплатные утилиты NirSoft (автор – Nir Sofer) хорошо известны своей полезностью, удобством и продуманностью функционала. И BlueScreenView действительно очень удобна для определения проблемного драйвера.

BlueScreenView

По умолчанию BlueScreenView ищет дампы в папке %systemroot%\Minidump, но можно настроить и собственную папку (Options –> Advanced ). Для найденных драйверов утилита отображает:

  • В верхней панели – название файла, дату создания, название стоп-ошибки, код ошибки, параметры, а также драйвер, предположительно вызвавший проблему (Caused By Driver ).
  • В нижней панели – (в зависимости от настроек в Options –> Lower Pane Mode ) все драйверы, загруженные во время ошибки, или только драйверы, найденные в стеке. Среди всех драйверов — на розовом фоне отображаются предположительно вызвавшие проблему драйверы. Также, утилита может отображать синий экран, очень похожий на тот, который все так любят.

Важно! Я должен отметить, что при определении драйвера не нужно полагаться только на имя файла в столбце Caused by Driver . Следует рассмотреть драйверы в нижней панели (или только выделенные розовым цветом, если включено отображение всех драйверов), в первую очередь обращая внимание на несистемные драйверы.

Утилита очень быстро работает, а также обладает дополнительными возможностями по копированию отдельных строк и созданию HTML-отчетов.

BlueScreenView vs. kdfe.cmd / WinDbg

В приведенном выше скриншоте виновником проблемы являлся не USBPORT.SYS (системный драйвер), aclaudsl.sys (драйвер модема). Именно на последний указал анализ kdfe , полагающeгося на Debugging Tools for Windows. И тут я перехожу к вопросу, насколько корректен анализ утилиты по сравнению с kdfe / WinDbg.

Честно говоря, я не являюсь экспертом по отладке, но одно очевидно сразу: в отличие от WinDbg, BlueScreenView не использует для анализа символы, загружаемые с сайта Microsoft. Я поинтересовался у автора программы, насколько корректным считает он анализ в этих условиях. И вот что он ответил (в сокращении):

Вне зависимости от того, используете вы BlueScreenView или WinDbg с символами, невозможно достичь абсолютной точности в определении драйвера.
Я не думаю, что символы помогли бы моей утилите произвести более точный анализ. В символах содержится дополнительная информация, которая может помочь профессионалам определить точную причину — например, функцию внутри драйвера, вызвавшую ошибку. Однако определение драйверов, вовлеченных в ошибку, может быть выполнено на основе адресов памяти без всяких символов.

Я решил проверить, насколько результаты BlueScreenView совпадают с kdfe. Поскольку в материале нет недостатка, я взял навскидку полтора десятка дампов с наиболее распространенными кодами (0x8E, 0x50, 0xD1 и 0x0A). Лишь в одном случае результаты отличались – BlueScreenView указала на системный драйвер, а kdfe – на драйвер Outpost Firewall. Тестирование также выявило, что далеко не всегда BlueScreenView верно указывает на проблемный драйвер в верхней панели, но во всех случаях кроме одного, оговоренного выше, проблемный драйвер был обозначен в нижней панели. Таким образом, kdfe понятнее указывает на проблемный драйвер. Однако наблюдалась и обратная картина – иногда kdfe однозначно указывает на системный драйвер, в то время как BlueScreenView выделяет еще и несистемные, которые также могут оказаться причиной проблемы.

Резюме

До появления утилиты MiniDumper рекомендовал BlueScreenView для быстрого анализа дампов памяти, создающихся при BSOD. Однако утилита не всегда однозначно указывает на проблемный драйвер в верхней панели. Поэтому, вместо того чтобы любоваться в нижней панели картинкой синего экрана, лучше включить для нее отображение драйверов и изучить их список. Для глубокого анализа без WinDbg все равно не обойтись, а утилита MiniDumper автоматизирует этот процесс.

Сегодня мы рассмотрим:

Сегодня компьютер для любого пользователя – это жизненно необходимый инструмент, который позволяет выполнять массу задач. К сожалению, система (особенно это касается ОС Windows) не всегда может работать корректно, из-за чего могут возникать различные неприятности, например, такие, как синий экран смерти.

– критическая ошибка, которая, как правило, сопровождается своим кодом ошибки. После ее появления пользователю требуется записывать данный код с целью дальнейшего выяснения его значения и определения программного обеспечения, которое могло вызвать сбой.

Чаще всего синий экран смерти (при условии, что операционная система все же способна загружаться) возникает из-за драйверов и иного программного обеспечения, установленного на компьютере. Для упрощения задачи выявления проблемного программного ПО и была разработана утилита BlueScreenView, которая позволяет практически мгновенно получить информацию о коде ошибки, его расшифровку, а также выявить конкретный компонент, повлиявший на ее возникновение.

Использование программы BlueScreenView

Утилита BlueScreenView является полностью бесплатной утилитой, которая направлена на создание дампа памяти и в случае возникновения синего экрана смерти позволяет сравнивать данные с целью выявления причин сбоя. Примечательно и то, что программа не требует установки, а значит, вы сразу можете приступить к ее эксплуатации.


BlueScreenView – чрезвычайно простая в эксплуатации утилита, которая поможет быстро и в удобной форме получить развернутую информацию об ошибке. Он значительно сэкономит вам время, освобождая от необходимости сидеть с листком и карандашом в руке, фиксируя код ошибки, пробивая информацию в поисковой системе и выясняя, какое именно программное обеспечение могло дать сбой.