Fix ERROR_SERVICE_MARKED_FOR_DELETE 0x00000430

When you see this error

You try to net start MyService or sc stop MyService in an admin command prompt. Windows throws back ERROR_SERVICE_MARKED_FOR_DELETE (0x00000430). The service won't start, won't stop, won't change configuration. It's stuck in a kind of limbo.

Real-world trigger: you installed a third-party driver or agent (like a VPN client, antivirus, or a monitoring tool), uninstalled it, rebooted, but the service entry lingers. Or you wrote a script that deleted a service while it was still running. Or a poorly behaved installer called DeleteService without first closing all open handles.

What's actually happening here

The Windows Service Control Manager (SCM) received a DeleteService call for that service. It immediately marks the service record as pending deletion. But the actual deletion only happens when every open handle to that service is closed. The SCM won't let you start or stop a service marked for delete. It won't even let you re-delete it. The service entry is a zombie.

Why does this happen? The SCM's internal state machine is conservative. If it deleted the record while something still held a handle, that handle could later send a control command (like StartService) to a dead entry. That'd crash the SCM or corrupt its database. So it waits. Indefinitely.

The fix: find and close the phantom handle

Identify the service name
Open an admin command prompt. Run sc queryex | find /i "YOURSERVICE". Look for SERVICE_NAME. Note the exact name. Also note the PID column – if it shows a PID, the service is still loaded in a process (probably svchost.exe). If PID is 0, you're dealing with a pure handle leak from another process.
Find which process holds the handle
Download Sysinternals Handle. Run:
```
handle.exe -a -p *scmanager* 2>nul | findstr /i "YOURSERVICE"
```
If that returns nothing, run the broader scan:
```
handle.exe -a 2>nul | findstr /i "YOURSERVICE"
```
This scans every running process for any handle whose name contains your service name. The output shows pid: 1234 – that's your culprit.
Kill the owning process (or restart it)
If the process is something like svchost.exe hosting multiple services, don't blindly kill it – you'll knock out other services. Instead, open Task Manager, go to Details tab, find the PID, right-click and select End process tree if you're sure it's safe. For svchost.exe with a specific service, run:
```
sc stop <OtherServiceInSameHost>   # drain the host first
```
Then taskkill /f /pid <PID>. The handle closes on process exit, and the SCM deletes the service.
If killing fails, reboot
This is the nuclear option but it works every time. All handles are released on reboot. The SCM cleans up the pending deletion during startup. After reboot, run sc query YOURSERVICE – it should return 1060 (service does not exist) or be gone from services.msc.
If the service still shows up after reboot
Then you have a driver-level service (not a Win32 service). Drivers can't be deleted while loaded. Uninstall the driver properly via devcon or the original installer. Or run sc delete YOURSERVICE with the system in Safe Mode – that prevents the driver from loading.

What to check if it still fails

You didn't find any PID with handle.exe: The handle might be held by a system process (System, PID 4) or a protected process like csrss.exe. These can't be killed. You must reboot.
You're dealing with a PNP driver: Check sc queryex type= driver. If the driver is marked for delete, the only clean fix is to uninstall the device or driver package via Device Manager (View > Show hidden devices, find the ghost device, uninstall).
The service belongs to a Windows component (like WMI or WinRM): Don't delete it. Instead, fix whatever corrupted its state. Run sfc /scannow or DISM /Online /Cleanup-Image /RestoreHealth. Then reboot.
Nothing works and you're desperate: regedit to HKLM\SYSTEM\CurrentControlSet\Services\YOURSERVICE and delete the entire key. This bypasses the SCM entirely. Back up the key first – export it. Then reboot. The registry entry disappears, and the SCM won't see it anymore. Only do this for services you're certain are orphaned.

The root cause is always the same: an open handle the SCM can't force-close. The fix is to close that handle, directly or indirectly. Rebooting is the simplest way to close all handles. Handle.exe is the surgical tool for when you can't reboot.