Первичный анализ файла дампа памяти MEMORY.DMP при STOP-ошибках Windows (BSOD)

Это маленькая заметка о том, какие шаги необходимо выполнить для получения первичной информации об исполняемом файле, ставшем возможной причиной остановки работы операционной системы Windows — Blue Screen of Death (BSOD). По умолчанию ОС Windows настроена таким образом, что при возникновении ошибки приводящей к полной остановке работы системы, автоматически создаётся аварийный дамп памяти в виде файла MEMORY.DMP. Чтобы получить доступ к информации из этого файла, нам потребуется набор отладочных утилит Debugging tools for Windows из состава Windows Software Development Kit.

Переходим по ссылке WDK and WinDbg downloads и скачиваем онлайн-инсталлятор/загрузчик Standalone Debugging Tools for Windows (WinDbg) – файл sdksetup.exe . Запускаем инсталлятор и выбираем вариант установки…

На следующем шаге выбора компонент к установке (Select the features you want to install) отмечаем только то, что нам нужно — Debugging tools for Windows и нажимаем Install

В указанную на первом экране папку из Интернета будет загружен и установлен набор утилит.

После окончания установки находим в меню “Пуск” или на стартовом экране в группе ярлыков Windows Kits утилиту WinDbg и запускаем её с правами администратора

Если по какой-то причине ярлык найти не удалось, то можно запустить исполняемый файл из каталога установки — С:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\windbg.exe

В главном меню программы WinDbg выбираем пункты File > Symbol File Path. В открывшееся окно вставляем строку определяющую пусть к локальному каталогу символьного кэша и его онлайн-источнику:

Сохраняем настройки, выбрав в главном меню пункты File > Save Workspace

Открываем файл дампа памяти, выбрав в меню File > Open Crash Dump.

Выбираем файл MEMORY.DMP (по умолчанию расположен в каталоге C:\Windows ) и нажимаем Open

Появится информация о том, какой именно исполняемый модуль стал причиной остановки работы системы. Щёлкнув по гиперссылке !analyze-v можно получить более развернутую информацию о состоянии системы на момент возникновения стоп-ошибки.

Туже самую информацию можно получить и с помощью командной строки используя примерно следующую последовательность команд:

How can I read memory.dmp files?

What do I do with the dmp files after uploading them to skydrive? Is there a way I can look at the files myself to see what’s wrong?

Replies (3) 

If you want us to analyze them you will need to post the link to your Skydrive
where you posted them (in the Public area).

We can analyze the minidumps if you make them available from the
OneDrive or other file sharing sites (such as MediaFire). If you have
problems uploading the minidumps copy them to the Desktop or the
Documents folder and upload them from there.

One-Drive — Share files and folders and change permissions
http://windows.microsoft.com/en-us/onedrive/share-file-folder

Zip or upload the contents of C:\Windows\minidump

Use OneDrive to upload collected files

Run BlueScreenView and it displays the information in a very readable format —
is quick and simple. BlueScreenView is not as accurate for the specific CAUSE
as WinDBG however it provides a wealth of information — and again it is very
simple to use,

BlueScreenView — Free
http://www.nirsoft.net/utils/blue_screen_view.html

As you click on each top section Bug_Check the lower section displays the
Filenames with more information. Sometimes the CAUSE is the actual cause
though more likely it is what was affected (or driven to fault) by something
else. Check the various commands/options from the menus and Right Click
while in BlueScreenView.

How to read the small memory dump files that Windows creates for debugging
http://support.microsoft.com/kb/315263/en-us?p=1

Check this thread for information using BlueScreenView, MyEventViewer
and other methods to troubleshoot BlueScreens — top 3 replies (+1 other).
This troubleshooter is for Windows 7 however it will also work for XP and
Visa- the main differences are using RUN instead of Start — Search (for XP).

WinDBG is a more complete debugging tool.

How to read the small memory dump file that is created by Windows if a crash occurs
http://support.microsoft.com/kb/315263/en-us

Using Microsoft Windows Debugger (WinDbg)
http://kipirvine.com/asm/4th/debug/windbg/index.htm

Hope this helps.
———————————————————————————————
Rob Brown — Microsoft MVP Rob Brown — past Microsoft MVP — Windows Insider MVP 2016 — 2021
Microsoft MVP Windows and Devices for IT 2009 — 2020

How to open and read Small Memory Dump (dmp) files in Windows 10

When a running Windows application stops or crashes unexpectedly, your system generates a ‘crash dump file’ to save information present just before the crashing event occurred. Reading these memory dump files may help you find and troubleshoot the cause of the error. Find how you can read a small memory dump file created by Windows.

Reading Small Memory Dump (dmp) files

A small memory dump file records the smallest set of useful information that may help you pinpoint why an application crashed or stopped unexpectedly. The newer version of Windows automatically creates a new file every time your computer stops unexpectedly. The history related to these files is stored in the %SystemRoot%\Minidump folder. The dump file type contains the following information:

1. The Stop message and its parameters and other data
2. A list of loaded drivers
3. The processor context (PRCB) for the processor that stopped
4. The process information and kernel context (EPROCESS) for the process that stopped
5. The process information and kernel context (ETHREAD) for the thread that stopped
6. The Kernel-mode call stack for the thread that stopped.

Users can use the Windows Debugger (WinDbg.exe) tool to read small memory dump files. It (WinDbg) comes as a part of the latest version of the Debugging Tools for Windows package.

You can install the debugging tools as a standalone component from the Windows Software Development Kit (SDK).

During the setup, when the SDK installation wizard appears, check the box marked against Debugging Tools for Windows. This action will enable you to install the debugging tools as a standalone component from the Windows Software Development Kit (SDK).

Once you have set up the Windows Debugger, open a dump by choosing Open Crash Dump option from the File menu or by pressing CTRL+D.

When the Open Crash Dump dialog box pops up on your computer screen, enter the full path and name of the crash dump file in the File name box, or use the dialog box to select the proper path and file name.

Now, when the proper file has been chosen, select Open.

Wait for a few seconds to allow the dump file to load as it connects to the Internet and downloads the required symbols to display in the readout.

You should see a message, reading – Debugee not connected.

After all the symbols have been successfully downloaded, the following message should be visible at the bottom of the dump text – Followup: MachineOwner.

Enter a command into the command bar at the bottom of the dump window to analyze the dump file. You should see a link that says !analyze -v under Bugcheck Analysis.

Hit the link to enter the command !analyze -v in the prompt at the bottom of the page.

Once done, a detailed bug check analysis should occupy the screen space.

Scroll down to the section where it says STACK_TEXT . The STACK_TEXT field shows a stack trace of the faulting component. Here, you will find be rows of numbers with each row followed by a colon and some text. The text should help you identify the cause of the crash and if applicable what service is crashing it.

Use the !analyze Extension to get more details. Do not forget to use the -v, option for a fully verbose display of data

Upon execution, the ‘!analyze’ command will determine the instruction that has probably caused the error and display it in the FOLLOWUP_IP field.

• The SYMBOL_NAME – show the symbol
• MODULE_NAME – displays the module
• IMAGE_NAME – displays image name
• DEBUG_FLR_IMAGE_TIMESTAMP – shows image timestamp corresponding to this instruction

Take the necessary action to get the issue resolved!

• You can also use the command-line tool Dumpchk.exe to check a memory dump file.
• Alternatively, you can use WhoCrashed Home Edition to check for errors in a single click. The tool does a post-mortem crash-dump analysis of the Windows Memory Dumps and presents all gathered information in a comprehensible way.

Hope that helps!

Date: November 22, 2020 Tags: Troubleshoot

How can I read memory.dmp files?

Replies (8) 

In order to assist you, we will need the DMP files to analyze what exactly occurred at the time of the crash, etc.

If you don’t know where DMP files are located, here’s how to get to them:

1. Navigate to the %systemroot%\Minidump folder.
2. Copy any and all DMP files in the Minidump folder to your Desktop and then zip up these files.
3. Upload the zip containing the DMP files to Skydrive or a hosting site of your choice and paste in your reply.

If you are going to use Skydrive but don’t know how to upload to it, please visit the following:

Please note that any «cleaner» programs such as TuneUp Utilities, CCleaner, etc, by default will delete DMP files upon use.

If your computer is not generating DMP files, please do the following:

1. Start > type %systemroot% which should show the Windows folder, click on it. Once inside that folder, ensure there is a Minidump folder created. If not, CTRL-SHIFT-N to make a New Folder and name it Minidump.

2. Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Performance > Settings > Advanced > Ensure there’s a check-mark for ‘Automatically manage paging file size for all drives’.

3. Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > ensure there is a check mark next to ‘Write an event to the system log’.

Ensure Small Memory Dump is selected and ensure the path is %systemroot%\Minidump.

4. Double check that the WERS is ENABLED:

Start > Search > type services.msc > Under the name tab, find Windows Error Reporting Service > If the status of the service is not Started then right click it and select Start. Also ensure that under Startup Type it is set to Automatic rather than Manual. You can do this by right clicking it, selecting properties, and under General selecting startup type to ‘Automatic’, and then click Apply.

If you cannot get into normal mode to do any of this, please do this via Safe Mode.

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Win Debugger requires special symbols and expertise. There is no user readable text in the DMP files.

It is as much art as science. Your best bet is to upload the DMP files as Patrick suggests and let us take a look.

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Thanks for uploading the dumps!

We have various different bugchecks:

This indicates that a system thread generated an exception which the error handler did not catch.

We have an access violation. the exception code — EXCEPTION_CODE: (NTSTATUS) 0xc0000005

If we run an .exr on the 3rd parameter of the bugcheck (Exception Record Address), we get the following:

1: kd .exr 0xffffffff984c980c ExceptionAddress: 91163942 (atikmpag+0x00006942) ExceptionCode: c0000005 (Access violation)

As we can see, it was an access violation as I mentioned, and what caused it was atikmpag.sys which is the ATI video driver.

This indicates that the current thread is making a bad pool request.

An invalid pool request has been made by the current thread.

This indicates that the video memory manager has encountered a condition that it is unable to recover from.

This bug check is usually caused by a video driver behaving improperly.

The processor identified a problem, but Windows was unable to deal with it. This problem can appear when one of these issues occurs: Low disk space in the primary system drive A driver bug (which may be identified in the message). Video adapter problems A BIOS bug BIOS caching or shadowing

Overall, let’s do the following:

Ensure you have the latest video card drivers. If you are already on the latest video card drivers, uninstall and install a version or a few versions behind the latest to ensure it’s not a latest driver only issue. If you have already experimented with the latest video card driver and many previous versions, please give the beta driver for your card a try.

ASACPI.sys — Thu Aug 12 22:52:52 2004

^^ Asus ATK0110 ACPI Utility (a known BSOD maker in Win7 and Win8). Also a part of many Asus utilities. The pre-2009 version is a huge cause of BSOD’s.

RTCore32.sys — Wed May 25 02:39:05 2005

^^ RivaTuner/EVGA Precision/MSI Afterburner (known BSOD issues w/Win7 8)

Uninstall this software ASAP, it’s likely what’s causing your issues.

We can discuess software replacements later.

What is Driver Verifier?

Driver Verifier is included in Windows 8, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.

Essentially, if there’s a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.

Before enabling Driver Verifier, it is recommended to create a System Restore Point:

Vista — START | type rstrui — create a restore point
Windows 7 — START | type create | select «Create a Restore Point»
Windows 8 — http://www.eightforums.com/tutorials/4690-restore-point-create-windows-8-a.html

How to enable Driver Verifier:

Start > type «verifier» without the quotes > Select the following options —

1. Select — «Create custom settings (for code developers)»
2. Select — «Select individual settings from a full list»
3. Check the following boxes —
— Special Pool
— Pool Tracking
— Force IRQL Checking
— Deadlock Detection
— Security Checks (Windows 7 & 8)
— DDI compliance checking (Windows 8)
— Miscellaneous Checks
4. Select — «Select driver names from a list»
5. Click on the «Provider» tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is [B]NOT[/B] provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.

Important information regarding Driver Verifier:

— If Driver Verifier finds a violation, the system will BSOD.

— After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will flag it, and as stated above, that will cause / force a BSOD.

If this happens, do not panic, do the following:

— Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

— Once in Safe Mode — Start > type «system restore» without the quotes.

— Choose the restore point you created earlier.
If you did not set up a restore point, do not worry, you can still disable Driver Verifier to get back into normal Windows:

— Start > Search > type «cmd» without the quotes.

— To turn off Driver Verifier, type in cmd «verifier /reset» without the quotes.
・ Restart and boot into normal Windows.

How long should I keep Driver Verifier enabled for?

It varies, many experts and analysts have different recommendations. Personally, I recommend keeping it enabled for at least 24 hours. If you don’t BSOD by then, disable Driver Verifier.

My system BSOD’d, where can I find the crash dumps?

They will be located in %systemroot%\Minidump