MEMORY_MANAGEMENT bsod related to ntoskrnl.exe

Apr 30, 2018
3
0
10
Hey all. I have a custom built PC dating back to about 2013-2014. It was built for me by an outside company and has run flawlessly until a month or so ago, when I started getting alarmingly frequent BSODs (not daily, but I did get 2-3 in a week, up from absolute zero). I updated all of my drivers and ran all the Windows updates I could at that time. (I think there's another one pending now that I'm currently installing; I don't know if it's related.) And then last night, a little after midnight, it crashed on me again.

I genuinely know very little about computers, and have gotten this far based on patching together understanding from a myriad of Google searches, but on this one, I'm stumped. Any clues you can give me to point me in the direction of a fix are beyond appreciated.

You can see the snapshot of the dump from bluescreenview here, or grab the whole dump file yourself here.
 
Solution
Allrighty. It seems that the hardware is ok, and Windows itself isn't coming apart at the seams.

Move on to making sense of the BSODs themselves, and their underlying cause(s). Two links. The first is an overview of BSODs for various Windows versions, and error codes, but most important, how to collect and see crash dump data.

The second focuses on the memory management issue, and possible causes.

https://mikemstech.blogspot.co.uk/2011/11/windows-crash-dump-analysis.html

https://mikemstech.blogspot.co.uk/2011/12/troubleshooting-0x1a-memorymanagement.html

Hopefully that takes you closer to the solution. If you don't have any current crash data to work with, just wait for the next one.
(Assuming you don't have an overclocked system - if you do, reset to stock settings)

Save any work, and type WinKey + R to open the run box and type "mdsched", then let it restart and run the program.

Settle down to wait for the results. Two passes should be enough. If after 2 hours it hasn't finished, stop it, and report back with it's % progress. More RAM takes longer, but it shouldn't takes hours and hours. It might take 10-20 minutes if you're lucky.

Basically you 'want' to trigger a BSOD with the memory test on stock RAM settings. Of course you don't want to have faulty parts, but if they're faulty it's good to have it confirmed.
 
If the first "done" means you reset to stock from an overclock, then stay at stock and see if the system still throws up BSODs. Then it's a case of not trusting the old overclock settings (too high, too hot, or not enough voltage).

Try running sfc /scannow - https://support.microsoft.com/en-gb/help/929833/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system

Other than that, I might suspect some update or driver prior to the first instance of the BSODs. Maybe roll-back a driver, or go looking for error logs that gleans more information of what's at the root of it all.
 
Apr 30, 2018
3
0
10

Ah, sorry, I should have specified! I... don't know the first thing about overclocking, LOL. I don't really even know what it entails, so I've always run on stock settings. But yeah, ran the mdsched & now the sfc with an all clear on both.
 
Allrighty. It seems that the hardware is ok, and Windows itself isn't coming apart at the seams.

Move on to making sense of the BSODs themselves, and their underlying cause(s). Two links. The first is an overview of BSODs for various Windows versions, and error codes, but most important, how to collect and see crash dump data.

The second focuses on the memory management issue, and possible causes.

https://mikemstech.blogspot.co.uk/2011/11/windows-crash-dump-analysis.html

https://mikemstech.blogspot.co.uk/2011/12/troubleshooting-0x1a-memorymanagement.html

Hopefully that takes you closer to the solution. If you don't have any current crash data to work with, just wait for the next one.
 
Solution