How to Open a Memory.DMP File for Analysis in WINDOWS 10, Please?

Topic

New Reply

[Mr. Austin]

When installed on a Win 10 Pro box, the WinDbg file downloadable from the Windows Store does not respond when it is launched, although it does give an interminably flashing mouse/processing cursor. I’ve tried both admin launch and non-admin launch.

During uninstallation of WinDbg, what looks like a command window comes up, but with an error code. I’ve gotten these results twice.

Which program will actually work to examine the Memory.dmp file, please?

Thank you for any helpful suggestions!

Human, who sports only naturally-occurring DNA ~ oneironaut ~ broadcaster

• This topic was modified 2 years, 3 months ago by Mr. Austin.

Reply | Quote

Replies

I’ve used the Nirsoft utility.

https://www.nirsoft.net/utils/blue_screen_view.html

Desktop Asus TUF X299 Mark 1, CPU: Intel Core i7-7820X Skylake-X 8-Core 3.6 GHz, RAM: 32GB, GPU: Nvidia GTX 1050 Ti 4GB. Display: Four 27" 1080p screens 2 over 2 quad.

Reply | Quote

Thank you. I tried it just now and it defaults to a mini dump file instead of full dump. So there are events it didn’t import.

Human, who sports only naturally-occurring DNA ~ oneironaut ~ broadcaster

1 user thanked author for this post.

TechTango

Reply | Quote

It reads what you have, have you browsed to the location of the .dmp file you want it to review?

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

Thank you. Above is what I see when I load I tried that under its Nirsoft BlueScreenView. Just a few events, when I know that these started on or before 11-1-22. Am I missing something obvious?

I also didn’t see a way to import or even locate the full (2.6 GB!) Memory.dmp file. The full Memory.dmp file defaults to the Windows directory, and not the Windows directory’s subfolder.

Human, who sports only naturally-occurring DNA ~ oneironaut ~ broadcaster

Reply | Quote

Click on file and you can browse to another location to search for other .dmp files.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

As per the online description, BlueScreenView scans the data from minidumps, larger dumps need different tools and more input/learning to get useful pointers.

Nirsoft’s DriverView displays the list of all device drivers currently loaded on your system: https://www.nirsoft.net/utils/driverview.html To narrow down the list to 3rd party drivers, View> Mark non-Microsoft drivers and Hide non-Microsoft drivers. MSFT-supplied (built-in) drivers, assumed to be fully tested and never causing Bugchecks, can sometimes be listed in there – see the Service Display Column for entries with an ‘@oem’ prefix and categorised as 3rd party.

BSOD Kernel Dump Analysis Debugging Information Kernel and full dumps require WinDbg (MSFT debugging tool) to follow these up.

Best self-help resources and debugging of Bugchecks/BSODs:
BSOD Bugcheck Codes (STOP Error Codes) and lots more on this site.

MSFT ‘help’ pages for your listed Bugchecks:

0xD1: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xd1–driver-irql-not-less-or-equal
0xA: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xa–irql-not-less-or-equal
0x139: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x139–kernel-security-check-failure
0xB8: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xb8–attempted-switch-from-dpc

1 user thanked author for this post.

Mr. Austin

Reply | Quote

satrow wrote:

BSOD Kernel Dump Analysis Debugging Information Kernel and full dumps require WinDbg (MSFT debugging tool) to follow these up.

Thank you. In this case, and that of six other Windows 10 machines mentioned in this, other, directly related thread by Captain AI, the problem clearly points to an ntoskernal.exe crash.

Yet the required WinDbg utility won’t even launch on my main Windows 10 Pro (64-bit) box.

Not being experienced in this, although I am sometimes a quick study, unless I can actually open the problem machines full memory.dmp file for examination, at this writing I haven’t found any productive options.

Human, who sports only naturally-occurring DNA ~ oneironaut ~ broadcaster

Reply | Quote

If ntoskernel.exe was the cause, we’d all be running *nix or Mac. The Windows Kernel will call a Bugcheck (halt) to protect data/hardware whenever a serious problem is detected or flagged.

Productive options: check your drivers are up to date and actually needed on your machine. This goes double for any non MS-installed drivers – and – any running, or loaded, security or ‘utility’ software, either processes, drivers, or Services.

WinDbg comes in at least two forms, a traditionally installed download and an ‘App’ from the MSFT Store. Don’t give up after failing on one version (and check that you have any library requirements fullfilled).

It usually takes me over an hour to install, setup and get some dumps loaded correctly in WinDbg for the first time. Researching which analysis ‘calls’ to make can take just as long per step.

I sometimes find the output from DriverView/BlueScreenView/MSInfo32 can give very useful insights into what’s happening.

1 user thanked author for this post.

Mr. Austin

Reply | Quote

Thank you for all that, Satrow. *And* the only substantial thing which changed about the software of the subject machine was that it was allowed to “upgrade” from Win 10 Home to “Pro”. That is when the problems began. All of the drivers had all been stable. All the drivers had remained managed.

Because of the supposed Windows “upgrade” – the problems began on a machine which had never had them in its 4+ fairly reliable years of service. No crash reboots, and the machine even functioned OK most of the time with an HP sound driver which was transferred to a non-HP machine by PC Mover. But the machine’s entire OS had to be wiped in early October because the OS failed completely, all in one fell swoop. All the same drivers were used, and the only thing that changed was the switch from Windows Home to Pro.

So the result of the “upgrade” was a thorny downgrade in reliability. This was a significant mistake which I am unlikely to make again.

And, based on this other thread which outlines the background reasons for wanting to find out how to diagnose this unexpected problem, Mysterious Windows 10 Kernel-Power Event ID 41 Critical Shutdown/Reboot Errors, the problem looks like it could even be widespread but either unnoticed or deemed to be unworthy of attention by other power users or sysadmins. So I’m thinking about nosing around other fora to see what others have noticed.

Human, who sports only naturally-occurring DNA ~ oneironaut ~ broadcaster

Reply | Quote

Hi Mr. Austin:

You might want to read DaveH’s 10-Feb-2016 instructions on how to use WinDbg on a Win 10 computer in the Norton thread Norton Security Blue Screen From Background Tasks. I don’t know if those instructions are still relevant but it should give you some idea of the complexity of setting up WinDbg. If you read through that entire thread you will see that DaveH was able to use WinDbg to determine that the OP Phoenix365’s BSODs were actually caused by the Gigabyte gdrv.sys driver included with the EasyTune utility that came with their Gigabyte motherboard. When I analyzed Phoenix365’s mini-dump files with BlueScreenView this utility reported the crashes were caused by ntoskrnl.exe and hal.dll, although the BlueScreenView image I posted <here> confirmed that gdrv.sys was loaded in the crash stack at the time of each BSOD. Several years ago I used BlueScreenView to correctly identify that an out-of-date driver for my NVIDIA graphics card was causing a BSOD on my old Vista SP2 computer, but in some cases an analysis of the full dump file with with WinDbg is required to find the actual driver responsible for your BSODs.

DaveH’s instructions were quite complicated but there’s a good TenForums tutorial at How to Install and Configure WinDBG for BSOD Analysis that might help get you started. I’ve never tried to set up WinDbg on my own Win 10 PC, and I normally suggest that users just post in BleepingComputer’s Windows Crashes and Blue Screen of Death (BSOD) Help and Support board (see their posting guidelines <here>) where someone will analyze your full crash dump for you using WinDbg.
————-
Dell Inspiron 5584 * 64-bit Win 10 Pro v22H2 build 19045.2486 * Firefox v109.0.0 * Microsoft Defender v4.18.2211.5-1.1.19900.2 * Malwarebytes Premium v4.5.20.230-1.0.1868 * Macrium Reflect Free v8.0.7279

Reply | Quote

lmacri wrote:

I’ve never tried to set up WinDbg on my own Win 10 PC, and I normally suggest that users just post in BleepingComputer’s Windows Crashes and Blue Screen of Death (BSOD) Help and Support board (see their posting guidelines ) where someone will analyze your full crash dump for you using WinDbg.

Merci buckets, lamacri. Of course I’m less than enthusiastic 😒about having to teach myself something very complicated I’m not used to. Although two decades ago I began fixing, running and building out a complicated LAN because I wanted to. So, I like your idea of simply posting the crash dumps for someone experienced and expert who lives in that mindspace to just follow and point out the obvious (to them) culprits. That hadn’t occurred to me because I usually prefer to be self-reliant, like when doing my own pre- and post-run inspections on a high-performance street car when running it on open-track, road racing days. But there were also times when at trackside when we’d be a huge help to each other. I helped a fellow speed freak rebuild his brakes. And when my otherwise eager car needed more tire tread to pass the pre-run tech inspector’s jaundiced eye, one of my friends just loaned me his entire set of wheels and tires, ready-to-go, which happened to be mounted on exact same type of aftermarket racing wheels. Again, I like your idea in this context.

Human, who sports only naturally-occurring DNA ~ oneironaut ~ broadcaster

Reply | Quote