ATTEMPTED_WRITE_TO_READONLY_MEMORY: Finding The Offending Module

Contents show

Introduction

The Windows stop code ATTEMPTED_WRITE_TO_READONLY_MEMORY (also written as STOP 0x000000BE, 0xBE, or “attempted write to read only memory”) is a critical BSOD that usually points to a faulty driver or memory corruption. It often appears after installing a new driver or update, adding hardware, or changing BIOS/UEFI settings. Left unresolved, this error can lead to repeated crashes, data loss, and system instability.

This guide goes far beyond generic advice. You’ll get a step-by-step, practical workflow to isolate the offending module (driver or kernel component), analyze minidumps, run advanced diagnostics like Driver Verifier, and apply proven fixes—from simple driver rollbacks to in-place upgrades. If your goal is to definitively identify what’s causing ATTEMPTED_WRITE_TO_READONLY_MEMORY and get your PC stable again, this is the most complete guide you’ll find.

Understanding the Error

The ATTEMPTED_WRITE_TO_READONLY_MEMORY bug check means a kernel-mode component—almost always a driver—tried to write to a read-only memory page. Windows protects certain memory regions from writes; when something violates that protection, the OS halts to prevent corruption.

Technical summary (plain language):
- A driver attempted to modify memory it shouldn’t (read-only).
- Windows detected the illegal write and triggered a BSOD with stop code 0xBE.
- The kernel captures debug data in a minidump to help pinpoint the culprit.
Common scenarios:
- Right after installing or updating GPU, storage, network, or security (antivirus/VPN) drivers.
- Following a Windows Update, feature update, or cumulative update that exposed a buggy driver.
- After enabling XMP/EXPO, overclocking, or changing BIOS/UEFI options.
- On systems with failing RAM, aggressive memory timings, or borderline PSU power delivery.
- When malware or low-level tools (e.g., disk encryption, filter drivers, overclock/RGB control utilities) hook into the kernel improperly.

Note: The 0xBE parameters (visible in a dump) are often useful:

Parameter 1: Address being written to (virtual address).
Parameter 2: IRQL at the time of the reference.
Parameter 3: Value attempted to be written.
Parameter 4: Address of the instruction that attempted the write.

Common Causes

Below are the most likely triggers for the ATTEMPTED_WRITE_TO_READONLY_MEMORY BSOD. Focus on recent changes first.

Faulty or incompatible drivers
- Graphics, storage (SATA/NVMe), Wi‑Fi/Bluetooth, chipset, security/AV, VPN, USB, RGB/control utilities, virtualization tools.
Memory (RAM) issues
- Defective modules, unstable XMP/EXPO profiles, mismatched kits, incorrect voltages/timings.
Disk or file system problems
- Bad sectors, failing SSD/HDD, corrupted system files.
BIOS/UEFI/firmware problems
- Outdated firmware, problematic settings (e.g., aggressive power states, CSM toggles).
Windows updates or feature upgrades
- Edge-case driver regressions surfaced by new kernels.
Malware or low-level utilities
- Kernel hooks from malware, encryption/file-system filter drivers, questionable driver “updaters.”
Overclocking and power instability
- CPU/GPU/RAM overclocks, undervolting, insufficient PSU, thermal issues.

Preliminary Checks

Before deep diagnostics, perform these quick checks to reduce variables and protect data.

Boot into Safe Mode
- If you can log in:
  - Settings > System > Recovery > Advanced startup > Restart now.
  - Troubleshoot > Advanced options > Startup Settings > Restart.
  - Press 4 (Enable Safe Mode) or 5 (Safe Mode with Networking).
- If you can’t log in:
  - Force Windows Recovery Environment (WinRE): power on, then hold the power button to interrupt boot. Repeat 2–3 times until “Preparing Automatic Repair” appears. Then:
    - Troubleshoot > Advanced options > Startup Settings > Restart > press 4.
Back up important data
- Prioritize Documents, Desktop, Pictures, project folders, and anything under C:\Users\.
- In WinRE: Troubleshoot > Advanced options > Command Prompt, then copy to an external drive with robocopy:
  
  robocopy “C:\Users\YourName” “E:\Backup\YourName” /MIR /XJ
Run basic health checks
- Open an elevated Command Prompt (Run as administrator).
- System file checker and component store repair:
  
  DISM /Online /Cleanup-Image /RestoreHealth
  sfc /scannow
- Check the disk (schedule for reboot if needed):
  
  chkdsk C: /f /r
- Optional quick scan without repair:
  
  chkdsk C: /scan

If problems persist after these basics, proceed to deeper steps.

Step-by-Step Troubleshooting

Work through these steps in order, from simplest to most advanced. The goal is to find the offending module and stabilize your system.

1) Remove recent changes and reduce variables

Disconnect non-essential peripherals (USB hubs, external drives, RGB controllers).
Revert any overclocking/undervolting. Disable XMP/EXPO temporarily.
Uninstall recently added drivers or software, especially kernel-level utilities (VPN, AV, disk tools).
If the issue started after a Windows Update, note the update KB and driver versions.

2) Clean boot to rule out third-party services

Press Win+R > type: msconfig
On the Services tab: check Hide all Microsoft services > click Disable all.
On the Startup tab: open Task Manager > Disable all startup items.
Reboot and test. If stable, re-enable items in batches to identify the culprit.

3) Update or roll back critical drivers

Focus on drivers historically linked to 0xBE:

Display (GPU): NVIDIA/AMD/Intel.
- Use a clean install option or DDU (Display Driver Uninstaller) in Safe Mode if necessary.
Storage/NVMe/SATA: Intel RST, AMD SATA, Samsung NVMe, Micron, WD.
- Try the latest OEM driver—or roll back to the Microsoft Standard NVMe driver to test.
Network: Intel/Realtek Wi‑Fi and Bluetooth.
Chipset: AMD or Intel chipset packages from your motherboard/laptop OEM.
Security/VPN: Uninstall third-party antivirus, endpoint security, and VPN temporarily. Rely on Microsoft Defender for testing.

Device Manager tips:

Right-click a device > Properties > Driver tab > Roll Back Driver (if available).
Use Driver Details to see the exact .sys module involved.
Prefer drivers from your system/motherboard OEM support page over generic ones when stability is the priority.

4) Check SMART and disk health

Use a reputable utility (e.g., CrystalDiskInfo) to view SSD/HDD SMART status. If you see reallocated/pending sectors or media errors, back up immediately and replace the drive.
For Windows-native check, PowerShell (admin):

Get-PhysicalDisk | Select FriendlyName, HealthStatus, OperationalStatus, Usage, Size

5) Memory stability: test RAM thoroughly

Start with Windows Memory Diagnostic:
- Press Win+R > mdsched.exe > Restart now and check for problems.
For deeper testing, use MemTest86 (USB boot) and run multiple passes.
- Test with one stick at a time and rotate slots to isolate a bad module or DIMM socket.
If XMP/EXPO is enabled, test again with it disabled or with looser timings and appropriate voltage (per vendor spec).

6) BIOS/UEFI sanity check and update

Enter BIOS/UEFI (usually Del, F2, or Esc at boot) and Load Optimized Defaults.
Ensure memory is at JEDEC defaults while troubleshooting.
Update to the latest BIOS/UEFI and SSD firmware (from OEM vendors). Read release notes for stability fixes.
Avoid aggressive features temporarily (e.g., Fast Boot, legacy CSM toggles, unusual PCIe bifurcation).

7) System Restore (if available)

WinRE > Troubleshoot > System Restore > choose a restore point from before the BSOD began.
This can revert drivers, registry, and system files without affecting personal data.

8) Analyze minidumps to find the offending driver or module

If the crash reports are enabled, this step is often decisive.

8.1 Enable and locate minidump files

Press Win+R > sysdm.cpl > Advanced tab > Startup and Recovery (Settings).
Under “Write debugging information,” select Small memory dump (256 KB).
Ensure the dump directory is: %SystemRoot%\Minidump (usually C:\Windows\Minidump).
Make sure a page file exists on the system drive (Automatic is fine).
After the next crash, retrieve the latest .dmp from C:\Windows\Minidump.

8.2 Quick analysis with BlueScreenView

Install BlueScreenView (NirSoft).
Open the latest .dmp and review:
- Caused By Driver (e.g., nvlddmkm.sys, iaStorA.sys, dxgmms2.sys, tcpip.sys, aswSP.sys).
- The stack and “Probably caused by” line.
If a third-party .sys appears repeatedly, that’s your prime suspect.

8.3 Deep analysis with WinDbg (Preview)

Install WinDbg (Preview) from the Microsoft Store.
File > Open dump file > select the latest minidump.
Set symbols (Run in the command box at the bottom):

.symfix
.sympath+ srvC:\Symbolshttps://msdl.microsoft.com/download/symbols
.reload /f
!analyze -v
Inspect the output:
- Look for BugCheck 0xBE and the “Probably caused by” line.
- Identify the faulting instruction address (Parameter 4) and module:
  
  lmvm
  
  This shows the driver provider, version, timestamp, and path (e.g., C:\Windows\System32\drivers\xxxx.sys).
- Use:
  
  kv
  
  to view the stack; repeated presence of a third-party .sys in the stack is telling.
- If symbols load properly, you can use:
  
  ln
  
  to map addresses to modules and even source lines if available.

If the “Probably caused by” points to a Windows component (e.g., ntoskrnl.exe), that often indicates a third-party driver corrupted memory earlier. Use Driver Verifier below to flush out the real offender.

9) Use Driver Verifier to flush out bad drivers (advanced)

Driver Verifier stresses drivers and will intentionally provoke BSODs if a driver misbehaves. Use with caution.

Start (administrator Command Prompt):

verifier /reset
verifier /querysettings

(First command ensures it’s not already active.)
Run targeted verification for non-Microsoft drivers only:
- GUI method: Win+R > verifier
  - Create standard settings > Select driver names from a list > Check all non-Microsoft drivers.
- Or command-line (replace with specific drivers if known):
  
  verifier /standard /driver thirdparty.sys
  
  Better yet, select exact driver names identified from minidump or Device Manager.
Reboot and use the PC normally. If a BSOD occurs, note the driver named on the screen or in the new minidump.
To turn off Driver Verifier:

verifier /reset

If you can’t boot, enter Safe Mode and run the reset command there.

Caution:

Driver Verifier increases the chance of BSODs by design. Backup first, and don’t enable it on production machines without planning.

10) Repair or remove problematic drivers and filters

If a specific driver is implicated, update from the OEM or roll back to a known stable version.
Remove filter drivers that hook into the kernel:
- Command Prompt (admin):
  
  fltmc filters
  
  Review non-Microsoft filters (often security/encryption related). Temporarily uninstall associated software to test.
Review installed driver packages:

pnputil /enum-drivers

Identify duplicate or old OEM drivers (oemXX.inf). Remove carefully if they’re not needed:

pnputil /delete-driver oemXX.inf /uninstall /force

Be cautious—removing in-use drivers can make devices stop working until reinstalled.

11) In-place upgrade repair (keeps files and apps)

If corruption persists and dump analysis isn’t conclusive:

Download the latest Windows 10/11 ISO from Microsoft.
Mount the ISO > run setup.exe > choose Keep personal files and apps.
This refreshes the OS components without wiping data, often resolving stubborn kernel issues.

12) Clean installation (last resort)

Backup all data.
Create installation media (Media Creation Tool).
Boot from USB > delete only OS partitions > install fresh.
Reinstall drivers carefully, starting with chipset, graphics, storage, and network from the OEM.

Advanced Diagnostics

When the usual steps don’t pinpoint the root cause, these techniques can help.

Driver Verifier: recommended settings

Enable the following checks: Standard settings, plus for tougher cases: Special Pool, Pool Tracking, Force IRQL Checking, I/O Verification, Deadlock Detection, Security Checks, DMA Verification (on drivers that use DMA), and Enhanced I/O.
Only target non-Microsoft drivers to avoid false positives and unbootable scenarios.

Event Viewer and Reliability Monitor

Event Viewer: Windows Logs > System. Filter for Critical and Error.
- Look for “The computer has rebooted from a bugcheck” (Event ID 1001) to confirm parameters of 0xBE.
- Correlated device warnings (e.g., Disk, Ntfs, storahci, nvlddmkm) around the crash time can provide clues.
Reliability Monitor (search “Reliability History”): visual timeline of crashes with links to technical details and related failures.

Thermal and power validation

Monitor temperatures using HWiNFO or HWMonitor. Persistent thermal throttling or VRM issues can cause driver misbehavior.
Ensure your PSU is adequate and stable. Brownouts or marginal power rails can manifest as random driver or memory errors.

Firmware and platform drivers

Update ME/AMT (Intel Management Engine) or PSP/SMU (AMD Platform Security/Management) firmware if your OEM provides updates.
Update NVMe firmware (Samsung Magician, WD Dashboard, etc.) and controller drivers.

When to Seek Professional Help

Consider professional diagnostics or hardware replacement if:

MemTest86 reports errors even at JEDEC defaults.
You have repeated 0xBE BSODs after a clean installation with only OEM drivers.
SMART reports or vendor tools show pending disk failure.
You cannot boot even to Safe Mode, or Driver Verifier implicates multiple unrelated drivers (suggesting underlying hardware instability).
The device is under warranty—contact the OEM for repair or RMA.

Prevention Tips

Practice driver hygiene:
- Avoid generic driver “updaters.” Get drivers from your OEM or chipset/GPU vendor.
- Don’t update drivers without a reason; prefer known-stable versions.
Keep Windows, BIOS/UEFI, and firmware current—especially storage and chipset.
Make regular backups (File History, OneDrive, or full image backups).
Use quality hardware: matched RAM kits, reputable PSUs, adequate cooling.
Be conservative with overclocking. If you must, test for hours under mixed workloads.
Limit kernel-level software: only run one antivirus and one VPN at a time.

Conclusion

The ATTEMPTED_WRITE_TO_READONLY_MEMORY BSOD is almost always solvable with a methodical approach. Start simple: Safe Mode, clean boot, driver updates or rollbacks, disk and RAM checks. Then move to minidump analysis with BlueScreenView and WinDbg to identify the offending module. If needed, use Driver Verifier to flush out problematic drivers, and stabilize firmware and BIOS settings. For stubborn cases, an in-place repair or clean install resolves deep-seated corruption.

Most systems experiencing this STOP 0x000000BE error can be stabilized without hardware replacement. Follow the steps carefully, and you’ll likely get back to a reliable, crash-free Windows.

FAQ

Can I ignore the ATTEMPTED_WRITE_TO_READONLY_MEMORY BSOD?

No. This stop code indicates a kernel-level violation and can lead to data loss or corruption. While a one-off crash might be a fluke, repeated 0xBE events must be investigated—start with driver updates/rollbacks and minidump analysis.

Does this BSOD mean my RAM is failing?

Not necessarily. Many 0xBE crashes are caused by drivers. However, faulty or unstable RAM can cause similar symptoms. Run Windows Memory Diagnostic and, ideally, MemTest86. Test with XMP/EXPO disabled and with one stick at a time.

How do I find the offending driver or module?

Enable Small memory dumps (C:\Windows\Minidump), then use BlueScreenView for a quick look or WinDbg for deep analysis:

Open the dump, set symbols, run !analyze -v, and check the “Probably caused by” line and call stack.
If it points to a Windows component, use Driver Verifier to stress-test non-Microsoft drivers until the real culprit appears.

Is it safe to use Driver Verifier?

Yes, if used carefully. It’s designed to expose bad drivers and will likely provoke BSODs during testing. Target only non-Microsoft drivers, back up data first, and disable it afterward with verifier /reset. If you get stuck in a boot loop, enter Safe Mode and run the reset command.

What if I can’t boot into Windows at all?

Use WinRE (automatic after repeated failed boots) to:

Enter Safe Mode.
Run System Restore.
Open Command Prompt for SFC/DISM/CHKDSK.
If these fail, consider an in-place upgrade repair via bootable media or, as a last resort, a clean installation after backing up data.

Handy Command Reference

System image and file repair:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
Disk check:

chkdsk C: /f /r
Driver Verifier:

verifier /reset
verifier /querysettings
verifier /standard /driver <driver.sys>
List and remove driver packages:

pnputil /enum-drivers
pnputil /delete-driver oemXX.inf /uninstall /force
Filter drivers:

fltmc filters

Stay patient and systematic, and you’ll pinpoint the issue. You’ve got this.