Windows Blue Screen Error 0x0000012E (INVALID_MDL_RANGE): Causes, Meaning and Troubleshooting

Quick Answer

0x0000012E (INVALID_MDL_RANGE) is a Windows Blue Screen of Death (BSOD) error indicating that a kernel-mode driver attempted to create a partial Memory Descriptor List (MDL) using a virtual memory address range that falls outside the range described by the original MDL.

Microsoft identifies this error as typically resulting from a driver programming problem involving the IoBuildPartialMdl() Windows kernel routine.

The error can occur when a driver incorrectly handles memory buffers or supplies an invalid address or length while processing an I/O operation. Identifying the responsible driver generally requires examining Windows crash dump files with debugging tools.

For ordinary users, recommended initial actions include reviewing recently installed drivers and hardware, installing appropriate manufacturer updates, and collecting crash dump information. Reinstalling Windows or replacing RAM should not be the first response to this error.

What Is INVALID_MDL_RANGE Error 0x0000012E?

INVALID_MDL_RANGE is a Windows stop error, also known as a bug check, that occurs when Windows detects an invalid memory range while a kernel-mode driver is attempting to construct a partial memory descriptor list.

Windows uses Memory Descriptor Lists (MDLs) to describe the physical memory pages associated with a virtual memory buffer. These structures are important when drivers perform operations involving data transfers, device communication and memory access.

The IoBuildPartialMdl() routine allows a driver to create a new MDL representing a smaller portion of an existing memory buffer.

For this operation to be valid, the requested virtual address and length must identify a proper subrange of the original buffer described by the source MDL.

If the requested range extends outside the source buffer, Windows can detect the invalid operation and generate bug check 0x0000012E.

According to Microsoft, this condition is typically associated with a driver bug. The stop code identifies the type of invalid operation, but does not independently identify the exact driver or hardware component responsible.

Official documentation: Microsoft Bug Check 0x12E: INVALID_MDL_RANGE.

Understanding Memory Descriptor Lists (MDLs)

A Memory Descriptor List is a kernel-mode data structure used by Windows drivers to describe the physical memory pages associated with a virtual memory buffer.

A virtual memory buffer may occupy consecutive virtual addresses while the corresponding physical memory pages are distributed across different physical memory locations. An MDL provides information that allows the operating system and drivers to work with these memory pages during I/O operations.

What Does IoBuildPartialMdl() Do?

The IoBuildPartialMdl() routine creates a new MDL describing a smaller portion of a buffer already represented by another MDL.

Drivers may use this functionality when splitting a large data transfer into smaller operations.

Its documented function signature is:

VOID IoBuildPartialMdl(
    PMDL SourceMdl,
    PMDL TargetMdl,
    PVOID VirtualAddress,
    ULONG Length
);

The parameters have the following meanings:

• SourceMdl: A pointer to the original MDL describing the existing memory buffer.
• TargetMdl: A pointer to the caller-allocated MDL that will describe the selected portion of the original buffer.
• VirtualAddress: The starting virtual address of the memory range to be described by the target MDL.
• Length: The size, in bytes, of the memory range to be described.

The combination of VirtualAddress and Length must specify a valid subrange of the original buffer described by SourceMdl.

If the requested range falls outside the original buffer, the operation is invalid.

Microsoft documentation: IoBuildPartialMdl function (wdm.h).

Symptoms of INVALID_MDL_RANGE BSOD

A computer experiencing bug check 0x0000012E may exhibit one or more of the following symptoms:

• Windows displays a Blue Screen of Death and restarts automatically.
• The system displays the stop code INVALID_MDL_RANGE.
• The error appears as 0x0000012E on the blue screen or in crash analysis information.
• The computer restarts unexpectedly during normal operation.
• The system crashes while accessing storage devices or performing I/O-intensive operations.
• The error occurs after installing or updating a device driver.
• Repeated crashes occur during startup, shutdown or power-state transitions.
• Crash dump files are generated in the Windows directory.

These symptoms are not sufficient to identify the exact cause. The timing of the crash, installed drivers and memory dump analysis provide more useful diagnostic information.

Common Causes of Error 0x0000012E

Microsoft specifically identifies invalid memory-range handling in the IoBuildPartialMdl() routine as the typical cause of this bug check. The following conditions are relevant areas to investigate when diagnosing the underlying driver problem.

1. Faulty or Incorrectly Implemented Device Drivers

A kernel-mode driver may incorrectly calculate a memory buffer's starting address or length when creating a partial MDL.

For example, a driver may request a memory range that extends beyond the original buffer. Windows can detect this invalid range and stop the system.

Third-party drivers should be investigated when the crash dump indicates that their code was involved in the failing operation.

2. Outdated or Incompatible Drivers

An outdated driver may contain programming defects or compatibility problems with the installed Windows version.

Drivers associated with storage controllers, network adapters, USB devices and other hardware should be reviewed when their involvement is indicated by the crash dump.

However, an outdated driver is not automatically responsible for every INVALID_MDL_RANGE error.

3. Third-Party Storage and File System Drivers

Storage-related software can participate in operations involving memory buffers and I/O requests.

Examples include:

• Third-party disk controller drivers.
• Storage management software.
• File system filter drivers.
• Backup and recovery software.
• Disk encryption software.
• Virtual disk and storage virtualization drivers.

If the crash occurs during disk operations, sleep transitions or file system activity, the relevant storage driver stack should be examined.

The presence of a Windows file system module in a crash stack does not necessarily mean that the file system itself is defective. Another driver may have supplied invalid data or corrupted memory earlier.

4. Network and Filter Drivers

Network drivers and third-party network filter drivers may process memory buffers during packet transmission and reception.

VPN clients, network security products, traffic inspection software and other network filtering components can introduce additional kernel-mode drivers.

If crashes begin after installing or updating one of these applications, investigate its associated drivers and compatibility with the Windows version.

5. Memory Corruption

Incorrect memory handling by a kernel-mode driver can potentially corrupt data structures used by other components.

Consequently, the component visible at the moment of the crash may not be the component that originally caused the corruption.

Physical RAM problems are another possible area of investigation when there are additional hardware-related symptoms or diagnostic findings. However, INVALID_MDL_RANGE does not directly establish that RAM is defective.

6. Recently Installed Hardware or Software

New hardware or software can introduce additional drivers into the Windows kernel.

Investigate recent changes such as:

• Installing a new storage controller or USB device.
• Adding a network adapter or other expansion card.
• Installing a VPN or endpoint security application.
• Updating motherboard chipset or storage drivers.
• Installing backup, disk imaging or virtualization software.
• Updating device firmware or related drivers.

A recent change is a useful diagnostic clue, but it must be verified against the crash evidence.

How to Fix Windows BSOD 0x0000012E INVALID_MDL_RANGE

The appropriate repair depends on which driver or component is responsible. Follow the steps below in order, starting with less disruptive checks.

Step 1: Restart Windows and Record the Error

If the error occurs only once, restart the computer and check whether Windows operates normally.

Record the following information before attempting further troubleshooting:

• Exact stop code: INVALID_MDL_RANGE.
• Bug check value: 0x0000012E.
• Any driver or module name displayed on the blue screen.
• What the computer was doing when the crash occurred.
• Recent hardware, software or driver changes.
• Whether the problem occurs during startup, normal use, shutdown or sleep.

If the error repeatedly occurs, continue with the following diagnostic steps.

Step 2: Check Recently Installed Drivers

A recently installed or updated driver is an important starting point when investigating a driver-related bug check.

1. Right-click the Start button.
2. Select Device Manager.
3. Expand the relevant hardware categories.
4. Identify devices associated with recent driver changes or warning symbols.
5. Open the device properties and review the driver information.
6. Compare the installed driver version with the manufacturer's supported version.

If the crashes started immediately after a driver update, consider using the Roll Back Driver option when available.

Alternatively, install a compatible driver supplied by the computer or hardware manufacturer.

Do not update or replace every driver indiscriminately. Prioritize components identified by crash analysis or associated with the recent system change.

Step 3: Update Windows

Install applicable Windows updates to obtain relevant operating system fixes and supported driver updates.

1. Open Settings.
2. Navigate to Windows Update.
3. Select Check for updates.
4. Review available updates.
5. Install applicable updates and restart the computer when requested.

For Windows 10, open Settings > Update & Security > Windows Update.

For hardware-specific drivers, also consult the manufacturer's support website. Avoid installing drivers from unverified third-party download websites.

Step 4: Disconnect Recently Added Hardware

If the problem started after connecting new hardware, temporarily disconnect the device where it is safe to do so.

Examples include:

• External USB storage devices.
• USB hubs and docking stations.
• Newly installed expansion cards.
• External network adapters.
• Other recently connected peripherals.

Shut down the computer before disconnecting internal components. Follow the manufacturer's hardware handling instructions.

Restart Windows and observe whether the crash returns.

If the system becomes stable after removing a particular device, investigate its driver, firmware and hardware compatibility.

Step 5: Investigate Recently Installed Software

Some applications install kernel-mode drivers or filter components that operate below the normal application layer.

Review software installed or updated shortly before the first crash.

Pay particular attention to:

• VPN and network security software.
• Antivirus and endpoint protection products.
• Disk encryption utilities.
• Backup and recovery applications.
• Virtualization and virtual disk software.
• Third-party storage management tools.

If a particular application is strongly associated with the crash, check its manufacturer's support documentation for a compatible update or recommended removal procedure.

Do not disable security protection permanently or remove business-critical software without an appropriate replacement and recovery plan.

Step 6: Start Windows in Safe Mode

Safe Mode starts Windows with a limited set of drivers and services. It can help determine whether the crash is associated with software or drivers that are not required for basic Windows operation.

To access Safe Mode:

1. Open Settings.
2. Navigate to System > Recovery in Windows 11, or Update & Security > Recovery in Windows 10.
3. Under Advanced startup, select Restart now.
4. After Windows Recovery Environment opens, select Troubleshoot.
5. Select Advanced options > Startup Settings.
6. Select Restart.
7. Press the appropriate number key for Safe Mode.

If Windows cannot start normally, Windows Recovery Environment may also be accessed through supported recovery startup methods.

If the computer remains stable in Safe Mode, investigate third-party drivers, services and applications that are not loaded in that environment.

Safe Mode stability is a diagnostic clue, not proof that a particular third-party driver is responsible.

Step 7: Check Windows Crash Dump Files

Crash dump files contain information about the system state when Windows encountered the stop error. They are particularly useful for investigating driver-related crashes.

Common dump file locations include:

• C:\Windows\Minidump\ - Contains small memory dump files when configured.
• C:\Windows\MEMORY.DMP - Contains a kernel or complete memory dump, depending on the configured dump type.

The availability and size of these files depend on Windows crash dump settings and the system configuration.

How to check crash dump settings

1. Press Win + R.
2. Enter sysdm.cpl and press Enter.
3. Open the Advanced tab.
4. Under Startup and Recovery, select Settings.
5. Review the Write debugging information setting.
6. Check the configured dump file location.

For future crashes, select an appropriate automatic or kernel memory dump option when sufficient disk space and system configuration permit.

Do not delete existing crash dumps before preserving them for analysis.

Step 8: Analyze the Dump File Using WinDbg

WinDbg is Microsoft's debugging tool for examining Windows crash dumps and investigating kernel-mode failures.

It can help technicians identify the bug check parameters, examine the call stack and investigate which driver was executing when the crash occurred.

Procedure

1. Install WinDbg using the official Microsoft distribution.
2. Launch WinDbg.
3. Select the option to open a dump file.
4. Open the relevant .dmp file from the Minidump folder or Windows directory.
5. Allow the debugger to load the required symbols.
6. Enter the following command in the debugger command window:

!analyze -v

This command requests a detailed analysis of the crash.

Review the following information:

• BUGCHECK_CODE: Confirms the stop code.
• BUGCHECK_P1 to BUGCHECK_P4: Displays the four bug check parameters.
• MODULE_NAME: Identifies a module associated with the crash analysis.
• IMAGE_NAME: Displays the image name associated with the identified module.
• FAULTING_IP: Provides the faulting instruction address when available.
• STACK_TEXT: Displays the available call stack information.
• PROCESS_NAME: Identifies the process context when available.

For bug check 0x12E, the four parameters represent the following values:

Parameter	Description
Parameter 1	SourceMdl - Original memory descriptor list.
Parameter 2	TargetMdl - Target memory descriptor list.
Parameter 3	VirtualAddress - Requested starting virtual address.
Parameter 4	Length - Requested memory range length.

These parameters provide information about the invalid MDL operation. They do not independently identify the responsible driver.

Important: A module appearing in the crash stack is not automatically the original cause. A driver may encounter corrupted data created earlier by another component. Technicians should correlate the call stack, module information, driver versions and repeated crash patterns before identifying the responsible component.

Official documentation: Analyzing a Kernel-Mode Dump File with WinDbg.

Step 9: Use Driver Verifier for Advanced Diagnosis

Driver Verifier is a Windows diagnostic tool that monitors selected kernel-mode drivers and checks their behavior against various driver requirements.

It can help identify certain invalid memory operations and driver programming problems that may contribute to system crashes.

Warning: Driver Verifier can deliberately cause additional Blue Screen errors when it detects a driver violation. It can also affect system performance and make a computer difficult to start.

It should generally be used by experienced technicians or driver developers on test systems, rather than as a routine repair step on business-critical computers.

Before using Driver Verifier:

• Back up important data.
• Ensure that Windows Recovery Environment or Safe Mode is accessible.
• Record the current driver configuration.
• Identify suspicious drivers using crash dump evidence.
• Avoid verifying every driver simultaneously.

Microsoft provides guidance for selecting drivers and interpreting Driver Verifier results.

Documentation: How to Use Driver Verifier for Driver Testing.

Step 10: Check System Memory if Other Evidence Suggests Hardware Problems

Although INVALID_MDL_RANGE is typically associated with driver programming errors, memory corruption can sometimes complicate the diagnosis.

If the computer also experiences unrelated memory errors, random crashes or hardware instability, perform a memory diagnostic.

To run Windows Memory Diagnostic:

1. Press Win + R.
2. Enter mdsched.exe.
3. Press Enter.
4. Select Restart now and check for problems, after saving your work.
5. Allow the diagnostic process to complete.

If the diagnostic reports memory errors, investigate the RAM modules and system hardware according to the manufacturer's instructions.

A successful memory test does not completely rule out intermittent hardware faults, and a memory test should not replace driver dump analysis.

Step 11: Use System Restore if the Error Started After a Recent Change

If the problem started after installing a driver, application or Windows update, System Restore may help return system configuration to an earlier working state.

1. Press Win + R.
2. Enter rstrui.exe.
3. Press Enter.
4. Review the available restore points.
5. Select a restore point created before the problem started.
6. Review the affected programs and drivers.
7. Follow the on-screen instructions to complete the restoration.

System Restore can affect installed applications, drivers and system configuration changes made after the selected restore point. Review the information carefully before proceeding.

It is not a substitute for backing up important personal files.

Advanced Troubleshooting for IT Professionals

When basic troubleshooting does not identify the responsible component, a more detailed investigation of kernel-mode driver behavior may be necessary.

1. Examine the Complete Bug Check Information

Record the four bug check parameters and compare them across multiple crash dumps.

Repeated crashes involving similar addresses, driver modules or call-stack patterns may help narrow down the investigation.

2. Inspect the Driver Stack

Investigate drivers associated with the operation that was active when the crash occurred.

Depending on the evidence, this may include:

• Storage controller and disk drivers.
• File system filter drivers.
• Network and VPN filter drivers.
• USB and peripheral drivers.
• Virtualization and security drivers.

Check the driver provider, version, date and compatibility with the installed Windows release.

3. Review IoBuildPartialMdl() Parameter Handling

For driver developers, the primary investigation should examine how the source MDL, target MDL, virtual address and length are calculated.

Verify that:

• The source MDL correctly describes the original buffer.
• The requested virtual address belongs to the source buffer.
• The requested length does not extend beyond the source buffer.
• The target MDL has sufficient allocated space to describe the requested pages.
• The source pages are properly locked before the operation when required.
• The source MDL remains valid throughout the operation.
• MDL reuse and mapping follow the documented Windows driver requirements.

Pay particular attention to integer calculations, address offsets, buffer lengths and the lifetime of memory objects.

For example, incorrect offset calculations or an invalid buffer length may cause the requested range to exceed the source MDL's described buffer.

4. Review MDL Mapping and Reuse

Driver developers should also review the lifecycle of partial MDLs.

Microsoft documents the use of MmPrepareMdlForReuse() when reusing a partial MDL that may have an existing system-address-space mapping.

The IoFreeMdl() routine releases the MDL and its associated system-address-space mapping when applicable.

Incorrect handling of MDL mappings, reuse or memory lifetime can introduce additional driver defects.

Reference: Microsoft IoBuildPartialMdl documentation.

What Should You Avoid When Troubleshooting 0x0000012E?

Some common troubleshooting actions can introduce unnecessary risks without addressing the underlying problem.

• Do not immediately reinstall Windows: A Windows reinstallation may not resolve a defective third-party driver.
• Do not replace RAM without evidence: The stop code primarily identifies an invalid MDL operation, not a confirmed RAM failure.
• Do not install random drivers: Use verified drivers supplied by the hardware or computer manufacturer.
• Do not modify kernel memory structures manually: Incorrect modifications can cause further system instability.
• Do not enable Driver Verifier on every driver without preparation: It can cause additional crashes and recovery difficulties.
• Do not delete crash dump files before analysis: They may contain important diagnostic information.
• Do not assume the module named in the crash report is always responsible: Earlier memory corruption may originate from another driver.

How to Prevent INVALID_MDL_RANGE Errors

Although users cannot directly correct programming defects inside third-party kernel drivers, appropriate system maintenance and driver management can reduce the risk of recurring problems.

• Install compatible drivers from official hardware manufacturer websites.
• Keep Windows updated with applicable security and reliability updates.
• Review driver updates before deploying them across business systems.
• Maintain supported firmware and chipset configurations.
• Remove obsolete or unnecessary third-party drivers using supported procedures.
• Keep security, backup and storage management software updated.
• Test new drivers in a controlled environment before production deployment.
• Preserve crash dumps whenever recurring BSOD errors occur.
• Monitor recurring system crashes and investigate repeated bug check patterns.
• Maintain regular backups of important business and personal data.

When Should You Contact Technical Support?

Professional technical support or the relevant hardware or software manufacturer should be contacted when:

• The computer repeatedly crashes with INVALID_MDL_RANGE.
• The system cannot start normally.
• The responsible driver cannot be identified through basic troubleshooting.
• The crash occurs on a business-critical server or workstation.
• Driver Verifier reports violations.
• Multiple bug check codes or signs of memory corruption appear.
• The error continues after updating or rolling back the suspected driver.

When requesting assistance, provide the following information where available:

• Windows edition, version and build number.
• Computer manufacturer and model.
• Hardware configuration.
• Bug check code and all four parameters.
• Crash dump files.
• WinDbg !analyze -v output.
• Recently installed drivers and applications.
• Steps or activities that reproduce the crash.

For kernel-mode driver problems, the driver developer or hardware manufacturer may need to examine the dump files and correct the underlying driver implementation.

Frequently Asked Questions (FAQs)

1. What does stop code 0x0000012E INVALID_MDL_RANGE mean?

It indicates that a kernel-mode driver attempted to create a partial Memory Descriptor List using a virtual address and length that specify a range outside the original buffer described by the source MDL.

2. Is INVALID_MDL_RANGE a hardware or software problem?

Microsoft identifies this bug check as typically resulting from a driver programming error. However, memory corruption or hardware instability may complicate an individual diagnosis. Crash dump analysis is needed to determine the actual cause.

3. Can a faulty driver cause INVALID_MDL_RANGE?

Yes. A driver that supplies an invalid memory range to IoBuildPartialMdl() can trigger this bug check. The responsible driver must be identified through crash analysis rather than assuming that every installed driver is defective.

4. Can faulty RAM cause error 0x0000012E?

Memory corruption can complicate kernel crash diagnosis, and faulty RAM should be investigated when other evidence supports a hardware problem. However, the 0x12E stop code itself does not confirm a RAM failure.

5. Does INVALID_MDL_RANGE mean my hard drive is damaged?

No. The error does not directly indicate physical disk damage. Storage-related drivers and file system filter components may be relevant if the crash occurs during storage operations, but disk failure must be established through separate diagnostics.

6. How can I identify the driver responsible for 0x0000012E?

Collect the Windows crash dump and open it using WinDbg. Run !analyze -v and review the bug check parameters, module information and call stack. Compare the findings with driver versions and repeated crash patterns.

7. Is it safe to use Driver Verifier to fix this error?

Driver Verifier is primarily a diagnostic and driver-testing tool, not a repair utility. It can deliberately cause system crashes when it detects driver violations. Use it only when you understand the recovery requirements and can access Safe Mode or Windows Recovery Environment.

8. Can updating Windows fix INVALID_MDL_RANGE?

Installing applicable Windows updates may resolve certain compatibility or operating system issues. However, if a third-party driver contains an invalid MDL calculation, that driver's manufacturer may need to provide a corrected version.

9. Why does INVALID_MDL_RANGE occur during startup or shutdown?

Startup and shutdown involve device initialization, storage operations and changes in hardware power states. A driver defect during one of these operations may trigger the bug check. The actual cause must be established through crash dump analysis.

10. Should I reinstall Windows to fix 0x0000012E?

Reinstalling Windows should not be the first troubleshooting step. First investigate driver updates, recent hardware or software changes and crash dump information. A clean installation may not resolve a defective third-party driver and can introduce additional data recovery work.

Key Takeaways

• 0x0000012E INVALID_MDL_RANGE is a Windows kernel bug check related to an invalid memory descriptor list range.
• The typical documented cause is an incorrect call to IoBuildPartialMdl() by a kernel-mode driver.
• The requested virtual address and length must describe a valid subrange of the original source MDL.
• Storage, network, security and other third-party drivers may warrant investigation depending on the crash evidence.
• WinDbg and Windows crash dump files are important tools for identifying the responsible component.
• Driver Verifier can assist advanced troubleshooting but should be used carefully.
• The stop code alone does not prove that RAM, the hard drive or Windows installation is defective.

Official References

1. Microsoft Learn - Bug Check 0x12E: INVALID_MDL_RANGE - Official explanation of the stop code and its four parameters.
2. Microsoft Learn - IoBuildPartialMdl Function - Technical documentation covering the function, parameters and requirements for creating partial MDLs.
3. Microsoft Learn - Using MDLs - Explains Memory Descriptor Lists and their use in Windows drivers.
4. Microsoft Support - Troubleshooting Windows Unexpected Restarts and Stop Code Errors - General troubleshooting guidance for Windows 10 and Windows 11 stop errors.
5. Microsoft Learn - Stop Code Error or Bug Check Troubleshooting - Advanced diagnostic guidance for Windows stop errors.
6. Microsoft Learn - Driver Verifier - Official documentation for testing and diagnosing Windows drivers.
7. Microsoft Learn - Analyzing a Kernel-Mode Dump File with WinDbg - Guidance for analyzing Windows kernel crash dumps.