• Happy holidays, folks! Thanks to each and every one of you for being part of the Tom's Hardware community!

Question Getting same BSOD multiple times a day - - - "Attempted write to readonly memory" ?

Toggle sidebar Toggle sidebar
ringmany

ringmany

Distinguished
Nov 6, 2014
210
8
18,695
Hi everyone,

I've been getting BSOD several times a day for like a week now. Done tons of hardware tests, virus scans etc, but I think from what I've been reading it may be related to drivers.
The main error itself on the blue screen is "attempted write to readonly memory"

I've got a recent memory dump here after enabling driver verifier.

https://drive.google.com/file/d/1X2vPs3pD5rgE1WXVYe0nSFsrlE9oSYXu/view?usp=sharing

There's some errors in there, one even mentioning discord, although after using WinDBG and analyse I'm still not 100% certain. Any ideas what might be causing the issue or which drivers?

Cheers
 
One dump isn't really enough to make any kind of reliable diagnosis, can you please upload ALL the dumps you have?

In addition, whilst Driver Verifier is a useful tool it needs to be enabled properly. Please follow these instructions...

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...
  • Special Pool
  • Force IRQL checking
  • Pool Tracking
  • Deadlock Detection
  • Security Checks
  • Miscellaneous Checks
  • Power framework delay fuzzing
  • DDI compliance checking
Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...
  • Wdf01000.sys
  • ndis.sys
  • fltMgr.sys
  • Storport.sys
These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running for 48 hours, use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing. The Driver Verifier generated BSODs are these...
  • 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
  • 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
  • 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
  • 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
  • 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
  • 0xE6: DRIVER_VERIFIER_DMA_VIOLATION
If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query. If drivers are listed then it's enabled, if no drivers are listed then it's not.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).
 
ubuysa said:
One dump isn't really enough to make any kind of reliable diagnosis, can you please upload ALL the dumps you have?

In addition, whilst Driver Verifier is a useful tool it needs to be enabled properly. Please follow these instructions...

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...
  • Special Pool
  • Force IRQL checking
  • Pool Tracking
  • Deadlock Detection
  • Security Checks
  • Miscellaneous Checks
  • Power framework delay fuzzing
  • DDI compliance checking
Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...
  • Wdf01000.sys
  • ndis.sys
  • fltMgr.sys
  • Storport.sys
These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running for 48 hours, use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing. The Driver Verifier generated BSODs are these...
  • 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
  • 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
  • 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
  • 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
  • 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
  • 0xE6: DRIVER_VERIFIER_DMA_VIOLATION
If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query. If drivers are listed then it's enabled, if no drivers are listed then it's not.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).
Click to expand...
Cheers for the reply,
Will look at enabling those settings.

In the meantime here are 5 of the previous memory dumps
https://drive.google.com/drive/folders/1JgSZpUzxpA-6KpUUhh8Im10VVevDoYT8?usp=sharing
 
Taken as a group my first reaction to these dumps is that it's most likely to be RAM. There are only two different bugchecks, 0x50 and 0xA, and whilst they are very often caused by bad third-party drivers there is no evidence of any third-party drivers being involved in any of these BSODs. That in itself is often a good indication that this is a hardware problem but, in addition, many of the dumps fail during memory management operations.

I can see from the dumps that you have 4 x 8GB RAM sticks installed, all of the same part number (which is good). Rather than run Memtest86 on 32GB of RAM, which will take some time and you won't be able to use the PC at all whilst Memtest86 is running, a better test will be to remove two RAM sticks for a few days and see whether the BSODs stop. If not then swap the sticks and run on just the other two. You'll soon see whether one pair BSOD and the other pair don't.

It is also worth leaving Driver Verifier enabled in the way I asked, just in case this is a third party driver that has ended before the BSOD happened. There are quite a few third-party drivers in the unloaded modules list, including a Logitech driver (lvrs64.sys) that dates back to 2012....
 
ringmany said:
Unfortunately I'm still getting constant BSOD. I have no idea what's causing it and it's happening so frequently now without any provocation. I've literally had 5 BSOD just today alone. I've attached some more memory dumps, any suggestions?
https://drive.google.com/drive/folders/1JgSZpUzxpA-6KpUUhh8Im10VVevDoYT8?usp=sharing
Click to expand...
I don't know what your system consists of, but first look at the memory, then the motherboard, and third in line the power supply.As you mention the problem, I would look at the memories, usually when their chips don't match and they have difficulty pairing and create continuous and random reboots
 
Co-signed; 0x50 and 0xA BSODs make me initially think the RAM is suspect. As the above poster recommended: Remove half the RAM sticks and run memtest86; repeat for the other two sticks.

Other then that, if running the XMP memory profile you could try running at stock just to eliminate that as a potential issue.
 
The RAM type can be had from the dump, all four are CMK16GX4M2B3000C15 - Corsair Vengeance LPX 8GB. However I do agree that bad RAM looks to be the most likely cause.
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom