0x000000EB DIRTY_MAPPED_PAGES_CONGESTION Blue Screen Error – Causes and Troubleshooting

Quick Answer

DIRTY_MAPPED_PAGES_CONGESTION (Bug Check 0x000000EB) is a Windows Blue Screen of Death (BSOD) error that occurs when Windows runs out of free memory pages because modified memory pages cannot be written successfully to their intended storage locations.

According to Microsoft, this error typically indicates that the file system driver stack has become deadlocked or that a storage driver is not processing write requests. As a result, Windows cannot safely reuse modified memory pages without risking data loss, so it stops the system.

Possible causes include:

• Faulty or malfunctioning file system drivers.
• Third-party file system filter drivers interfering with write operations.
• Storage controller or disk drivers that are not processing I/O requests.
• Deadlocks involving modified page writers.
• Unresponsive storage devices or stranded storage request queues.
• Driver conflicts involving backup, antivirus, encryption or storage management software.

The most effective troubleshooting approach is to investigate storage and file system drivers, review recent software or driver changes, and analyse the Windows crash dump using WinDbg. Simply adding RAM or changing virtual memory settings is not a confirmed solution for this bug check.

What Is DIRTY_MAPPED_PAGES_CONGESTION (0x000000EB)?

DIRTY_MAPPED_PAGES_CONGESTION is a Windows kernel bug check with the hexadecimal stop code 0x000000EB.

To understand this error, it is important to understand how Windows manages memory and writes modified data to storage.

Understanding Modified and Mapped Pages

Windows divides physical memory into small units called pages. These pages are used to manage application data, system processes, cached files and other operating system resources.

When Windows modifies data held in memory, the affected pages may become dirty pages. These pages contain changes that must be written to their appropriate backing storage before Windows can safely reuse the memory.

The modified page writer is responsible for writing modified pages to their intended storage locations. These may include files, mapped files or the paging file, depending on the type of memory allocation.

Under normal circumstances, Windows continuously manages this process to maintain sufficient available memory.

Why Does Windows Crash?

If the file system or storage driver stack stops processing the required write operations, modified pages can accumulate in memory.

When the system cannot make these pages available for reuse without potentially losing data, Windows triggers Bug Check 0xEB to prevent further unsafe operation.

Microsoft specifically identifies file system driver deadlocks and storage drivers that fail to process requests as documented causes of this condition.

Symptoms of the 0x000000EB Blue Screen Error

A computer experiencing DIRTY_MAPPED_PAGES_CONGESTION may display one or more of the following symptoms:

• Windows suddenly displays a Blue Screen of Death.
• The system restarts automatically after the crash.
• The stop code DIRTY_MAPPED_PAGES_CONGESTION appears on the blue screen.
• The computer crashes repeatedly during file operations or storage-intensive activities.
• Windows becomes unresponsive before restarting.
• The problem appears after installing or updating a storage-related driver or software component.
• Crash dump files are generated in the Windows directory, if dump collection is configured and successful.

The circumstances surrounding the crash can provide useful diagnostic information, but they do not independently identify the faulty driver or hardware component.

Common Causes of DIRTY_MAPPED_PAGES_CONGESTION

1. File System Driver Deadlock

This is one of the primary causes documented by Microsoft.

A file system driver manages communication between Windows and the file systems used to store and retrieve data. If a driver becomes deadlocked, the modified page writer may be unable to complete pending write operations.

Examples include:

• Incorrect synchronization involving mutexes or other driver locks.
• A driver accessing memory that has been paged out when the operation cannot safely proceed.
• Deadlocks within file system drivers or filter drivers.

Such problems generally indicate a driver implementation defect and require investigation of the kernel driver stack.

2. Faulty Third-Party File System Filter Drivers

File system filter drivers operate between applications or system components and the underlying file system. They can monitor, intercept or modify file operations.

Common examples of software that may install file system filter drivers include:

• Third-party antivirus and endpoint security software.
• Backup and recovery applications.
• File encryption software.
• Disk monitoring and storage management utilities.
• File synchronization and data protection applications.
• Virtual disk and snapshot management software.

A malfunctioning filter driver can interfere with file system operations and potentially prevent modified pages from being written successfully.

Important: The presence of a third-party filter driver does not automatically mean it is responsible for the crash. Its involvement must be established through crash dump analysis or controlled troubleshooting.

3. Storage Driver Failure

Windows relies on storage drivers to communicate with SSDs, HDDs, RAID controllers and other storage devices.

If a storage driver stops processing requests, pending write operations may remain incomplete. Microsoft identifies unresponsive storage request queues and storage driver failures as possible causes of this bug check.

Potentially relevant components include:

• SATA/AHCI controller drivers.
• NVMe storage drivers.
• RAID controller drivers.
• Storage controller firmware.
• Manufacturer-specific disk drivers.

4. Unresponsive Storage Device

A storage device that stops responding or repeatedly encounters I/O errors can contribute to storage request processing failures.

Possible underlying issues include:

• SSD or HDD hardware faults.
• Intermittent storage connectivity.
• Faulty SATA or power cables.
• Storage controller problems.
• Firmware-related compatibility issues.

These are investigation areas rather than confirmed causes in every 0xEB crash. Hardware diagnostics and storage event logs should be used to establish whether the device is actually malfunctioning.

5. Insufficient Nonpaged Pool Resources (Legacy Windows Systems)

Microsoft documents an additional cause specifically applicable to Windows Server 2003.

On that operating system, insufficient nonpaged pool memory may prevent the storage stack from writing modified pages.

For Windows Vista and later versions, Bug Check Parameter 3 is reserved. Therefore, the legacy Windows Server 2003 nonpaged pool explanation should not be applied directly to modern Windows systems.

Understanding 0x000000EB Bug Check Parameters

Windows records four parameters when this bug check occurs. These values can help advanced users investigate the memory and storage conditions present at the time of the crash.

Parameter	Description
Parameter 1	Total number of dirty pages.
Parameter 2	Number of dirty pages destined for the page file.
Parameter 3	Windows Server 2003: Available nonpaged pool size in pages. Windows Vista and later: Reserved.
Parameter 4	Windows Server 2003: Number of stranded transition pages. Windows Vista and later: Most recent modified write error status.

These parameters should be interpreted in the context of the operating system version and the complete crash dump. They should not be used independently to identify a faulty hardware component.

How to Fix DIRTY_MAPPED_PAGES_CONGESTION BSOD Error

Because this error is associated with memory page write operations and the file system or storage driver stack, troubleshooting should focus on identifying the component preventing write operations from completing.

Follow the procedures below, starting with basic checks before moving to advanced diagnostics.

1. Disconnect Recently Added Hardware

If the blue screen started after connecting a new storage device, controller, external drive or other hardware component, disconnect the recently added device and check whether Windows becomes stable.

1. Shut down the computer properly.
2. Disconnect recently added non-essential external devices.
3. Restart Windows.
4. Observe whether the blue screen occurs again.

If the problem disappears, investigate the disconnected device, its driver and its compatibility with the installed Windows version.

Do not disconnect internal storage devices while Windows is running.

2. Check Recently Installed or Updated Drivers

Driver changes immediately preceding the first crash are important diagnostic clues.

1. Right-click the Start button.
2. Select Device Manager.
3. Expand the relevant device categories, particularly Storage controllers, IDE ATA/ATAPI controllers where available, and other storage-related categories.
4. Identify recently installed or updated drivers.
5. Check the driver provider, version and installation date under the device properties.
6. Obtain compatible driver updates from the computer, motherboard or storage controller manufacturer.

If the problem began immediately after a driver update, use the Roll Back Driver option when available, or reinstall the previous known-working driver obtained from the manufacturer.

Avoid installing generic driver packages from unverified third-party websites.

3. Investigate Third-Party File System Filter Drivers

Third-party filter drivers are particularly important when investigating this bug check.

To identify installed file system filter drivers, open Command Prompt or Windows Terminal as Administrator and execute:

fltmc filters

This command displays registered file system minifilter drivers, including their names, altitudes and frame information.

Review the output for filters associated with recently installed antivirus, backup, encryption or storage management applications.

For additional investigation, execute:

fltmc instances

This displays filter instances attached to volumes.

If a particular filter driver is suspected:

1. Identify the software product that installed the driver.
2. Check for a compatible update from its manufacturer.
3. Review the manufacturer's troubleshooting instructions.
4. If necessary, temporarily disable or uninstall the associated application using its supported procedure.
5. Restart Windows and monitor system stability.

Warning: Do not manually delete filter driver files or remove their registry entries. Doing so can cause file system failures or prevent Windows from starting.

4. Check Storage Device Health

Investigate whether the storage device or controller is reporting errors.

Start by checking the Windows System event log:

1. Press Win + R.
2. Type eventvwr.msc and press Enter.
3. Expand Windows Logs.
4. Select System.
5. Review events around the time of the blue screen.
6. Look for storage-related warnings and errors, including events from Disk, Ntfs, StorPort or the relevant storage controller driver.

Where available, use the SSD or HDD manufacturer's diagnostic utility to check device health and perform appropriate hardware tests.

Also inspect internal storage connections, SATA cables and power connections where applicable. These checks should be performed with the computer powered off.

If the drive reports critical health warnings, repeated I/O errors or signs of failure, prioritize backing up important data before performing additional testing.

5. Check and Repair File System Errors

File system errors can complicate storage troubleshooting. Windows includes the CHKDSK utility for checking file system integrity.

Open Command Prompt as Administrator and execute:

chkdsk C: /scan

This performs an online scan of the C: volume for file system errors.

If errors requiring offline repair are reported, first ensure that important data is backed up. Then use the repair procedure appropriate to the reported condition.

chkdsk C: /f

The /f parameter instructs CHKDSK to fix detected file system errors. If the volume is in use, Windows may ask to schedule the operation for the next restart.

Important: CHKDSK is a file system checking and repair utility. It does not repair faulty storage drivers, firmware defects or failing hardware. Do not assume that a successful scan resolves the underlying cause of Bug Check 0xEB.

6. Install Windows Updates

Windows updates can contain operating system fixes, driver compatibility improvements and reliability updates.

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

For storage controllers and manufacturer-specific devices, also check the computer or motherboard manufacturer's support website for compatible driver and firmware updates.

Do not apply firmware updates without confirming the exact device model, compatibility and manufacturer's update procedure.

7. Verify Paging File Configuration

Windows uses the paging file as part of its virtual memory management system. A correctly configured paging file is also important for collecting certain types of crash dump files.

Check the current virtual memory configuration:

1. Press Win + R.
2. Enter sysdm.cpl.
3. Open the Advanced tab.
4. Under Performance, select Settings.
5. Open the Advanced tab.
6. Under Virtual memory, select Change.

Review the paging file configuration.

For most users, allowing Windows to manage the paging file automatically is a suitable starting configuration.

Do not disable the paging file or assign arbitrary fixed sizes as a supposed universal fix for this stop code. The Microsoft documentation identifies file system and storage driver failures as the primary areas of investigation for this bug check.

8. Use Safe Mode to Isolate Software and Driver Problems

If Windows crashes repeatedly during normal startup, Safe Mode can help determine whether a recently installed driver or third-party application is contributing to the problem.

To enter Safe Mode:

1. Open Settings.
2. Navigate to System > Recovery in supported Windows 11 versions.
3. Under Advanced startup, select Restart now.
4. After restarting, select Troubleshoot > Advanced options > Startup Settings.
5. Select Restart.
6. Press 4 or F4 to start Safe Mode.

If Windows is unable to start normally, Windows Recovery Environment can also be accessed through the available recovery or installation media options.

Once in Safe Mode, investigate recently installed storage-related applications and drivers. Use supported uninstall or rollback procedures rather than manually deleting system drivers.

Advanced Troubleshooting Using WinDbg

If the error continues after basic troubleshooting, analysing the crash dump is one of the most useful ways to identify the underlying driver or storage stack problem.

WinDbg is Microsoft's debugging tool for examining Windows crash dump files.

1. Locate the Crash Dump File

Windows may generate crash dump files depending on the system failure configuration.

Common locations include:

• C:\Windows\Minidump\ – Small memory dump files.
• C:\Windows\MEMORY.DMP – Kernel, automatic or other configured memory dump files.

If no dump file exists, check the Startup and Recovery settings and the available disk space. A crash dump may not be generated if the system cannot complete the dump-writing process.

2. Configure Automatic Memory Dump

To configure Windows to collect debugging information:

1. Open the Windows search box.
2. Search for Advanced system settings.
3. Open the Advanced tab in System Properties.
4. Under Startup and Recovery, select Settings.
5. Under Write debugging information, select Automatic memory dump.
6. Ensure the appropriate dump file location and paging file configuration are available.
7. Click OK and restart Windows.

Automatic memory dumps contain kernel-level debugging information and use a system-managed paging file configuration to support dump collection.

3. Analyse the Dump Using WinDbg

Install WinDbg using Microsoft's official documentation and open the relevant crash dump file.

Begin the investigation with:

!analyze -v

This command performs an automatic analysis of the crash dump and displays information about the bug check, parameters and available diagnostic clues.

Next, execute:

.bugcheck

This displays the bug check code and its four parameters.

4. Examine Memory Statistics

Microsoft specifically recommends using the !vm 3 debugger extension to examine general memory statistics when investigating DIRTY_MAPPED_PAGES_CONGESTION.

!vm 3

This command provides detailed virtual memory information that can help investigators examine the condition of memory pages and related memory management statistics.

Pay particular attention to the number of dirty pages and the broader memory state. Large Parameter 1 or Parameter 2 values may support investigating a driver deadlock involving modified or mapped page writers.

5. Investigate Storage Request Processing

Microsoft also recommends examining process information when investigating storage drivers that may not be processing requests.

!process 0 7

This command displays detailed process and thread information, which may help identify threads associated with blocked operations.

Correlate the results with the crash stack, driver modules and storage-related threads.

6. Examine Loaded Drivers and Their Modules

Use the following command to list loaded kernel modules:

lm

Review the loaded drivers and compare them with the modules identified in the crash analysis.

Pay particular attention to third-party file system filters, storage controller drivers and recently updated kernel-mode drivers.

Important: The driver appearing in a crash stack is not automatically the defective driver. A driver may simply be waiting for another component that has stopped responding. A reliable diagnosis requires examining the complete call stack, thread state and associated driver activity.

When Should You Suspect Hardware Failure?

Although Microsoft identifies driver-related deadlocks and storage request processing failures as documented causes, physical hardware problems should also be investigated when the available evidence indicates storage instability.

Consider further hardware testing when:

• Windows reports repeated disk or storage controller errors.
• The SSD or HDD diagnostic utility reports health problems.
• Storage devices intermittently disappear from BIOS or Windows.
• The computer experiences repeated I/O errors.
• Storage-related problems occur alongside other unexpected system crashes.

Depending on the findings, investigate the storage device, controller, cabling, power delivery and motherboard connections.

Do not replace RAM, the motherboard or the storage device solely because this bug check has occurred. Replacement should be based on diagnostic evidence.

How to Prevent DIRTY_MAPPED_PAGES_CONGESTION Errors

Although not every driver defect or hardware problem can be prevented, the following practices can help reduce the likelihood of related system failures:

• Keep Windows updated with applicable security and reliability updates.
• Install storage and chipset drivers from trusted manufacturer sources.
• Keep antivirus, backup and encryption software updated.
• Remove obsolete or incompatible low-level system utilities.
• Monitor storage device health using manufacturer-supported diagnostic tools.
• Investigate recurring disk and storage controller errors.
• Maintain regular backups of important business and personal data.
• Preserve crash dump files when investigating recurring BSOD errors.
• Avoid unnecessary modifications to Windows paging file and storage configurations.

Frequently Asked Questions (FAQs)

1. What does DIRTY_MAPPED_PAGES_CONGESTION mean?

It means Windows has insufficient free memory pages to continue safely because modified pages cannot be written successfully to their intended storage locations. It is identified by Bug Check 0x000000EB.

2. Is DIRTY_MAPPED_PAGES_CONGESTION caused by faulty RAM?

Not necessarily. Microsoft's documented causes primarily involve file system driver deadlocks and storage drivers that fail to process requests. A memory hardware problem should be investigated separately if other diagnostic evidence suggests it.

3. Can an SSD or HDD cause error 0x000000EB?

Storage-related failures can contribute to this error, particularly when storage requests remain unprocessed or a device stops responding. However, the actual cause may also be a storage driver or file system filter driver rather than the physical drive itself.

4. Can antivirus software cause DIRTY_MAPPED_PAGES_CONGESTION?

Antivirus software may install file system filter drivers that participate in file operations. A defective or incompatible filter driver can potentially interfere with the file system driver stack. Its involvement must be confirmed through investigation rather than assumed.

5. Does increasing virtual memory fix error 0xEB?

There is no universal evidence that increasing the paging file fixes this bug check. The documented causes involve blocked modified-page writing and storage request processing. Review paging file configuration primarily to ensure that Windows can manage virtual memory and collect crash dumps correctly.

6. What is the difference between 0xEB and 0xFD?

Both are Windows bug checks associated with modified memory pages, but they have different names and diagnostic meanings. 0xEB is DIRTY_MAPPED_PAGES_CONGESTION, whereas 0xFD is DIRTY_NOWRITE_PAGES_CONGESTION. They should not be treated as interchangeable errors.

7. Where can I find the dump file for this BSOD?

Check C:\Windows\Minidump\ for small memory dumps and C:\Windows\MEMORY.DMP for larger configured crash dumps. Their availability depends on the Windows crash dump settings and whether dump collection completed successfully.

8. Should I reinstall Windows to fix this error?

Reinstalling Windows should not be the first troubleshooting step. Investigate the file system driver stack, storage drivers, filter drivers and storage hardware first. Reinstallation may not resolve a faulty hardware component or an underlying driver compatibility problem.

Official References

• Microsoft Learn – Bug Check 0xEB: DIRTY_MAPPED_PAGES_CONGESTION
• Microsoft Learn – Windows Bug Check Code Reference
• Microsoft Learn – Analyze a Kernel-Mode Dump File Using WinDbg
• Microsoft Learn – Generate a Kernel or Complete Crash Dump
• Microsoft Support – Troubleshooting Windows Unexpected Restarts and Stop Code Errors

Key Takeaways

DIRTY_MAPPED_PAGES_CONGESTION (0x000000EB) is a serious Windows kernel error associated with the inability to write modified memory pages successfully to their intended storage locations.

The primary troubleshooting priority should be identifying deadlocks or failures within the file system and storage driver stack. Third-party filter drivers, storage controller drivers and unresponsive storage devices are important areas to investigate.

For recurring crashes, analysing the Windows memory dump using WinDbg commands such as !analyze -v, !vm 3 and !process 0 7 can provide valuable evidence for identifying the underlying problem.

Always preserve important data and use diagnostic evidence before replacing hardware, modifying system configurations or reinstalling Windows.