STATUS_HANDLE_NOT_CLOSABLE (0XC0000235) Fix — NtClose on Protected Handle

You're staring at a blue screen with 0XC0000235 and the message STATUS_HANDLE_NOT_CLOSABLE. I know that feeling — you've got work to do, and Windows just decided to brick your session. The good news is this isn't a hardware failure. It's almost always a driver or a third-party kernel module calling NtClose on a handle that was explicitly protected via NtSetInformationObject. You can't just ignore it and hope it goes away. Here's how to kill it.

The Fix — Find and Remove the Bad Driver

The culprit here is almost always a third-party driver that has a bug in its cleanup code. Microsoft's own drivers rarely trigger this because they follow strict handle lifecycle rules. Vulnerable scanner drivers, VPN clients, backup software, or old anti-malware tools are the usual suspects.

Step 1: Check the crash dump

You need to look at the crash dump to see which driver was on the call stack when the crash happened. If you haven't enabled dump files yet, do it now.

1. Press Win + R, type sysdm.cpl, hit Enter.
2. Go to the Advanced tab > Startup and Recovery > Settings.
3. Under Write debugging information, select Automatic memory dump or Kernel memory dump.
4. Set Small memory dump folder to %SystemRoot%\Minidump.
5. Click OK and reboot.

Next time the crash happens, open WinDbg (install from Microsoft Store or Windows SDK). Load the dump file — either C:\Windows\MEMORY.DMP or a minidump from %SystemRoot%\Minidump. Run this command:

!analyze -v

Look at the STACK_TEXT section. You'll likely see nt!NtClose at the top of the stack, with a driver like avgntflt.sys, mwac.sys, eamonm.sys, or vsock right below it. That's your smoking gun.

Step 2: Disable or update the offending driver

Once you know the driver name, disable or uninstall the associated software. If it's a security product, use the vendor's official removal tool — standard uninstall often leaves kernel drivers behind. For example, Avast has avastclear.exe, McAfee has MCPR.exe.

If you can't uninstall immediately, disable the driver manually:

1. Open Device Manager. Right-click the Start button and select Device Manager.
2. Go to View > Show hidden devices.
3. Expand Non-Plug and Play Drivers, find the driver by name, right-click > Disable device.

Reboot. If the crash stops, you've found the problem. Update the software to the latest version or switch to a different product.

Why This Happens — The Kernel's Handle Protection

Windows allows a process to mark a handle as protected using NtSetInformationObject with the flag ObjectHandleFlagProtectFromClose. This is a rare operation — only drivers or privileged services use it to prevent accidental or malicious closure of critical system objects (like the kernel's own process handle).

When NtClose is called on such a handle, the Object Manager checks the flag, sees it's protected, and returns STATUS_HANDLE_NOT_CLOSABLE (0xC0000235) instead of closing it. The caller (a driver) doesn't expect this return value, and instead of handling it gracefully, it panics and crashes the system. The real bug is that the driver didn't verify the handle was supposed to be closed, or it closed a handle it didn't own.

Less Common Variations

Variant 1: Handle duplication gone wrong

Some drivers duplicate a protected handle and then try to close the original or the duplicate without proper synchronization. This often shows up under heavy I/O load — like copying large files or running a backup while an antivirus scan is active. The crash dump will show nt!ObpCloseHandle in the stack alongside the driver's duplicate call.

Variant 2: Filter driver conflict

Multiple filter drivers (like encrypted file system drivers or backup filters) can step on each other's handles. If you see fltmgr.sys in the stack, this is likely. The fix is to identify the conflicting software and remove one. Use fltmc instances in Command Prompt (as admin) to list active filter drivers.

Variant 3: Corrupted system files

Rare, but if no driver shows up in the stack, run sfc /scannow from an elevated command prompt. Then dism /online /cleanup-image /restorehealth. This fixes system file corruption that can cause handle table corruption — though that usually manifests as other errors first.

Prevention — Stop It From Coming Back

• Keep drivers updated. Set Windows Update to automatically install driver updates, or use OEM tools like Dell Command Update or HP Support Assistant. Outdated drivers are the #1 cause.
• Avoid third-party kernel-mode software. If you don't need it, don't install it. This includes registry cleaners, system optimizers, and old-school antivirus suites. Use Windows Defender — it's good enough and doesn't hook into NtClose.
• Test updates in a VM first. If you're in an enterprise environment, stage driver updates on a test machine before rolling out broadly. One bad driver update can take down hundreds of machines.
• Monitor for handle leaks. Use tools like Process Explorer or Handle.exe from Sysinternals to spot processes with abnormally high handle counts. That's often a precursor to this crash.

Bottom line: 0xC0000235 is a driver bug, not a Windows bug. Find the driver, update or remove it, and you're done. Don't bother with registry tweaks or memory tests — they won't help here.