2 years of memory corruption and BSOD... but no bad RAM?

0

1

Here is a link to my Dropbox folder where I'm adding memory dumps as they're produced. It's the same as the link provided below. Also, the newest edits are at the top of this post. https://www.dropbox.com/sh/vw7zkiwbq7hh05p/AABxLOaKIc8V5djSgyy3sUWja?dl=0

EDIT: Another BSOD, while watching Netflix in Chrome. Added to the Dropbox link.

EDIT: Finally got another BSOD, and this one actually produced a full memory dump (1.07GB). It should be available at the same link below once it finishes uploading. I've compressed it to 181MB with 7zip, so that'll help some. This most recent crash was while watching Vimeo in the new Edge browser, but it's also happened while watching YouTube in Chrome. If anyone can provide any insight, I'd be grateful. Reminder, this is with the new PSU and all 16GB of RAM. The only pieces of electronic hardware I haven't completely replaced are the CPU, hard drives, and possibly the GPUs (it's been going on long enough that this particular problem might be newer than my GPUs). Thanks much!

EDIT: So I RMA'd my PSU, got the new one, installed it two days ago and everything has been fine until just now. Got an IRQL_not_less_or_equal BSOD. The worst news is that it seems like Windows didn't save a memory dump either :-( The only dump I have is from a while back. It might be because of low disc space on that disc, so I'll try to clear some up. The ONLY remaining components that haven't been totally replaced are the hard drives and the CPU.

EDIT: Here is a link to my RAM dumps. The complete dump is 800MB, so it's still uploading. I'll add more here as they are generated. It will be up for the foreseeable future. https://www.dropbox.com/sh/vw7zkiwbq7hh05p/AABxLOaKIc8V5djSgyy3sUWja?dl=0

Looks a lot like this problem: Frequent BSoDs regarding memory corruption ...but running SFC has never found any bad files.

There's a lot of background, so please bear with me. I'll try to be systematic.

I've been having intermittent BSOD crashes for the last 2 years, or so. Errors have included:

  • IRQL_NOT_LESS_OR_EQUAL
  • MEMORY_MANAGEMENT
  • PAGE_FAULT_IN_NONPAGED_AREA
  • BAD_POOL_HEADER

  • and others.

  • OS This started with Windows 7 and has continued with Windows 10. One such crash even necessitated a clean install of Windows 7, so that I could re-upgrade to Windows 10, so I've completely reinstalled the OS at least 4 times since these problems started.

  • GPU The problem started with one pair of non-SLI NVIDIA GPUs, and has persisted with a different pair of non-SLI NVIDIA GPUs.

  • Mobo This problem started with one ASUS motherboard, and has continued with a newer model ASUS motherboard.

  • RAM This problem started with one set of RAM and has persisted with a completely new set of RAM. At the same time I upgraded the motherboard, I also upgraded my RAM from 16GB of DDR3 1066 to 16GB of DDR3 1333, both G.Skill. (The GPU upgrade was a year or so before the mobo upgrade)

  • Disks I have four HDD, two of which are SSDs. One SSD is my boot disk, the other three are storage. I've run a pagefile on all four disks, no pagefile at all, only on the SSDs, only on the conventional disks, and everything in between, with BSODs occurring in every configuration. The OS disk has been formatted a few times as part of an install, but the other disks have been largely unchanged. I think this problem started while I still had my OS on a conventional disk, but I can't remember for sure.

  • Power I have a 750 watt PSU that's 3-4 years old, never seemed to have issues... but this might be that. I'm also on an uninterruptible power supply, but it's not reported switching to battery power since I installed it a couple of months ago.

I've run MemTest a half-dozen times, never with any faults at all, but only on the first set of RAM. More recently, I ran Windows Memory Diagnostic on all four modules, and got some faults. Then I ran it on only two, with no faults, then on the other two, with no faults. Each test was 3 passes of the "Extended" test set.

I've run verifier.exe, but it's fairly opaque, so I don't know if it gave me any useful information.

I've been using the home version of WhoCrashed to look at minidumps, but I recently discovered WinDBG (WHY IS THIS NOT A STANDARD OS FEATURE?!?!?!), but I've only produced two dumps since discovering it, so not a lot of new info. One dump pointed to "memory_corruption," which is what prompted running WMD.

I have two minidumps and a memory.dmp that I can share via Dropbox, if anyone things they'd be useful, but they're only from the last two days.

Thanks for any suggestions.

mHurley

Posted 2015-11-13T16:59:40.563

Reputation: 163

To test ram thoroughly you should be letting Memtest run for 48-72 hours PER STICK. – Ƭᴇcʜιᴇ007 – 2015-11-13T17:04:20.210

2Obvious conclusion I have is it has nothing to do with memory. You supplied has with zero information about the BSOD you can't specifically. So there isn't any way we can look at the .dmp file ourselfs to analysis them. If WDM indicates a failure though there is a good chance there is a failure, but you running MemTest for a significant amount of time, and providing additional information will go a long way. – Ramhound – 2015-11-13T17:05:09.050

Wow, run MemTest for TWO WEEKS for four sticks of RAM? That seems excessive. If I'm getting a BSOD every other day or so, then it seems like Memtest ought to trigger that condition in one or two passes. It'll be nearly impossible to schedule that much down time for my machine, but I'll see what I can do to run a longer test. – mHurley – 2015-11-13T17:17:22.797

Two weeks to test, vs. another 2 years of BSoD? You could also go get other, known-good sticks of RAM and use them to test instead. but seeing that you've already replaced the RAM once, then there's a good chance you probably don't have a memory issue. The Stop codes you've reported generally point to either bad RAM, or a bad driver, but they are also pretty generic, and there could be multiple reasons you've gotten them of the last two years. You need to have it crash, and then keep investigating it until you find a cause. WinDBG may be hard to follow, but it's the tool you need ot use. – Ƭᴇcʜιᴇ007 – 2015-11-13T17:41:10.537

1Memory corruption happens more often because of bugs in driver code (use after free, race conditions through incorrect use of locking primitives) than bad hardware. So I'd blame those unless you can see single bit flips in the dumps. – Vojtech – 2015-11-13T18:05:54.260

share the dmp files, so that we can also take a look at them. – magicandre1981 – 2015-11-13T18:32:32.157

1I'd look at what you haven't changed out. Power Supply & CPU. Being on a battery backup unit, isn't going to resolve a possible problem with a power supply. You said it hasn't "Switched to better power" which I assume means it hasn't gone to battery mode. The cheaper BBU units provide pretty dirty power when running in battery mode. The nicer ones have a line conditioner that will even it out. If this computer was on my bench to look at, I'd swap PSU. – N. Greene – 2015-11-13T19:39:34.717

@N. Greene, Yes, "better" should have read "battery." The PSU is about the only thing left to check, besides the CPU, but I don't have another $100 to shell out on a new PSU for testing. Is there a (simple) way to test it without replacing it? magicandre1981, sure thing. I'll try to put them up later. Ƭᴇcʜιᴇ007 I don't mean that 2 weeks is more time than I want to spend. I mean that 2 weeks is more time than makes sense. I have to defer, because I probably know less about RAM than you, but it doesn't seem like there's a good reason for it to take that long. – mHurley – 2015-11-13T20:58:46.887

2Sell your UPS so you can test the remaining parts. The equipment to properly test a PSU without replacing it costs about ten times more than a PSU. – qasdfdsaq – 2015-11-13T23:05:20.890

Lol, good to know. – mHurley – 2015-11-13T23:11:37.130

1BSOD symptoms that are "all over the place", as yours are, are most commonly due to hardware rather than drivers. Replace your PSU. – Jamie Hanrahan – 2015-11-14T03:24:38.797

@mHurley - Can you do a better job providing labels to your files? I can't tell which is the old and new .dmp files unless I look at the revision history. I see how you just linked to your entire folder...not the best way to link us files, but acceptable. – Ramhound – 2015-12-03T19:04:03.270

Sorry, I'll go make that more clear. My intention was to provide a single link that'd always be up to date, even as I added new dumps. – mHurley – 2015-12-08T16:56:06.313

Answers

2

Ok, I looked at your memory.dmp file. It appears that a thread belonging to one of the Chrome processes was near the "end stages" of completing a write to a "named pipe" object, implemented by npfs.sys, the "named pipe file system" driver.

Here's what's relevant about named pipes/npfs.sys: It is an interprocess comm mechanism implemented as a pseudodevice. It is very well-established stable code. It's been in Windows for forever. It is used by a great many internal Windows processes. It's not surprising that Chrome is using it (for comm between Chrome's various processes).

And, as a pseudodevice, it is not specific to any hardware. So every Windows machine that is running the same version of the OS is running the same binary of npfs.sys. This is not like a wireless card or video card where there are many different "WiFi" or "video" drivers out there.

So we can be fairly confident the problem is not in npfs.sys. And it certainly isn't in IopCompleteRequest (the routine that raised the unhandleable exception, by trying to write to a not-defined address, which was the final "cause" of the crash). Both of these are very heavily exercised and well-trusted code. The other kernel mode routines on the stack are NtWriteFile and KiSystemServiceCopyEnd - likewise not at all likely suspects. (NtWriteFile is invoked for every write function to every file or device; KiSystemServiceCopyEnd for the vast majority of calls from user to kernel mode - and btw it has nothing to do with service processes.)

As I said in a comment above - I would replace the power supply. I have seen PSUs cause similar flurries of "widely variant" BSODs before. Be sure you get one with one big 12 volt rail, not multiple rails - this provides the best protection against momentary sags and spikes. This is particularly important given that you have two GPUs.

Jamie Hanrahan

Posted 2015-11-13T16:59:40.563

Reputation: 19 777

This is excellent information, thanks! I'll let you know how it goes. – mHurley – 2015-11-14T13:37:20.150

IT'S STILL UNDER WARRANTY!!!! But only for another 3 weeks, lol – mHurley – 2015-11-14T14:55:54.290

Got the new PSU installed 2 days ago... just got another BSOD... AND it looks like Windows didn't keep the memory dump :-( – mHurley – 2015-11-24T15:00:56.183

None at all? Not even a minidump? – Jamie Hanrahan – 2015-11-24T23:06:08.900

Not even a minidump :-( I double checked the settings and it was set to NOT overwrite any existing dump, so I changed that and it'll hopefully work next time. – mHurley – 2015-11-24T23:10:12.933

Asked: 2015-11-13T16:59:40.563

Viewed: 736 times

Active: 2015-12-08T16:58:02.653