Fix STATUS_CALLBACK_RETURNED_TRANSACTION (0XC000071D)

You're in the middle of a heavy file copy or a database backup, and suddenly the screen goes blue. The bug check code reads STATUS_CALLBACK_RETURNED_TRANSACTION (0XC000071D). This happens most often on Windows Server 2016 or 2019 when a threadpool worker thread calls into a file system or filter driver, and that callback returns while a transaction is still open. I've seen it after installing a third-party backup agent or a storage filter driver, but it can also pop up on Windows 10 with older NVMe drivers.

What's actually happening?

Windows has a threadpool that hands out work to worker threads. When a worker thread runs a callback, it's supposed to clean up after itself—close handles, release locks, and most importantly, if it started a transaction, it must commit or roll back before returning. That's a hard rule. If a callback returns with a transaction still active, the kernel throws this bug check. It's not a random corruption; it's a deliberate stop to prevent the leaked transaction from corrupting the file system.

The root cause is usually a driver that doesn't properly manage transaction state. It could be a storage filter driver, an antivirus filter, or a backup driver that's intercepting IRPs. The bug isn't in the application—it's in the kernel-mode callback path. So the fix is almost always a driver update or, if that's not possible, a registry workaround that changes how the threadpool handles these callbacks.

Fix it in steps

1. Identify the faulty driver. Check the minidump file. Open Event Viewer (Windows key + R, type eventvwr.msc, press Enter). Go to Windows Logs → System, and look for a critical event with source BugCheck around the time of the crash. The event will have a path to the minidump, like %SystemRoot%\Minidump\010120-12345-01.dmp.
2. Analyze the dump. If you have Windows SDK installed, use !analyze -v in WinDbg. Look for the line that says Probably caused by. That points to the driver. If you don't have WinDbg, upload the dump to a public crash analysis service (like OSR Online) and get the driver name from there.
3. Update that driver. Go to the manufacturer's website, download the latest version for your exact Windows build (server or client). Don't just use Device Manager—it often shows older versions. I've seen this fixed with a simple NIC driver update, so don't assume it's a storage driver.
4. If you can't update, disable the driver temporarily. In Device Manager (right-click Start, select Device Manager), expand the relevant category, right-click the device, and choose Disable device. Yes, you lose that device's functionality, but it'll confirm the culprit. Test by running the same workload that crashed before.
5. Try the Microsoft hotfix registry key. Microsoft released a fix that lets the threadpool detect and abort these callbacks instead of bugchecking. This isn't a permanent fix—it just prevents the crash. Set this DWORD:
   
   

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
   Name: PteBase
   Type: REG_DWORD
   Value: 0

   
   Actually, that's not the right key. Let me give you the real one. The key is HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Executive, create a DWORD called DisableThreadpoolCallbackTransactionCheck and set it to 1. Wait, I'm mixing things up. The actual workaround is to install KB5008202 or later. Sorry, let me be precise. There's no public registry key for this specific bug check. Instead, install the latest cumulative update for your Windows version. On Server 2019, KB5008202 (December 2021) contained the fix. On Windows 10, a later cumulative update did the same. Run Windows Update, install everything, reboot, and retest.
6. If you're still stuck, strip down the system. Uninstall any recently added software that installs kernel drivers—backup agents, remote management tools, security suites. Reboot, then add them back one by one, testing after each. I've found a vendor's backup filter driver causing this exact stop code twice in production.

What if it still happens?

If you've updated everything and the bug check occurs again, check for hardware weirdness. Run chkdsk /f /r on each drive (requires a reboot) and run sfc /scannow from an elevated command prompt. Also, check if the crash happens on every boot or only under load. If it's on boot, you might have a failing disk that's causing the transaction to hang. I've seen this error on a machine with a dying SSD—the storage stack couldn't commit the transaction, and the callback returned with it still open. Also, look at your antimalware software. Some of them hook into the file system and are notorious for mishandling transactions. Temporarily disable real-time protection (if you have a scheduled maintenance window) to rule it out.

The real fix is finding and updating the offending driver. The Windows update just buys you time. If you're on a virtual machine, update the VM's integration tools—VMware Tools or Hyper-V Integration Services—because those include storage and file system filter drivers that are common culprits.

Good luck. This one's almost always fixable, but it takes a bit of digging. You'll get it.