MULTIPLE_IRP_COMPLETE_REQUESTS 0x00000044 and IRP handling bugchecks

Fix it now

0x00000044 means a driver called IoCompleteRequest for an I/O request packet that was already complete. Microsoft’s published reading is two drivers each believing they own the packet: the first completion succeeds, the second bug checks. The driver named in the dump is usually the one that made the second call, not the one that caused the problem.

fltmc
driverquery /si /fo table

1. Open the newest file in %SystemRoot%\Minidump in WinDbg and run !analyze -v. Note the module named and, more usefully, the device stack the packet was travelling down.
2. Read the fltmc output against what you believe is installed. You are looking for two products doing the same job on one stack, or a filter belonging to something that was uninstalled.
3. Remove the redundant one with the vendor’s own removal utility. An ordinary uninstall frequently leaves the kernel filter loaded.
4. Restart and confirm with fltmc that the filter has actually gone, rather than trusting the uninstaller.
5. Update whichever product remains to a build its vendor supports on your Windows version, then re-run the workload that crashed.

fltmc unload <name> takes a minifilter out of the path without a reboot, which makes a clean test. Some products reload theirs from a service, so check with fltmc afterwards.

If the stack is now clean and the workload runs, you are done. The next section covers how a packet gets completed twice and which of the sibling codes you might be looking at instead.

Why it happens

Windows I/O runs on request packets that travel down a device stack. Each driver in the stack gets its own stack location, does its part, and either completes the packet or passes it further down. Completion is a one-way door: once a driver calls the completion routine the packet is finished, its memory can be released, and any later reference to it is a reference to memory that no longer belongs to anyone.

Microsoft’s description of 0x00000044 is narrow and worth taking literally: two separate drivers each believed they owned the packet and each attempted to complete it. The first call succeeded. The second bug checked. It does not say the second caller is at fault, and in practice it often is not – it is simply the one that arrived after the door had closed. That is why replacing the named driver so often changes nothing.

The sibling codes describe adjacent mistakes in the same machinery, and they are not interchangeable. 0x00000035 is a higher-level driver calling IoCallDriver with no stack locations left, so it wrote off the end of the packet and corrupted whatever was next – Microsoft calls that a disastrous situation for exactly that reason. 0x00000048 is a packet that completed normally with a cancel routine still set, and whose parameter 2 is that cancel routine, which identifies the driver. 0x000000CB is locked pages left behind after an I/O operation, and it is only issued when TrackLockedPages is enabled; without it the system issues the much less informative 0x76 instead.

0x0000002A is the odd one out. It has a published meaning – an IRP found in a state inconsistent with the rest of itself, such as one being completed while still marked as queued to a driver’s device queue – but Microsoft also states that the code is not currently used by the system and exists for debugging purposes. If you are triaging a live machine, it is not what you are looking at.

Full reference

Looking at a stack rather than a module name

The four codes, side by side

Turning on the diagnostic that produces 0x000000CB

If you are seeing 0x76 rather than 0x000000CB, you are getting the uninformative version of the same fault. Setting TrackLockedPages to DWORD 1 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management makes the system issue 0x000000CB instead, which carries the MDL and the page count. Driver Verifier’s pool tracking option can raise the same bug check. Both are diagnostics for a test machine, not settings to leave on an estate.

Using Driver Verifier on this class of fault

I/O verification is precisely the check for this. It is part of the standard option set, so verifier /standard /driver name.sys against the suspect drivers is enough – there is no need to reach for the aggressive options first. Enable it on a test machine, reproduce the workload, and let it bug check with the offending driver on the stack rather than the one that came second. Clear it with verifier /reset and restart when you have your answer.

Driver Verifier crashes machines deliberately and Microsoft says to run it only on computers used for testing and debugging. Take a backup, and enable it with verifier /bootmode resetonbootfail so a failed start clears it automatically.

When the stack looks clean and it still crashes

• Compare several dumps. A module that changes between crashes points away from a single filter and towards pool corruption.
• Check the System log around each crash for storage or device errors immediately before the bug check.
• Confirm the remaining security product is a build its vendor supports on your Windows version. Kernel components fall behind quickly when a licence lapses and updates stop arriving.
• Where two products genuinely have to coexist, apply each vendor’s documented exclusions for the other rather than removing either.
• If the crash only appears under backup or replication, run that job with the other filters unloaded to narrow the pair involved.

Every code this article covers

Confirm the fix worked

1. fltmc lists only the filters you intend to have, all belonging to products that are still installed.
2. The workload that crashed – a full backup, a large file copy, whatever it was – completes without a new dump.
3. The remaining security product reports itself active in Windows Security.
4. No new files appear in %SystemRoot%\Minidump over several days of normal use.

Questions people ask about this