Fixing ERROR_SERVER_HAS_OPEN_HANDLES (0x00000713) on Windows Server

When This Error Hits

You're on Windows Server 2019 or 2022. You try to stop a service – maybe a custom app service, a database listener, or even a built-in one like Spooler or DHCPServer. You get a popup: "The server is in use and cannot be unloaded" with error code 0x00000713. Or you're trying to unload a kernel driver via sc delete or fltmc, and same thing. The server's refusing to let go because something's got an open handle – a file, a pipe, a registry key, you name it.

Root Cause

The culprit here is almost always a handle leak in a process that's holding onto the service's or driver's resources. Common triggers:

• A third-party backup agent or antivirus that locked a file the service uses.
• A buggy service that doesn't close file handles properly after a crash.
• A user-mode process (often svchost.exe hosting the service) that's stuck in a deadlock.
• A driver that opened a device object and never closed it – common with old printer or VPN drivers.

Windows Server's Service Control Manager (SCM) won't let you unload the service until ALL open handles to its \Device\...\ objects, named pipes, or registry keys are released. That's by design – prevents data corruption. But when something holds them forever, you get 0x00000713.

The Fix – Step by Step

Skip the reboot if you can – we want to find the leak. You'll need Process Explorer or Handle.exe from Sysinternals. Both free, no install needed.

Step 1: Identify the Service or Driver

1. Open an elevated Command Prompt.
2. Run sc qc "YourServiceName" to get the exact binary path and service type. Replace YourServiceName with the service showing the error.
3. If it's a driver, note the driver name (like mydriver.sys).

Step 2: Find the Handle Leak

1. Download Handle.exe from Microsoft Sysinternals – drop it in a folder like C:\Tools.
2. Run this command:
   

   handle -a -p "YourServiceProcessName.exe" 2>&1 | findstr /i "0x00000713"

   If you don't know the process name, use tasklist /svc to see which process hosts the service.
3. If no results, search broadly:
   

   handle -a 2>&1 | findstr /i "Leak|HandleCount"

4. Look for processes with abnormally high handle counts (over 10,000 is suspicious). Common offenders: svchost.exe, lsass.exe, or your specific service host.

Step 3: Close the Handle

1. Once you identify the process and handle type (e.g., \Device\...\... or a named pipe), use Process Explorer to close it:
2. Open procexp.exe as Administrator.
3. Find the process, double-click, go to the Handles tab.
4. Sort by Type or Name. Look for anything related to your service/driver – the name usually matches part of the service's ImagePath.
5. Right-click the offending handle and select Close Handle. Confirm.
6. Immediately try stopping the service again: sc stop YourServiceName.

Step 4: Force the Service Stop (if above fails)

If closing the handle doesn't free it, the process might be hung. Use taskkill /f /pid [PID] to terminate the process (if it's a user-mode service host like svchost.exe, be careful – you might kill other services). For a driver, you may need to:

1. Set the driver's start type to disabled: sc config DriverName start= disabled
2. Reboot the server. The driver won't load.

If It Still Fails

You've done the steps and the error persists. Here's what to check:

• Antivirus interference – temporarily disable real-time scanning. I've seen Symantec and McAfee hold handles to driver objects for hours.
• Shadow copies – if the service's files are on a volume with active VSS snapshots, VSS might hold handles. Run vssadmin list shadows and delete old ones.
• Dirty driver state – some drivers like old NDIS filters or storage miniports don't clean up. Use fltmc instances to list filter drivers and unload them: fltmc unload MyFilter.
• Last resort – if it's production and you can't reboot, schedule a maintenance window. Then reboot. You'll lose the root-cause visibility, but the server will work.

One more thing – if you're seeing this with Windows Server 2016 specifically, there's a known bug with the WMI Performance Adapter service that leaks WMI handles. Check svchost.exe -k WmiApSrv – restarting that service group often clears the leak.