BSOD Memory_management

[Bill_Bright]

Despite being maintained by PassMark, MemTest86 is still a single-threaded application at core, incapable of real multi-threading without producing false positives. Insufficient for today's hardware and must be written from scratch.

I sure wish people would do their homework before posting.

PassMark's MemTest86 has tested in multi-thread mode since 2011 - where the hardware supports it.

And so what? You are testing the RAM, not the CPU. And that is the same issue with your HCI MemTest so why would you suggest it if it "should not be used in 2019"? That makes no sense and, as I noted, is just not accurate.

RAM testing does not care how many threads or cores on the CPU you are using - except to improve testing speeds. That is why it is incorrect to say it is "intended for single-core processors with discrete memory controller and shouldn't be used in 2019."

I've been doing hardware tech support since the early 70s and MemTest86 on DEC and Vax systems since the late 80s. I have never - not once seen a "false positive" (with any decent tester!). A false positive would be where the program reports the RAM is faulty, but it is really good. If any error is reported, the RAM is bad. The problem is, no errors might be reported, but the RAM is still faulty - but that is the case with any software based memory tester, including your suggested HCI MemTest.

And to your HCI MemTest, there is nothing in its documentation about multi or single threaded application.

As I noted above, no software based program is conclusive. But to suggest it cannot do its job because it is single threaded (which was wrong to begin with), or that it should not be used in 2019 is just bad information and advice.

Sorry. Nothing personal. Those are just the facts and that's what matters here.

 

[Regeneration]

I sure wish people would do their homework before posting.

PassMark's MemTest86 has tested in multi-thread mode since 2011 - where the hardware supports it.

And so what? You are testing the RAM, not the CPU. And that is the same issue with your HCI MemTest so why would you suggest it if it "should not be used in 2019"? That makes no sense and, as I noted, is just not accurate.

RAM testing does not care how many threads or cores on the CPU you are using - except to improve testing speeds. That is why it is incorrect to say it is "intended for single-core processors with discrete memory controller and shouldn't be used in 2019."

I've been doing hardware tech support since the early 70s and MemTest86 on DEC and Vax systems since the late 80s. I have never - not once seen a "false positive" (with any decent tester!). A false positive would be where the program reports the RAM is faulty, but it is really good. If any error is reported, the RAM is bad. The problem is, no errors might be reported, but the RAM is still faulty - but that is the case with any software based memory tester, including your suggested HCI MemTest.

And to your HCI MemTest, there is nothing in its documentation about multi or single threaded application.

As I noted above, no software based program is conclusive. But to suggest it cannot do its job because it is single threaded (which was wrong to begin with), or that it should not be used in 2019 is just bad information and advice.

Sorry. Nothing personal. Those are just the facts and that's what matters here.

Ever since Nehalem, memory bandwidth is somehow capped per core, unless other cores are in deep sleep.

To fully stress test memory modules, the memory must be accessed by several cores simultaneously. Otherwise, it will fail to detect some errors (bad configuration, overheating, lack of voltage, wrong timing) even after 10 hours.

HCI MemTest is outdated too, but you can run several instances of it, and assign each to a core / virtual core.

You should be using MemTest64 / AIDA64 Memory Stress Test / several instances of HCI MemTest to check for RAM errors.

Single core operation, obsolete in 2019, will only detect extreme errors or defective memory chips.

 

[Bill_Bright]

Gee whiz. In other words, you are now confirming what I said all along - that is, no software based program is conclusive therefore users need to swap in known good RAM to see if the problems recur.

To fully stress test memory modules, the memory must be accessed by several cores simultaneously

Which MemTest86 does - again if you did your homework you would see.

I see no reason to continue this side discussion so I'm done here. Have a good day.

 

[silentbogo]

Ever since Nehalem, memory bandwidth is somehow capped per core, unless other cores are in deep sleep.

Unlike v4 which you are probably thinking about, the modern implementation is completely based on UEFI (can even be installed as a UEFI App on your PC). Legacy stuff has been completely removed (incl. BIOS support, PAE-based addressing, etc). New version does not have any downsides of the legacy version. Even devs themselves stated that v5 was re-written from scratch in order to address all issues at once.
Plus you are forgetting the main purpose of memtest: it was created to detect memory errors, like in OPs situation (e.g. faulty cells, banks etc). Overclocking stability testing is just a side-effect which over time grew up to be a full feature.

You should be using MemTest64 / AIDA64 Memory Stress Test / several instances of HCI MemTest to check for RAM errors.

That's a good way to test memory bandwidth and overall performance, but that' where it ends.
You will get jack shit for accurate error testing, since: a) you don't have access to the entire memory pool; b) your tests are running behind a dozen levels of abstraction; c) even if you do get errors, you don't know what's the cause due to .
Even something as banal and boring as running mdsched will give you more accurate results.

As much as I like what W1zzard has done with the tool, it's pretty much useless. Tested it on several Asus Zenbooks with some dead RAM just for fun (rarely booted between BSODs), and 4-5 runs wouldn't find a single error, cause the problematic addresses were out of userland's reach (reserved by system). Legacy memtest86 v4 found consistent errors on the first run within minutes.

 

[eidairaman1]

No point in argiung when @IceScreamer hasn't been back to post results...

 

[IceScreamer]

Oh, I was gonna write that everything is fine so far. So from now on, if I don't post anything it means that everything is ok. It appears that the pagefile rebuild helped.

 

[trparky]

OK, this may seem like a really dumb question but wouldn't the page file be rebuilt every time you reboot the system? Think about it, when you reboot the system you're essentially starting out with a clean memory slate. Any and all stuff in memory is wiped out so what is in the page file is useless. Right?

 

[IceScreamer]

OK, this may seem like a really dumb question but wouldn't the page file be rebuilt every time you reboot the system? Think about it, when you reboot the system you're essentially starting out with a clean memory slate. Any and all stuff in memory is wiped out so what is in the page file is useless. Right?

To be honest I know very little about this, but I figured since it is a file that is being written to it could have gotten corrupted somehow, especially when I cloned the drive. But as I said, I could be wrong.

EDIT: So I found this: "As most of you know, whenever you shut down your system, the contents of the memory (RAM) are automatically lost due to the loss of power. But when it comes to the pagefile, the content stays intact unless Windows removes them. This makes it possible for others to probe for data in the pagefile. "

 

[Regeneration]

OK, this may seem like a really dumb question but wouldn't the page file be rebuilt every time you reboot the system? Think about it, when you reboot the system you're essentially starting out with a clean memory slate. Any and all stuff in memory is wiped out so what is in the page file is useless. Right?

Not by default to quicken shutdown time. Where data security is crucial, registry entry ClearPageFileAtShutdown can be used to force pagefile cleanup at shutdown. But rebuilding the pagefile will tear down SSDs more quickly, slow down boot and shutdown time. Full disk encryption is a better option.

 

[trparky]

Not by default to quicken shutdown time. Where data security is crucial, registry entry ClearPageFileAtShutdown can be used to force pagefile cleanup at shutdown. But rebuilding the pagefile will tear down SSDs more quickly, slow down boot and shutdown time. Full disk encryption is a better option.

I didn't think about that. That makes sense.

 

[eidairaman1]

To be honest I know very little about this, but I figured since it is a file that is being written to it could have gotten corrupted somehow, especially when I cloned the drive. But as I said, I could be wrong.

EDIT: So I found this: "As most of you know, whenever you shut down your system, the contents of the memory (RAM) are automatically lost due to the loss of power. But when it comes to the pagefile, the content stays intact unless Windows removes them. This makes it possible for others to probe for data in the pagefile. "

I would say it's imperative for critical items to be cleared out of the paging file. There is a command and windows that you enable via either Group Policy editor or the registry and it will delete the paging file on shut down every single time. Minor warning is that Windows might take a little bit longer to shut shutdown and startup.

 

[Bill_Bright]

OK, this may seem like a really dumb question but wouldn't the page file be rebuilt every time you reboot the system?

Yes. While the file itself may stay on the disk, the priority of the data within it is reset every time you reboot - or even as you keep using Windows and open and close programs. For example, if you use Word and Windows stuffs data about Word in the PF, it that data is not going to stay as a priority if you close Word and move on to other tasks. Windows is smarter than that. The PF is there as part of the "virtual memory" the OS uses for "high priority" data. If Word is closed, that data is no longer high priority and it will be replaced, if the space is needed for newer, high priority data.

 

[IceScreamer]

Well, this now got even weirder. I just got a BSOD again, but now its QUOTA_UNDERFLOW.

This is the exact text from WhoCrashed:

On Tue 15.1.2019. 9:01:57 your computer crashed or a problem was reported
crash dump file: C:\Windows\MEMORY.DMP
This was probably caused by the following module: Unknown (0x000000000BFCCDF7)
Bugcheck code: 0x21 (0xFFFFFA800884A510, 0x2, 0xC000071, 0xBFCCDF7)
Error: QUOTA_UNDERFLOW
Bug check description: This indicates that quota charges have been mishandled by returning more quota to a particular block than was previously charged.
A third party driver was identified as the probable root cause of this system error.
Google query: QUOTA_UNDERFLOW

I think I'll have to nuke this from orbit. It just keeps happening so randomly. Googling the module number that apparently caused the issue returns nothing so I can't even troubleshoot this.

 

[silentbogo]

Googling the module number that apparently caused the issue returns nothing so I can't even troubleshoot this.

1) replace memory with known working sticks
2) Run memtest86 (or at least mdsched if you manage to boot into windows)
3) Check HDD for defects (use Victoria HDD, do a full surface scan)
4) If nothing helped - replace the MoBo.
Since your previous BSODs were also related to system memory and you did not install any new drivers recently, it's safe to assume that it's not a software problem.

 

[IceScreamer]

1) replace memory with known working sticks
2) Run memtest86 (or at least mdsched if you manage to boot into windows)
3) Check HDD for defects (use Victoria HDD, do a full surface scan)
4) If nothing helped - replace the MoBo.
Since your previous BSODs were also related to system memory and you did not install any new drivers recently, it's safe to assume that it's not a software problem.

I mean the computer works great up to that point, Word, AutoCAD, Inventor, games, everything works, and then it just crashes, and not regularly.
Will have to source some new sticks for no.1. I ran memtest86 but I'll run it again for good measure and after that will check the HDD.
This is all so baffling, especially since I can't look up the module that causes these issues. I'm having more and more doubts about a bad HDD clone.

 

[silentbogo]

I'm having more and more doubt about a bad HDD clone.

Did you clone the drive from a PC with different arch, or was it just the storage upgrade on this PC?

 

[IceScreamer]

Did you clone the drive from a PC with different arch, or was it just the storage upgrade on this PC?

It was the same PC as this one, I cloned my old WD 160GB to this new WD 1TB drive, and the only hardware change was a CPU upgrade from i3 2100 to i5 2400, and a CPU cooler upgrade, but that was a while ago.

 

[Regeneration]

Can you upload the dump file?

 

[IceScreamer]

Can you upload the dump file?

I was going to but it's a MEMORY.DMP file, 500MB in size. I mean I could but not till afternoon.

 

[Regeneration]

Well, it seems you know what you're doing. My guesses are bad driver, bad cloning, bad memory, or bad HDD.

Scan the drive for errors (surface scan), scan the memory, try a fresh OS installation (complete re-partition). Make sure the BIOS/UEFI is updated and configured properly.

If you cloned from another PC (even with same hardware), it is possible for drivers to misbehave. Reinstall all drivers.

Look at the bright side, the BSOD code has changed, that's an improvement.

 

[IceScreamer]

Well, it seems you know what you're doing. My guesses are bad driver, bad cloning, bad memory, or bad HDD.

Scan the drive for errors (surface scan), scan the memory, try a fresh OS installation (complete re-partition). Make sure the BIOS/UEFI is updated and configured properly.

If you cloned from another PC (even with same hardware), it is possible for drivers to misbehave. Reinstall all drivers.

Look at the bright side, the BSOD code has changed, that's an improvement.

Yup, I just did another memtest86 scan, this time with the latest version, still no errors. About to do an HDD surface scan too. If that shows no errors then I'll try to use the PC as little as possible, only for the necessary stuff till I get a reasonable time window to reinstall the OS and download all my software. Thanks again for the help.

 

[trparky]

Yup, I just did another memtest86 scan, this time with the latest version, still no errors.

How long did you run it for? I'd suggest running it for no less than 24 hours.

 

[IceScreamer]

How long did you run it for? I'd suggest running it for no less than 24 hours.

This version does 4 runs on it's own, lasts about 2-3 hours. Previous one I ran for 12 I think, also no errors.
HDD surface scan also showed no errors.

 

[Regeneration]

First uninstall ALL drivers and reinstall them.

I assume your previous HDD was SATA2, and the new one is SATA3.

Try a new SATA cable and then try using the secondary SATA controller.

 

[eidairaman1]

Id get a fresh drive, no os at all, fresh OS, not image, test if it crashes then its probably ram