0XC000071E

STATUS_CALLBACK_RETURNED_LDR_LOCK (0XC000071E) Fix

Windows Errors Intermediate 👁 6 views 📅 Jun 8, 2026

A threadpool worker thread returned from a callback while still holding the loader lock. This usually points to a buggy driver or DLL that deadlocks the process.

Quick answer for the impatient

Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth from an admin command prompt, then check for a corrupt driver or third-party DLL. If that doesn't work, it's almost certainly a buggy driver – update or roll back recent driver changes.

What's actually happening here

The error code 0xC000071E (STATUS_CALLBACK_RETURNED_LDR_LOCK) is thrown by the Windows kernel when a threadpool worker thread returns from a callback function but hasn't released the loader lock. The loader lock is a global lock used by the OS loader (ntdll) to serialize operations like loading DLLs, resolving imports, and running DllMain routines. If a callback holds that lock when it returns, it deadlocks the entire process – no other thread can load or unload DLLs. This isn't a normal user-mode bug; it's a low-level violation that often crashes system-critical processes like svchost or explorer.

Real-world triggers: I've seen this happen after installing a sketchy printer driver that hooks kernel32 imports, or after a Windows Update that ships a broken version of a system DLL. It can also pop up when a third-party antivirus driver injects code into a threadpool callback.

Fix steps – try these in order

  1. Run SFC and DISM. Open an admin Command Prompt and run sfc /scannow. Let it finish. Then run DISM /Online /Cleanup-Image /RestoreHealth. This fixes corrupt system files that might be causing the loader lock to be misbehaved. Repeat both until SFC reports no integrity violations.
  2. Check for recent driver or software changes. Go to Settings > Update & Security > Windows Update > View update history. Uninstall any updates from the last week. Also check Programs and Features for recently installed software – uninstall anything suspicious (especially printer software, VPN drivers, or anti-malware tools). Reboot after each removal.
  3. Roll back or update graphics drivers. Open Device Manager, expand Display adapters, right-click your GPU, select Properties > Driver tab > Roll Back Driver if available. If not, download the latest driver from the GPU vendor's site (NVIDIA, AMD, Intel) and do a clean install (check the “Perform clean installation” box if NVIDIA).
  4. Check for broken third-party DLLs. Use Process Monitor from Sysinternals: filter on the process that's crashing (e.g., svchost.exe). Look for Load Image operations that return NOT FOUND or PATH NOT FOUND for DLLs in C:\Windows\System32. A missing DLL can cause the loader lock to be held indefinitely if the callback tries to load it.
  5. Use Verifier to isolate the bad driver. Run verifier.exe from an admin prompt. Select “Create custom settings (for code developers)” > Next > Select “Lock Windows critical code sections” and “Force IRQL checking” > Next > Select “Select driver names from a list” > Next. Sort by provider and check all non-Microsoft drivers. Reboot. If the system crashes with a different stop code that names a driver, you've found the culprit.

Alternative fixes if the main ones fail

  • Do a clean boot. Run msconfig, enable Selective startup, uncheck “Load startup items”. Disable all non-Microsoft services on the Services tab. Reboot. If the error goes away, re-enable services one by one until you find the offender.
  • Repair-install Windows. Use the Windows Media Creation Tool to perform an in-place upgrade. This keeps your files but replaces system files. It's drastic but effective against corruption that SFC can't touch.
  • Check the Application event log. Open Event Viewer, go to Windows Logs > Application. Look for Warning or Error events with source “Application Error” or “Windows Error Reporting” that mention 0xC000071E. The faulting module path (e.g., C:\Program Files\SomeCompany\bad.dll) is your smoking gun.

Prevention tip

Once you've fixed it, avoid installing software that hooks into system DLLs or runs kernel-level code unless you trust the publisher. Driver updates from Windows Update are generally safe, but I always wait a week before installing optional driver updates – let the crowd test them first. Also, keep a system restore point before any major update. That's not paranoid; it's pragmatic.

The loader lock is a single point of failure in Windows. The kernel expects callbacks to release it before returning. If you see this error, you're dealing with code that broke that contract – and it's almost always a driver or a third-party DLL that doesn't follow the rules.

Was this solution helpful?