STATUS_NO_CALLBACK_ACTIVE 0XC0000258 — the real fix

Quick answer for advanced users

Update or roll back any third-party drivers that register callbacks via KeRegisterObjectNotification or similar — antivirus, backup agents, or hypervisor drivers are the usual suspects. Disable the driver or switch to a known-good version.

What's actually happening here?

This error means a kernel-mode driver tried to execute a “callback return” system service — think ObRegisterCallbacks or PsSetCreateProcessNotifyRoutine — at a point where the callback it was returning from no longer existed. The system caught this as an invalid state transition and raised STATUS_NO_CALLBACK_ACTIVE (0xC0000258).

You'll usually see this on Windows Server 2019 or 2022, often logged in the System event log as a bugcheck or warning from ntoskrnl.exe. The trigger? A driver that unregistered a callback while a return from that same callback was still in flight — a classic race condition. Antivirus filters, backup software that hooks file operations, or hypervisor-type drivers (VMware Tools, Hyper-V integration services) are common culprits.

The key point: this isn't your application's fault. It's a driver-level bug. You can't fix it by patching your code. You need to find and update the offending driver.

Fix steps

1. Identify the driver in the crash dump. Open the most recent memory.dmp or minidump in WinDbg or use !analyze -v. Look for the line that says IMAGE_NAME or MODULE_NAME. That's your target. Common names: mwac.sys (Malwarebytes), snapman.sys (Acronis), vmci.sys (VMware).
2. Check the Windows event log. Run eventvwr.msc, navigate to Windows Logs > System. Filter by event source BugCheck or Kernel-General. Look for event IDs 1001 or 1 that reference 0xC0000258. The bugcheck parameters sometimes list the driver's base address.
3. Update or roll back the driver. If the driver is from your security suite, backup agent, or virtualization platform, go to the vendor's site and grab the latest version. On Server 2019, I've seen Symantec Endpoint Protection 14.x and older Malwarebytes 4.x trigger this. If updating doesn't help, roll back to a version that worked before the crashes started.
4. Disable the driver temporarily. If you need the server back up now, disable the suspect driver from the registry. HKLM\SYSTEM\CurrentControlSet\Services\ — find the service key matching the driver name, set Start to 4 (disabled), and reboot. This proves the driver was the cause. Then decide: update, replace, or live without it.
5. Run Driver Verifier (advanced). If you can't find the driver from dump analysis, enable Driver Verifier for all third-party drivers. Reboot and reproduce the crash. The verifier will catch the misbehaving driver with extra detail. verifier.exe /standard /all — but be ready for a reboot that might trigger the bug faster.

If the main fix doesn't work

Three alternatives if updating the driver fails or you can't identify it:

• Boot into Safe Mode with Networking. This loads only Microsoft drivers. If the error disappears, you've confirmed a third-party driver is the problem. Then use safe mode to disable drivers one by one until you find the culprit.
• Remove recently installed software. Think about what changed on the server in the last 72 hours — a new security tool, a backup agent update, a hypervisor patch. Uninstall that software completely, reboot, and test.
• Apply a hotfix from Microsoft. Rare, but for Server 2019 some cumulative updates (e.g., KB5005565) included a fix for a callback race in ntoskrnl.exe. Install all pending Windows Updates. If the bug is in Microsoft's code, you'll need their patch, not a driver update.

Prevention tip

Don't let drivers auto-update on production servers — at least not security software or backup agents. Test new versions in a staging environment first, especially if they hook kernel callbacks. Keep a snapshot or backup of your server's driver state (export HKLM\SYSTEM\CurrentControlSet\Services for third-party drivers). That way, when a driver update introduces this bug, you can roll back in minutes, not hours.

Also: enable crash dump collection on your servers. A minidump is your best friend when debugging STATUS_NO_CALLBACK_ACTIVE. Without it, you're guessing.