How to Fix 0x0000011C ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE Blue Screen Error in Windows

Quick Answer

ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE (Bug Check 0x0000011C) is a Windows Blue Screen of Death (BSOD) error that occurs when an attempt is made to write to the read-only protected storage of the Windows Configuration Manager.

The Configuration Manager is a Windows kernel component responsible for managing configuration information, including the Windows Registry. This bug check indicates that a protected memory area was accessed through an attempted write operation that Windows does not permit.

Microsoft documents this error as a bug check with four parameters. When possible, Windows also identifies the driver attempting the write operation and records its name in the KiBugCheckDriver variable.

Because this error involves kernel-level memory protection, a faulty or incompatible driver is an important area to investigate. However, the error code alone does not establish which driver or component caused the failure.

Recommended troubleshooting includes examining the crash dump, identifying the responsible driver, reviewing recent driver or software changes, installing appropriate updates and testing the system after each change.

What Is ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE (0x0000011C)?

ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE is a Windows kernel bug check with the hexadecimal value 0x0000011C.

It indicates that an attempt was made to modify a protected, read-only storage area maintained by the Configuration Manager (CM).

The Configuration Manager is a Windows kernel component that manages configuration information used by the operating system. One of its major responsibilities is managing Registry-related configuration data.

Windows uses memory protection mechanisms to prevent unauthorized modifications to protected kernel memory. When an operation attempts to write to the protected storage associated with the Configuration Manager, Windows can stop the system to prevent further corruption.

This is a kernel-level error rather than an ordinary application error. Consequently, troubleshooting should focus on system drivers, kernel-level components and crash-dump analysis rather than simply reinstalling the application that was running when the crash occurred.

Understanding the 0x0000011C Bug Check Parameters

Microsoft documents four parameters associated with this bug check. These values provide technical information about the attempted write operation.

Parameter	Description
Parameter 1	Virtual address for the attempted write.
Parameter 2	Page Table Entry (PTE) contents.
Parameter 3	Reserved.
Parameter 4	Reserved.

What Do These Parameters Mean?

Parameter 1 – Virtual Address: Identifies the virtual memory address associated with the attempted write operation. Kernel debugging tools can use this information to investigate the memory location involved.

Parameter 2 – PTE Contents: Contains information from the Page Table Entry associated with the memory operation. A PTE is a memory-management structure used by Windows and the processor to manage virtual-to-physical memory translation and memory access permissions.

Parameters 3 and 4: These are reserved for this bug check and should not be interpreted as additional diagnostic values.

KiBugCheckDriver Information

One particularly useful diagnostic detail is the KiBugCheckDriver variable.

According to Microsoft, when it is possible to identify the driver attempting the write operation, its name is displayed as a Unicode string on the bug check screen and saved in KiBugCheckDriver.

This information can help technicians identify the driver associated with the crash. However, its availability is not guaranteed, and its absence does not mean that a driver was not responsible.

Symptoms of the 0x0000011C Blue Screen Error

A Windows system experiencing this bug check may exhibit one or more of the following symptoms:

• A Blue Screen of Death displaying ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE.
• The stop code 0x0000011C displayed on the blue screen.
• Unexpected system restarts.
• Repeated crashes during Windows startup or normal operation.
• Crashes occurring after installing or updating a device driver.
• System instability when a particular hardware device or kernel-level software component is being used.
• Crash dump files being generated after the system encounters the error.

These symptoms are not exclusive to this bug check. The exact crash code and diagnostic information should be examined before determining the underlying problem.

Possible Causes of ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE

Microsoft's official documentation defines what the bug check means but does not provide a definitive list of every underlying cause. The following are reasonable areas to investigate during diagnosis, not confirmed causes for every occurrence.

1. Faulty or Incompatible Device Drivers

A kernel-mode device driver operates with elevated privileges and can interact with protected operating system memory.

A driver containing a programming defect, using an invalid memory operation or behaving incorrectly after a Windows update may be involved in a protected-memory access violation.

Pay particular attention to recently installed or updated drivers, especially when the crash started immediately after a driver change.

2. Third-Party Kernel-Level Software

Some applications install kernel-mode components to provide additional functionality. Examples include:

• Third-party antivirus and endpoint security software.
• Disk encryption and storage management utilities.
• Backup and snapshot software.
• Virtualization and device-emulation software.
• System monitoring and hardware management utilities.
• Low-level device management and filtering software.

If such software installs a faulty kernel component, it may contribute to system instability. Investigate recently installed or updated components rather than assuming that every product in these categories is responsible.

3. Windows Update or Driver Compatibility Problems

A Windows update can change operating system components and interfaces used by device drivers.

Although supported drivers are expected to work with the operating system, compatibility problems or existing driver defects may become apparent after an update.

If the error first appeared following a Windows update, review the update history and compare the crash timeline with recent system changes.

4. Corrupted or Inconsistent System Components

Damaged or inconsistent Windows system files may contribute to broader operating system instability.

System File Checker and Deployment Image Servicing and Management (DISM) are built-in Windows utilities that can check and repair supported Windows image and system-file problems.

However, a system-file integrity problem should not automatically be considered the cause of this specific bug check.

5. Memory or Hardware Instability

Unstable hardware, memory errors, aggressive overclocking or firmware-related problems can contribute to unexpected system behaviour.

These possibilities should be investigated when crashes occur repeatedly, affect different system components or are accompanied by other hardware-related errors.

The 0x11C bug check does not independently confirm a defective RAM module or other hardware component.

How to Troubleshoot the 0x0000011C Error

Follow the troubleshooting procedures below in order. Begin with evidence collection and less disruptive checks before changing drivers, software or system configuration.

Step 1: Record the Blue Screen Error Details

Before making any changes, record the information displayed on the blue screen.

Look for the following details:

• Stop code: ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE.
• Bug check value: 0x0000011C.
• Any driver filename displayed on the screen.
• When the crash occurs, such as during startup, shutdown or normal operation.
• Recent Windows updates, driver installations or software changes.

If the system restarts too quickly to capture the information, examine the crash dump files after Windows starts again.

Step 2: Locate Windows Crash Dump Files

Windows can generate memory dump files when a system crash occurs. These files contain diagnostic information that can help technicians investigate the bug check.

Check the following locations:

• C:\Windows\Minidump\ – Contains small memory dump files when configured and successfully generated.
• C:\Windows\MEMORY.DMP – Common default location for a kernel or complete memory dump.

The actual location and availability depend on the configured dump type, Windows settings and whether the crash dump was successfully written.

Configure Memory Dump Settings

1. Press Windows + R.
2. Type sysdm.cpl and press Enter.
3. Open the Advanced tab.
4. Under Startup and Recovery, select Settings.
5. Locate the Write debugging information section.
6. Select an appropriate dump type, such as Automatic memory dump or Small memory dump (256 KB).
7. For a small memory dump, verify that the destination is configured as %SystemRoot%\Minidump.
8. Click OK to save the settings.

Ensure that the system drive has sufficient free space and that the page-file configuration supports the selected dump type.

Important: Memory dumps may contain sensitive information from system memory. Restrict access to these files and avoid uploading them to public websites without checking their contents and privacy implications.

Step 3: Analyse the Crash Dump Using WinDbg

Windows Debugger (WinDbg) is a Microsoft debugging tool that can analyse crash dump files and help identify the components involved in a system crash.

It is particularly useful for investigating kernel-level bug checks such as 0x0000011C.

Install WinDbg

1. Open the Microsoft Store or the official Microsoft WinDbg documentation.
2. Install the supported WinDbg application.
3. Launch WinDbg with the necessary permissions to access the dump file.
4. Select File > Open dump file.
5. Browse to the relevant file in C:\Windows\Minidump or open C:\Windows\MEMORY.DMP.
6. Wait for the debugger to load the dump and initialise symbols.

Official documentation: Microsoft Windows Debugging Documentation.

Run Basic Analysis Commands

After opening the dump file, enter the following commands in the WinDbg command window.

1. Run automatic bug check analysis:

!analyze -v

This command generates a detailed analysis of the crash, including the bug check code, parameters and available driver or module information.

2. Check the bug check driver information:

dx KiBugCheckDriver

This command attempts to display the driver information recorded in the KiBugCheckDriver variable, when available in the dump and debugger context.

3. Examine a suspected driver module:

lmvm drivername

Replace drivername with the actual module name identified during analysis, without the file extension.

This command displays available information about the loaded module, including its image name, version and symbol details where available.

Important: A module appearing in the crash stack does not automatically establish that it caused the crash. Analyse the complete call stack, memory context and other dump information before identifying a responsible driver.

Step 4: Update or Roll Back the Suspected Driver

If crash analysis identifies a potentially involved driver, investigate its version and compatibility before changing it.

1. Right-click the Start button.
2. Select Device Manager.
3. Locate the relevant hardware category.
4. Expand the category and identify the associated device.
5. Right-click the device and select Properties.
6. Open the Driver tab.
7. Review the driver provider, date and version.

If an updated driver is available, obtain it from the computer manufacturer, hardware manufacturer or another appropriate official distribution channel.

If the problem began immediately after a driver update, check whether the Roll Back Driver option is available. Use it when the previous driver is known to be compatible and the timing supports the suspected connection.

Restart the computer after making the change and monitor whether the crash returns.

Note: Avoid installing random driver packages from unofficial download websites. Incorrect or modified drivers can introduce additional stability and security problems.

Step 5: Review Recently Installed Software

If the error started after installing a new application or updating an existing one, investigate whether the software installs kernel-level drivers or system services.

1. Press Windows + I to open Settings.
2. Navigate to Apps > Installed apps in supported Windows versions.
3. Review recently installed applications.
4. Check the software manufacturer's documentation for known compatibility issues.
5. If a specific application is strongly associated with the crash, use its official uninstallation or repair procedure.
6. Restart Windows and observe the system behaviour.

For security software, encryption tools and business-critical applications, consult the vendor's instructions before removing components. Uninstalling such software without following the correct procedure can affect protection, encryption or system functionality.

Step 6: Install Available Windows Updates

Windows updates can include security improvements, operating system fixes and compatibility updates.

1. Open Windows Settings.
2. Navigate to Windows Update.
3. Select Check for updates.
4. Review the available updates.
5. Install applicable updates from Microsoft.
6. Restart the computer if required.

Also review optional driver updates carefully. Prefer a driver directly supplied by the hardware manufacturer when the device manufacturer recommends it for the particular system.

Do not install every optional driver update indiscriminately, particularly on business-critical computers.

Step 7: Check and Repair Windows System Files

If there are additional indications of Windows system-file corruption, run the built-in DISM and System File Checker utilities.

These commands require an elevated Command Prompt or Windows Terminal.

Run DISM

DISM /Online /Cleanup-Image /RestoreHealth

DISM checks and repairs the currently running Windows image using available repair sources. An internet connection or an appropriate local repair source may be required.

Wait until the operation finishes before proceeding.

Run System File Checker

sfc /scannow

System File Checker scans protected Windows system files and attempts to repair integrity problems using available repair resources.

Restart Windows after the scans complete if required.

These utilities address Windows image and protected system-file integrity problems. They do not directly repair a defective third-party driver or guarantee a solution to bug check 0x11C.

Official documentation: Microsoft Support – Using System File Checker in Windows.

Step 8: Check for Memory and Hardware Problems

If the crash continues after reviewing drivers and software, investigate possible hardware instability.

Run Windows Memory Diagnostic

1. Press Windows + R.
2. Type mdsched.exe.
3. Press Enter.
4. Select Restart now and check for problems after saving your work.
5. Allow the diagnostic test to complete.
6. Review the test results after Windows restarts.

A detected memory error warrants further hardware investigation. A clean test does not completely rule out intermittent memory problems.

Check BIOS and Firmware Configuration

Review whether the system has recently undergone changes to BIOS/UEFI settings, memory profiles or CPU/GPU overclocking.

• Temporarily return unsupported or unstable overclocking settings to manufacturer-recommended defaults.
• Check the computer manufacturer's documentation for applicable BIOS or firmware updates.
• Do not interrupt a firmware update once it has started.
• Record existing configuration settings before making changes.

BIOS or firmware updates should only be performed when appropriate for the specific computer model and when there is a relevant reason to do so.

Step 9: Use Safe Mode if Windows Cannot Start Normally

If the computer repeatedly crashes during startup, Windows Recovery Environment (WinRE) may provide access to troubleshooting options.

1. Enter Windows Recovery Environment using the available recovery startup method.
2. Select Troubleshoot > Advanced options > Startup Settings.
3. Select Restart.
4. After the restart, choose the appropriate Safe Mode option.
5. Once Windows starts, investigate recently installed drivers, software and updates.

If Windows does not automatically display recovery options, compatible Windows installation media can be used to access the recovery environment.

Safe Mode loads a limited set of drivers and services. If the system is stable in Safe Mode but crashes during normal startup, this can provide a useful diagnostic clue, although it does not independently identify the responsible component.

Warning: Before uninstalling drivers, removing updates or using recovery options, consider backing up important data whenever possible.

Advanced Troubleshooting for IT Technicians

For persistent occurrences of 0x0000011C, technicians should perform a more detailed kernel-level investigation instead of repeatedly applying general Windows repair procedures.

1. Compare Multiple Crash Dumps

If the system has generated several crash dumps, analyse them together.

Look for recurring patterns, including:

• The same driver appearing in multiple crash stacks.
• Repeated references to the same kernel module.
• Similar memory addresses or fault contexts.
• A consistent relationship between crashes and a specific device or operation.
• Changes in crash behaviour following driver or software updates.

Repeated involvement of a particular component can strengthen a hypothesis, but should still be evaluated against the complete debugging evidence.

2. Investigate the Driver Call Stack

In WinDbg, examine the available stack trace using:

k

The command displays the current thread's stack trace. Depending on the dump type and available symbols, technicians may obtain additional information about the sequence of kernel functions involved in the crash.

Use the bug check parameters, module information and call stack together to understand how the attempted write operation occurred.

3. Verify Microsoft Symbol Configuration

Correct symbols help WinDbg interpret kernel and module information.

A commonly used Microsoft public symbol path is:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

Configure the symbol path in WinDbg and reload symbols when necessary.

For example:

.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols
.reload

The symbol cache directory must be writable, and network access may be required to download symbols.

4. Consider Driver Verifier Only When Necessary

Driver Verifier is a Windows diagnostic utility designed to detect certain illegal or unsafe driver behaviours.

It can be useful when investigating suspected driver defects, but it deliberately applies additional checks and can cause system crashes when a driver violates those checks.

It should not be enabled casually on a production computer or a system that cannot easily be recovered.

Before using Driver Verifier:

• Ensure that important data is backed up.
• Understand how to access Windows Recovery Environment.
• Confirm that the system can be recovered if Windows fails to start.
• Identify the specific third-party drivers that need investigation.
• Read the official documentation and understand the verification options.

Microsoft documentation: Driver Verifier – Windows Drivers.

For most users, crash-dump analysis and controlled driver troubleshooting should be performed before considering Driver Verifier.

What to Do If the 0x0000011C Error Continues

If the error continues after the recommended checks, avoid repeating the same repair operations without obtaining additional diagnostic evidence.

Consider the following approach:

1. Preserve the latest crash dump files.
2. Record the exact bug check code and all four parameters.
3. Identify whether KiBugCheckDriver contains a driver name.
4. Compare the crash stacks from multiple occurrences.
5. Review recent Windows, driver, firmware and kernel-level software changes.
6. Test suspected components individually using supported recovery procedures.
7. Escalate the case to the computer manufacturer or relevant software vendor if the cause remains unclear.

For enterprise systems, preserve the original dump files and relevant system logs before making significant changes. This helps maintain useful diagnostic evidence and reduces unnecessary downtime.

How to Prevent ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE Errors

Although not every kernel-level failure can be prevented, the following practices can reduce the likelihood of driver and system stability problems.

• Install drivers from official hardware manufacturer sources.
• Use drivers compatible with the installed Windows version and hardware.
• Keep Windows updated with applicable security and reliability updates.
• Maintain compatible versions of third-party kernel-level software.
• Avoid unnecessary system-tweaking and kernel-modification utilities.
• Use supported BIOS and firmware configurations.
• Avoid unsupported overclocking configurations.
• Maintain regular backups of important files and business data.
• Preserve crash dumps when investigating recurring blue screen errors.
• Test significant driver and software changes before deploying them across business-critical systems.

Frequently Asked Questions (FAQs)

1. What does ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE mean?

It means Windows detected an attempt to write to read-only protected storage maintained by the Configuration Manager. Windows generates bug check 0x0000011C when this condition occurs.

2. Is error 0x0000011C a Blue Screen of Death error?

Yes. It is a Windows kernel bug check that can cause a Blue Screen of Death and an automatic system restart.

3. Does the 0x0000011C error always indicate a faulty driver?

No. A driver attempting an invalid write is an important area of investigation, but the error code alone does not establish the underlying cause. Crash-dump analysis is needed to investigate the component involved.

4. How can I identify the driver responsible for error 0x11C?

Examine the Windows crash dump using WinDbg. Run !analyze -v and, when available, inspect KiBugCheckDriver. Review the crash stack and module information before identifying a suspected driver.

5. Can Windows system-file corruption cause this error?

System-file corruption may contribute to operating system instability, but Microsoft does not identify it as a definitive cause of this specific bug check. DISM and System File Checker can be used when there is evidence of Windows image or system-file integrity problems.

6. Can RAM problems cause the 0x0000011C blue screen?

Memory instability or hardware problems are reasonable diagnostic possibilities, especially when the system experiences multiple types of crashes. However, this bug check does not directly confirm defective RAM.

7. Is it safe to delete the Windows Registry to fix this error?

No. Deleting Registry keys or modifying protected Configuration Manager storage without a verified diagnosis is not a recommended troubleshooting method. Such changes can damage Windows configuration and make the system unbootable.

8. What is the difference between 0x0000011C and a normal application crash?

A normal application crash generally affects an individual application or process. Bug check 0x0000011C is a kernel-level failure that causes Windows to stop the system to protect operating system integrity.

9. Where can I find the Windows dump file for error 0x11C?

Small memory dumps are commonly stored in C:\Windows\Minidump. Larger kernel or complete memory dumps are commonly stored in C:\Windows\MEMORY.DMP. The actual location depends on the configured dump settings.

10. Should I reinstall Windows to fix ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE?

Reinstalling Windows should not be the first troubleshooting step. Identify the suspected driver or component through crash-dump analysis and investigate less disruptive solutions first. A clean installation may be considered only when other appropriate diagnostic and recovery options have been exhausted and the evidence supports it.

Conclusion

ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE (0x0000011C) is a Windows kernel bug check indicating an attempted write to protected, read-only Configuration Manager storage.

The most useful starting point is to preserve and analyse the crash dump, inspect the available KiBugCheckDriver information and investigate the driver or kernel-level component involved.

Driver updates, software compatibility checks, Windows system-file verification and hardware diagnostics can help narrow down the problem. However, these procedures should be selected according to the available evidence rather than treated as guaranteed fixes.

For recurring crashes, especially on business-critical computers, a proper kernel dump analysis is preferable to repeatedly reinstalling drivers or making unverified Registry changes.

Official References

1. Microsoft Learn – Bug Check 0x11C: ATTEMPTED_WRITE_TO_CM_PROTECTED_STORAGE
2. Microsoft Learn – Windows Debugging Documentation
3. Microsoft Learn – Driver Verifier
4. Microsoft Learn – Crash Dump Files
5. Microsoft Support – Using System File Checker in Windows