STATUS_CALLBACK_RETURNED_WHILE_IMPERSONATING 0xC0000710 Fix
This Windows error means a thread pool worker finished a callback still impersonating a client. Usually a driver or third-party software bug. Here's how to pin it down.
Quick answer for pros: Boot into Safe Mode, run verifier /reset to disable Driver Verifier, then use Event Viewer or a kernel dump to find which driver's callback is messing up impersonation. Uninstall or update it.
What's happening here?
You're staring at a 0xC0000710 blue screen or an event log entry that reads "A thread pool worker thread is impersonating a client, after a callback to 0x%p(0x%p)". I know this error is infuriating because it doesn't name the bad guy directly. Microsoft's ntstatus.h defines it as STATUS_CALLBACK_RETURNED_WHILE_IMPERSONATING. The short version: a Windows thread pool worker thread ran a callback function (usually from a driver or a piece of system software), and that function forgot to revert the impersonation token before returning. Thread pool threads are shared across the system — leaving impersonation active corrupts security contexts and can crash processes or trigger a bugcheck.
This tripped me up the first time too. I saw it on a Windows 10 21H2 machine after installing a third-party backup tool that hooked into kernel callbacks. The pattern is almost always a kernel-mode driver or a system service that registers a callback via PsRegisterThreadPoolCallback or similar.
Fix steps
Step 1 — Check if Driver Verifier is running
Driver Verifier is often the trigger. Microsoft uses it internally to catch precisely these bugs. If you or an update enabled it, you'll see this error when a driver misbehaves. Open an admin Command Prompt and run:
verifier /queryIf it reports active verifier settings, run:
verifier /resetReboot. If the error stops, you've found the cause — a driver failed Verifier's checks. Now you need to identify that driver.
Step 2 — Use Event Viewer to find the callback address
The error message includes two addresses (the callback and the context). Boot normally (or from the last crash dump) and open Event Viewer. Go to Windows Logs > System. Filter by event source Microsoft-Windows-Kernel-EventTracing or just look for errors with ID 0xC0000710. The logged addresses look like 0xfffff80123456789. Write those down.
Step 3 — Convert the callback address to a driver name
This is the part that feels like detective work. Download WinDbg (or use the online OSR Online kernel debugger). Load the crash dump or a live kernel dump (Ctrl + Scroll Lock + Scroll Lock to force a manual dump on some systems). Then run:
lmDv | grep -i <your_address_prefix>If that's too much, use !address <callback_address> to see which module owns it. In practice, the culprit is often nvlddmkm.sys (NVIDIA), iaStorA.sys (Intel RST), or a third-party antivirus driver like SymNet.sys.
Step 4 — Update, disable, or remove the offending driver
Once you've got the driver name, update it from the manufacturer's site. If it's a third-party driver (backup software, VPN, AV), try disabling or uninstalling it. For system drivers like Intel RST, roll back to the previous version from Device Manager.
Alternative fixes if the main one fails
Fix A — System File Checker
Sometimes a corrupt system file can break callback handling. Run:
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealthReboot. This rarely fixes the impersonation error by itself but eliminates one variable.
Fix B — Disable all non-Microsoft services (clean boot)
Press Win + R, type msconfig. Go to Services tab, check Hide all Microsoft services, then click Disable all. Reboot. If the error disappears, re-enable services one by one until the bad one resurfaces. This is tedious but works when no driver name is obvious.
Fix C — Check for pending Windows updates
Microsoft sometimes ships fixes for specific callback bugs. Go to Settings > Windows Update > Check for updates. Install any optional driver updates too (under Advanced options > Optional updates).
Prevention tip
The root cause is a poorly written callback that doesn't call RevertToSelf before returning. You can't fix other people's drivers, but you can lock down your system. Stay away from "system optimizer" tools, older backup software, and cheap VPNs that install kernel drivers. If you're a developer, always pair RevertToSelf with ImpersonateSelf or SetThreadToken in your callbacks — and use __try/__except to clean up even on exceptions.
One more thing: if you're using Windows 11 22H2 or later, enable Memory Integrity under Core Isolation in Windows Security. It blocks unsigned kernel callbacks entirely. That will stop this error for all future third-party drivers, but it may break some older hardware drivers. Trade-off, but worth it for stability.
Was this solution helpful?