STATUS_SERVER_HAS_OPEN_HANDLES (0X80000024) fix

What's Actually Happening Here

Error 0X80000024 shows up when you try to stop a Windows service or unload a driver, but something else — a process, a kernel object, or even a pending I/O — still has an open handle to it. Windows won't yank the rug out because that'd crash the owning process or corrupt data. The server (usually the Service Control Manager, SCM, or a driver's device object) reports: "I'm busy, can't unload."

This happens most often with third-party antivirus drivers, backup software agents, or VPN adapters after they crash or fail to clean up. You'll see it in the System event log as Event ID 7034 or 7031 paired with this error code. Or you'll hit it when uninstalling a program and the installer can't stop the service.

Quick Fix: Kill the Handles with Process Explorer (30 seconds)

If you know the specific service name (say MyService), the fastest way is using Process Explorer — not Task Manager. Download it from Microsoft Sysinternals, run it as administrator.

1. Press Ctrl+F to open the Find Handle or DLL dialog.
2. Type the service or driver name (no extension, e.g., MyService not MyService.sys).
3. Hit Search. You'll see a list of processes holding handles to that object.
4. Double-click any result — it jumps to that process. Right-click the handle line, choose Close Handle.
5. Close all handles for every process listed. Then try stopping the service again from services.msc.

Why this works: You're manually releasing the reference count. Once it hits zero, the SCM can tear down the service. It's safe as long as you only close handles to the target service — closing random handles can crash other apps.

Moderate Fix: Use Handle.exe to Find and Release (5 minutes)

If you don't have Process Explorer, or you're on a headless server, handle.exe from Sysinternals does the same job from the command line. No GUI needed.

handle.exe -a -p <PID> -accepteula

Replace <PID> with the process ID that won't unload. Better yet, search for the service name directly:

handle.exe -accepteula | findstr /i "MyService"

This dumps every handle that references your service. Note the handle hex value (like 0x1234) and the PID. Then close it:

handle.exe -c 0x1234 -p <PID> -y -accepteula

The -y skips the confirmation prompt. Run this for every handle found.

The reason step 3 works: handle.exe calls NtClose directly on the handle in the target process's handle table. That decrements the kernel object's reference count. Same mechanism as closing a file handle programmatically.

Advanced Fix: Registry Cleanup and Driver Force-Unload (15+ minutes)

If the handle belongs to a kernel driver that's stuck loaded (not just a user-mode service), the above methods won't help — you need to bypass the SCM's refusal to unload. This requires a registry edit and a forced driver unload.

1. Open Regedit as administrator.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<YourDriverName>
3. Change Start from 1 (System) or 2 (Automatic) to 4 (Disabled). This prevents the driver from loading on next boot.
4. Now you need to unload it now. Use sc.exe to query its state first:

sc query <YourDriverName>

If it shows STOP_PENDING or RUNNING, try sc stop. If that fails with 0X80000024, you need to force it using the kernel debugger or a tool like fltmc (for file system filter drivers).

For filter drivers only: Run fltmc detach <DriverName> <Volume> to detach it from all volumes, then it can unload cleanly.

Last resort: reboot into Safe Mode (no networking). In Safe Mode, most third-party drivers don't load, so the handle won't exist. Then delete the driver file and remove its registry key. Reboot normally.

Why the registry change alone isn't enough: Setting Start=4 only affects loading on next boot. The driver is already loaded now. That's why you still need to unload it — but by disabling it, you buy a clean reboot path.

When to Skip All This and Just Reboot

If the service isn't mission-critical, and you don't need to keep uptime, a reboot fixes 90% of 0X80000024 errors. The handles vanish because all processes and drivers get a fresh start. But if you're on a production server or debugging a recurring leak, finding the root cause — a buggy driver, a dying backup agent — saves you repeat pain.

Check Event Viewer under Windows Logs > System for the service's crash dump path. Analyze it with WinDbg if you want to identify the specific leaked handle type. Most of the time, it's a file handle left open by a filter driver during a failed backup.