Windows 10 BSOD MEMORY_MANAGEMENT in ntoskrnl.exe and sometimes FLTMGR.SYS [SOLVED]

[Fonebone]

I've been having them every few days since I upgraded from Win7. I did a clean install, but they persisted. I ran the driver verifier, and at first it crashed with the driver from NoMachine in memory, so I uninstalled that, but still kept getting BSOD. Ran driver verifier again and came up empty. Ran MEMTEST continuously for over 48 hours with no errors found. I used SeaToolsDOS223ALL.ISO to boot from CD and checked all HDDs. The only one with some shady sectors was an external. I kept it disconnected for awhile but still getting the BSODs. I upgraded my C: drive from HDD to SSD (was wanting to anyway, Samsung 850 EVO), no change. I ran SFC /scannow and dism /online /cleanup-image /restorehealth and there is the only thing I have not yet resolved or ruled out. I couldn't get it to fix the errors it found. Reading another one of your posts, I can't recall if I did them all from the same command prompt so I will go back and do that. In the meantime I'm attaching my crash reports files. This has gone on for months now and I'm going to beat this thing, dammit! Thanks in advance for your help.

 

[Sonny]

What is the make and model of your computer and your motherboard.

 

[Fonebone]

What is the make and model of your computer and your motherboard.

It's an Equus Nobilis with an Intel motherboard. I think all the system details are inside the MSINFO32.nfo file in the zipped archive.

 

[kemical]

Hi,
I will post back shortly with results but as you have many dump files we can look for patterns it just takes some time.

One thing I'm struggling with is the actual model of your machine. I know it's a Nobilis made by Equus Computer Systems but which Nobilis is it?

Check the manual, if you have one, to see if any numbers or letters accompany the model name.

Like i said i'll post again shortly..

 

[kemical]

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1A, {3f, 43dde, c7390ad1, c7390bd1}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+3efbf )

Followup: MachineOwner

Hi,
I went through all your dump files and apart from a bugcheck C9 all are like the above.
As the RAM is filled with data the process is being interrupted causing the bsod.

It's possible that either the data or the RAM is corrupted although after looking over everything I've a feeling that your system might be a little too old for Windows 10.
When you first upgraded did you try the compatibility test?

My initial thoughts are that you might save a lot of time and effort if you simply tried re-installing Windows 7. If the machine still blue screens then sure you know your problem is for definite but I would at least try if only to rule out the possibility.

Regarding the RAM situation, I have known of cases where Memtest86 would turn up nothing but yet the RAM was still faulty. Why no errors popped up I'm unsure, maybe it just simply wasn't run long enough. Now to make sure this isn't happening to you try running the system on one stick at a time. Do make a note of which stick is which and run on one at a time. If it produces a blue screen then remove it and install another and so on. Your looking for any sticks which do not bsod and if that happens you'll have your culprits. It's a bit of a pain I know but that's troubleshooting for you..

If you have information regarding the full model name of the desktop that would be great.

Post any new dump files.

I forgot something lol..

dfmirage.sys Fri Jan 11 21:04:26 2008: Mirage Driver by DemoForge, LLC. This is a little old for Windows 10. Please remove if no longer used or if possible update. Either way please uninstall to test.
(Hmm driver support stops at win 7)
Link Removed

 

[Fonebone]

Some further information that may make a difference on how to proceed with the troubleshooting:

I have several of these machines that are all the same because they came from my old office, but this is the only one I'm using now. At least one of them had a motherboard or onboard video chipset issue, but there are like 2 more that should be OK. I could completely swap out all the RAM, wait for a BSOD which always happens within a few days, and that should for sure prove whether it is or isn't the RAM, right? In retrospect, I probably should have already tried this, but I thought MEMTEST86 had ruled it out already.

Just so I can learn from this process: If it was the physical RAM wouldn't we expect the BSOD to occur with some random process in memory as opposed to the same one each time? Or can some specific physical location in RAM that pretty much always has the same thing loaded into it just flake out every now and then? And why just with Win10?

Regarding the specific model number, it is I288M. I couldn't find any info on Equus's website about it, and as I recall they were custom-built systems. It has an Intel DQ45CB system board, according to a sticker inside. The "AA" number on the board is E30148-302 and is not specified on Intel's website, so it's probably an OEM version of that board. It has an Intel E5400 series processor running at 2.70 GHz.

Before upgrading, I did the Windows 10 compatibility test and there were no problems. Other than the periodic (annoying) BSODs it has been running fine, not slow or glitchy or anything else. No perceptible performance loss compared to Win7, maybe even faster. I could try to upgrade one of the other machines to Windows 10 and if it also starts having the same kind of BSODs I guess that might mean there's some incompatibility in the whole platform itself. But what? Could it be a BIOS setting? Trusted platform module or trusted execution technology settings? It looks like I'm booting from legacy BIOS mode instead of UEFI mode and I know this system is UEFI capable - would that make a difference?

Where did you find that dfmirage.sys driver and what's it for? I'll look for it too.

 

[Fonebone]

Put replacement RAM in, now just waiting. I also removed the DemoForge Mirage driver. It's an add-on for TightVNC Server but not essential for its function. It was only installed recently so unlikely the issue, but just to be complete I got rid of it.

 

[kemical]

Hi, Fonebone,
first apologies I didn't answer sooner. I did actually write the post but just never posted it lol.. I'm a bit unwell at the moment (not to mention absent minded) so again sorry I didn't get back to you sooner. Below is my reply from yesterday but it sounds like you have things well in hand. Any problems or new dump files then please post back.

I could completely swap out all the RAM

Sure.. If you have other sticks you can use then try swapping them.

If it was the physical RAM wouldn't we expect the BSOD to occur with some random process in memory as opposed to the same one each time? Or can some specific physical location in RAM that pretty much always has the same thing loaded into it just flake out every now and then?

It doesn't really go into that much detail just that it could be either bad data or bad RAM.

Where did you find that dfmirage.sys driver and what's it for? I'll look for it too.

I found it in the driver stack section of the dump file.

 

[BIGBEARJEDI]

Hi,
A note on the Trusted Platform issue you mention in Post #6. We dealt with another user having problems with W10 with that option a few months back. Research has confirmed what you suspect. Computer with TPM are typically built and ordered for the US Government agencies (alphabet agencies, FBI, NSA, etc.) and law enforcement. Those computers are protected with forensic bio-engineering protection such as requiring a fingerprint, palmprint, or even an corneal-retina scan to unlock. I'm guessing that since you are running these computers at home, they were most likely discarded as old, or donated to you or whatever, but if you're going to use them with TPM disabled you will lose the ability to use your BIOS in UEFI mode. The TPM will only work in UEFI mode, not legacy mode. (again as you suspected correctly).

We've also noticed that machines that are UEFI capable and are older (older than W8/8.1/8.1.1), don't like to be set to run in legacy mode for W10. It's not that they won't work in legacy mode, they just don't like to work with W10. I ran across this in a few customer machines in the last several months. When you try to Clean Install W10 on a UEFI/LEGACY PC, it fails, sometimes with error codes, sometimes not. As soon as I switched those machines over to UEFI mode only, they would work on W10 for the most part.

Of course, we don't know what your home use is for these machines, or if you are reselling them to someone or not, but I think you can forget about them running W10 in UEFI mode with TPM enabled.

Hope that gives you some insight on that issue!

Best,
<<<BIGBEARJEDI>>>

 

[kemical]

Usually TPM is turned off by default and so shouldn't be an issue.

 

[Fonebone]

Well, it has been since last Friday that I swapped out all of the RAM and no BSODs. This is an unusually long interval for how frequently it usually was having them. My final troubleshooting step is this post to see if it has another one just to prove me wrong. So for now I'm going to call it solved. Thanks for the help!

 

[kemical]

It was bad RAM after all, despite running Memtest86+ for an extended time and multiple passes with no errors ever detected.

Hi Fonebone,
thank you for the update. As I said above I've seen this before with bad RAM and memtest86, I'm just so glad you had some spare RAM lying around.
As always if any issues should return then please don't hesitate to post back..

 

[BIGBEARJEDI]

Hey, that's Great you got it fixed!! Thanks for posting back and sharing with our other users.

BBJ

 

[Fonebone]

Well, bummer. I can't believe it went that long without one BSOD but today it had another one. So I guess it's not the RAM. I attached the new post-crash system logs, but I included only the most recent minidump file - see my original attachment for the rest if needed. I guess I can try to upgrade one or more of the other identical machines and see if it is inherent to this particular hardware configuration not liking Windows 10, though there still should be a way to trace it to which part of the hardware is causing problems, shouldn't there?

Any other potential causes I could be looking at?

Thanks!

 

[kemical]

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1A, {3f, 114f, 2ca9ff72, 2da9ff72}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+3efbf )

Followup: MachineOwner

Hi,
sorry to see the issue has returned and as you can see it's good old Bugcheck 1A
Can you remember where these sticks of RAM came from? Left over from an upgrade perhaps?

Can you run some basic tests please. Check the RAM with memtest86 and run a chkdsk on your SSD
Link Removed

Driver wise nothing is mentioned so see how those tests go and we'll take it from there.

Please post any new dump files.

 

[Sonny]

Had same problem with mine. I have a different board than you but when I went into bios and manually set my settings it stopped. I don't know if that would work on an Intel board or not. If nothing else works after doing what kemical has suggested you might want to try that as last option.

 

[kemical]

Good idea Sonny! As sonny suggests try disabling XMP profiles if your using them and then clock the RAM manually.

 

[BIGBEARJEDI]

Hey fonebone,
sorry to hear the problem has returned. I have 2 guesses to make at this point.

One is that this PARTICULAR Equus PC has a faulty Motherboard. Can you replace the Motherboard on this PC from one of your other identical Equus PCs that you said is running BSOD-FREE and install into the problem machine? Certainly, if the BSOD disappears on this machine with the replacement Mobo, that's a sure sign that the bad machine's Mobo is bricked and must be replaced (if you can even find them on Internet aftermarket such as ebay).

I've seen this problem many times during my career.

The other guess that just came to me was, nowhere in your thread did any of us ask about the source of your installation media. Was your installation media DVD or USB stick? If so, did you grab the W10 ISO file from anywhere other than the office Microsoft download site? If so, you could have a bad installation media. You also mentioned you did the upgrade to W10 online, so I'm assuming you got this machine to W10 via download from Microsoft servers right? If so, have you attempted a CLEAN INSTALL? If not, I would suggest you try this after the Mobo swap. If the Mobo swap still produces your BSODs, the only thing left is bad installation software. You'll be able to keep your W10 license key on the Clean Install as your successful initial W7->W10 upgrade has registered your key to that computer on the MS activation servers, so you'll be able to reactivate W10 (if it was properly activated during the upgrade before) without issue.

Let us know what you find.
Cheers!

BBJ

 

[kemical]

Hi,
before you run off stripping down computers please let us know the results of what was asked earlier. Apologies if this gets confusing.

 

[BIGBEARJEDI]

Hi,
Sorry, I may have jumped the gun when you asked for any other guesses as to what may be causing your reappearing BSODs. Please follow kemical's request for your dump files so he may analyze them again and see if there are any other software solutions available to you first! It's always best to try and find the problem in software before applying hardware fixes.

BBJ