Fixing ERROR_SERVICE_DEPENDENCY_DELETED (0x00000433)

1. Orphaned dependency from a failed uninstall or upgrade

This is the one I see most often. You or someone on your team installed a piece of software—maybe SQL Server, maybe an older version of IIS—and then uninstalled it badly. The parent service (say MSSQL$SQLEXPRESS) is gone, but the service that depended on it (like a backup agent or a custom app) still lists it in its dependency tree. When you try to start that service, Windows throws 0x00000433.

Here’s how to nail it:

1. Open an elevated Command Prompt (Run as Administrator).
2. Run sc query yourservicename to see the current state and dependencies.
3. Then run sc qc yourservicename — look at the DEPENDENCIES line. You might see something like MSSQL$SQLEXPRESS or HTTPFilter.
4. If that dependency service is no longer installed (check with sc query missingdependencyservicename), you need to remove it from the parent service’s list.
5. Use sc config yourservicename depend= / — note the space after depend=. This wipes all dependencies. If you need to keep others, use sc config yourservicename depend= service1/service2 with a slash separator, omitting the broken one.
6. Reboot or restart the service.

I’ve seen this exact scenario on Windows Server 2019 when someone uninstalled SQL Server 2017 but left a Veeam backup service referencing it. Two minutes to fix once you know where to look.

2. Service marked for deletion but still referenced

This one’s trickier. Another service holds a handle to the dependency service, and while it’s closing, Windows flags the dependency as "marked for deletion." The parent service can’t start until that handle is released. Usually happens during a reboot or service restart storm—like patching cycles.

The fix:

1. Identify the service that’s stuck. Run sc queryex type= service state= all | find /i "0x00000433" — this lists all services in error state.
2. Look at the dependencies with sc qc thestuckervice.
3. Then run sc queryex thedependencyname — if its state is STOP_PENDING or DELETE_PENDING, you’ve found the problem.
4. Kill whatever process is holding the handle. Use tasklist /m or Process Explorer to find the PID. If it’s svchost.exe, note the PID.
5. From an admin prompt: taskkill /f /pid 1234 (replace 1234).
6. Then restart the stuck service.

On a Server 2022 box running Microsoft Deployment Toolkit, I once had a phantom WDS service ghosting around. Killing the svchost hosting it cleared the error instantly. Reboot afterward to be safe.

3. Corrupted service dependency registry entry

Less common, but when it hits, it’s a mess. The registry key for the service’s dependencies has a bogus entry—maybe a typo, maybe a leftover from a half-baked install. The service can’t resolve the name, so it fails with 0x00000433.

1. Open Regedit and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\yourservicename.
2. Look for the DependOnService MULTI_SZ value. Export that key first (right-click > Export) as a backup—trust me, you’ll thank yourself.
3. Double-click DependOnService. You’ll see one or more service names, each on its own line. Delete the ones that don’t exist. To check if a service exists: run sc query servicename from an admin command prompt.
4. Click OK, close Regedit, and restart the service.

One time I found a leftover RpcSs misspelled as RpcSvc — someone’s fat fingers. Took 10 minutes of head-scratching before I thought to check the registry directly. Don’t skip the backup.

If none of these work—and I know this error is infuriating—check if your service is trying to start too early during boot. Try setting it to Automatic (Delayed Start) in services.msc. Sometimes a slow dependency just hasn’t fully loaded.