Question "Attempted to write to read only memory" BSOD ?

MentalThinking

Distinguished
Sep 6, 2014
42
0
18,530
Hello -

For the last few weeks, I have had intermittent BSoD issues, always with the same stop code. I have run the suggested memory test on the Microsoft page related to this error and it says there's no issue with my RAM. I have also gone through the device manager and checked all drivers - all of which are up to date, including of course my graphics driver.

Using BlueScreenView is not helpful to me, as it only points towards ntoskrnl. So, I am here, asking the experts before I pull out my hair and reinstall windows. Linked below are two minidump files. Oddly, the latest minidump files refuse to upload, but the state of my computer was essentially the same in every single situation.

During each BSoD, I am playing a game via Steam, with a browser window open and perhaps Overwolf (a gaming overlay software).

Minidump 12/16/24
Minidump 12/17/24

Edit:
Computer Type: PC/Desktop
System Manufacturer/Model Number: Custom
OS: Windows 10 version is 22H2 (OS Build 19045.5247)
CPU: AMD Rayzen 5 7600 3.8GHz
Motherboard: Gigabyte B650M AORUS ELITE AX
Memory: G.SKILL Ripjaws S5 32GB (2x16GB)
Graphics Card: GeForce RTX 4070 WindForce 3 OC 12GB
PSU: Corsair RMx Series RM750x 80+ Gold Modular Power Supply 750W
SSD: Solidigm 670p QLC NAND PCIe 3.0 x4 NMVe m.2 2TB

All items in my PC are new, and were purchased in May of '23. The total used space on my SSD is 248GB.


Regards,

MT
 
Last edited:
Update your post to include full system hardware specs and OS information.

Include PSU: make, model, wattage, age, condition (original to build, new, refurbished, used).

Disk drive(s): make, model, capacity, how full?

Look in (as a starting point) Reliability History/Monitor for error codes, warnings, and even informational events be captured just before or at the time of the BSoDs. Click entries as applicable to obtain more details. The details may or may not be helpful.

Run "dism" and "sfc /scannow" to find and fix possibly corrupted files.

https://www.windowscentral.com/how-use-dism-command-line-utility-repair-windows-10-image

https://www.lifewire.com/how-to-use-sfc-scannow-to-repair-windows-system-files-2626161
 
Ralston18 -

Thank you for your reply. I have updated my original post with the specified information. I did look through those files before posting, but was unable to find anything that seemed anomalous or problematic - certainly nothing that trumpets 'this is the problem, fix this.'. In fairness, I am not an IT professional, so it's possible I overlooked something.

I will run the commands you suggested.

Edit: I have run both the sfc and DISM commands as outlined in the links provided, and both came back clean and error free.

Regards,

MT
 
Last edited:
Ralston18 -

Thank you for your reply.

Please see the following link. View: https://imgur.com/a/VW1VV0v


Apologies for earlier stating that I had looked at this - I had not, but had looked instead at the event viewer. The details offered in the critical events in those screenshots are all along the lines of:

(For the Windows stopped working error)

The computer has rebooted from a bugcheck. The bugcheck was: 0x000000be (0xffffc1401719c5e8, 0x8a00000000800121, 0xffffce0eb98b6820, 0x000000000000000a). A dump was saved in: C:\Windows\Minidump\121624-9265-01.dmp. Report Id: 26a55d2e-1ec4-4bad-8fcf-5194dcdbbcff.

or

(For Windows was not properly shut down)

The previous system shutdown at 1:53:50 PM on ‎2024-‎12-‎18 was unexpected.

Regards,

MT
 
From looking at the dumps I rather suspect that this is bad RAM. Both dumps fail during memory management operations and there are no indications of any third-party drivers being called, so bad hardware is more likely.

You have two sticks of 16GB G.Skill 6000MHz RAM installed, although they are clocked at their SPD speed of 4800MHz. The most effective way to test that RAM is to remove one stick for a few days, or until you get a BSOD. Then swap sticks and run on just the other for a few days. If it BSODs on each stick on their own then it's probably not bad RAM - but we need to eliminate that first.
 
Ubuysa -

You are perhaps right. Another forum suggested I run memtest86+ and an error was discovered relatively quickly during my test - I was told that if a single error was found, continued testing was not necessary -

xHtOn1l.jpeg


I am not entirely positive what this means for my next steps - likely, I should do as you suggest?

Regards,

MT
 
You have bad RAM, that's what that means - that's the source of all your problems. Try running Memtest86+ with one stick removed (ie. test each stick on their own) to find out which stick is bad.

If you decide to replace the faulty stick you should do so in one of only two ways...
  1. Buy a single new stick with EXACTLY the same part number as the existing stick.
  2. Sell the one good stick to someone else and buy a new pack of two matched sticks.
Mismatched RAM causes all sorts of issues and you should avoid mixing RAM types and models like the plague.
 
Ubuysa -

Thank you, I rather thought that might be the situation.

I consulted my motherboard manual (side note: I do not enjoy trying to read a PDF on my phone! I miss paper manuals.) discovered that one stick was already in the proper spot for a single stick to be used, and removed the other stick.

I am currently running memtest86 on the single stick, and it has completed 2 passes and has yet to throw an error.

I am off to bed now, but I will report back later with results!

Related: if this first stick does not turn out to be faulty, should I still take the time to run test on the second stick, just to rule out some other issue, or is it a given that the issue will lie with the second stick? I have not had this issue before, nor have I tried to troubleshoot myself.

I appreciate you mentioning the mixing of RAM - though, I think I've read it about four other places today. Both memory and motherboard manufacturers are quite clear that you ought not mix the sticks, as it were.

Regards,

MT
 
Hello -

The first stick ran all night and came up clean.

12 Passes, no errors.

The second stick is running now. Of note, when I seated the second stick, I wasn't fast enough to load into the boot options page, and attempted to restart once I reached the log on page.

The computer failed to do so, and I spotted a red light on my motherboard. This 'failure to restart' is an issue I've had since I've had this machine. Is it possible that a faulty RAM stick could have been at play the whole time, and degradation finally lead to my BSoD issues?

Regards,

MT
 
Hello -

The second stick ran while I was at work today, and has also come up clean.

14 Passes, no errors.

I gather my next step is to run the same test with the RAM in a different DIMM (likely the same one that was in use when the initial error appeared?) to see if the fault lies with my motherboard?

The manufacturer recommends using a specific DIMM for single module use - am I risking anything by not using the proper DIMM with only a single module?


Apologies if that's a silly question - I'm trying to learn as I go, here.

Regards,

MT
 
It's entirely possible that reseating the RAM has solved the problem, it's not uncommon.

No, don't try the RAM in a different slot, stick to the slot the motherboard manual specifies. You won;t do any damage by using the wrong slot, but you may have problems.

Now replace both RAM sticks, in the correct slots, and see how things go.
 
Ubuysa -

I seated both RAM as they were in the initial test, and my computer failed to boot. There was a red light on my motherboard, which made me think I had improperly seated a module, but I triple checked when installing. I checked again before removing a module to run the test I mentioned below. I am quite confused, as the system seems to boot fine with a single stick in either DIMM that I've tested so far.

Since I was unsure what to do, I ran MemTest86+ with a single module in the second DIMM (second that had been in use during the initial error) and it has returned clean after fourteen passes.

14 Passes, no errors. (Second DIMM)

I have double checked the manual, and the two DIMM in use are the recommended to use for dual channel with two modules. I will try reseating both sticks after I post this, but I thought I should let you know how things are going.

Regards,

MT
 
Last edited:
Ubuysa -

The modules are from the same package, bear the same branding, and have matching part numbers with sequential serial numbers. If they are not a matched pair, they're doing a great job pretending!

F5-6000J3636F16G is the part number returned by CPU-Z and this matches the stickers on each module, which I made sure to photograph during all of these tests, in case I needed the information for RMA purposes.

When the second stick (I call it this because it was initially installed into channel B) is seated in either channel A or B and I attempt to restart the system for some reason (such as when I am not fast enough to enter the boot options menu) sometimes the restart 'stalls' - and a red light appears on my motherboard.

Going off this alone, I would wonder if there were some issue with this particular module, but it continues to pass MemTest86+ just fine, no matter where it's seated.

12 Passes, no errors. (Second module, second DIMM)

Next time this occurs, I will photograph my motherboard.

Regards,

MT
 
Hello -

I reseated both sticks and have successfully begun another Memtest86 cycle. Good news! It's passed the first battery of tests. Despite my best efforts, I must have made a mistake seating them last time I sought to retest the pair.

I did once again experience a 'stalled' restart before I could begin the test, and photographed my motherboard. As you probably expected, the DRAM light is red.

View: https://imgur.com/a/0shYAC0


This *only* occurs when the 'second' module is seated, in my experience. But it has consistently passed the Memtest86 tests, and is technically currently *passing* another, provided an error doesn't occur later.

It is confusing.

Regards,

MT
 
They are seated in the correct slots? Check the motherboard manual, typically though it's A2 and B2. - which is where they were in those first dumps.

Also go into the BIOS and disable any XMP/DOCP profile (there was none in the first dumps). Also check that all RAM settings are at their default values.
 
@MentalThinking

Sort of following along here....

Noted in Post #11:

"The second stick is running now. Of note, when I seated the second stick, I wasn't fast enough to load into the boot options page, and attempted to restart once I reached the log on page."

My underline.

Just what/why "wasn't fast enough"?

With the system powered down and unplugged while swapping components, etc. there should be no need for speed or hurry.

Please clarify.
 
  • Like
Reactions: ubuysa
noticed you also have a old driver:
uvhid.sys Fri Nov 19 20:57:52 2021
you might want to remove or update it if you are not using it.
you can use microsoft autoruns64.exe to remove it.
might be a driver from unified remote.

note: looked at one bugcheck, looked like a bad page table entry that the system attempted to cleanup and bugchecked. system was running 55 minutes before the bugcheck.

note: both bugchecks were basically the same, bugcheck on cleanup of used virtual memory.

if this is not caused by bad RAM, I would be update the bios, and the chipset driver, any storage firmware and storage driver.

i would update or remove the unified remote virtual driver in case it was causing the bug. (best guess)
 
Last edited: