What STATUS_KEY_DELETED Actually Means
You're seeing 0xC000017C — STATUS_KEY_DELETED. Translation: some process tried to open, read, or write a registry key that Windows has already queued up for deletion. The key still shows up in Regedit, but its internal state says "this is gone, don't touch it." Any handle or API call against it fails hard.
I hit this most often on machines where the user uninstalled a piece of software while it was still running. Last month a client's Sage 50 install left a service behind, the uninstaller deleted its registry hive, and the orphaned service kept poking at keys that no longer existed. Event log was lit up with 0xC000017C every 30 seconds.
The error is not fatal to Windows itself. It's a per-process problem, and how you fix it depends on what's holding the handle.
Cause 1: A Service or Process Still Holds a Handle to the Deleted Key
This is the number one culprit. When you call RegDeleteKey, Windows doesn't delete the key immediately if another thread has it open. It marks the key for deletion and waits. Until the last handle closes, the key sits in limbo. Anyone else touching it gets STATUS_KEY_DELETED.
The Fix
Find who's holding the handle, then restart or kill that process.
- Open Task Manager as admin (Ctrl+Shift+Esc, then More details if needed).
- Look for the app or service that's logging the error. If it's a service, open
services.mscand find the matching service. - Stop the service, or kill the process tree. Just restarting the app usually isn't enough because the parent process still holds the handle.
- Once stopped, reboot. The pending deletion completes on the next boot cycle.
If you can't tell which process it is, use Process Explorer from Sysinternals. Turn on View → Show Lower Pane, then Lower Pane View → Handles. Search the handle list for Key and look for your orphaned path. Right-click the process, choose Kill Process Tree.
Real talk: rebooting fixes this in 80% of cases. If the error survives a clean reboot, a service is set to auto-start and touching the key on boot. Schedule it to Disabled, reboot again, then decide if you actually need that service.
Cause 2: Buggy Uninstaller Leaving the Machine Half-Clean
Cheap uninstallers — looking at you, older versions of McAfee and some HP printer bloat — call delete on a key, then immediately try to write a log entry or update a sibling key under the same parent. That second call fails with 0xC000017C because the parent is already pending deletion. You see this in Add/Remove Programs: the app is gone, but its entries linger and the installer throws an error on reinstall.
The Fix
Clean up the orphaned keys manually, then rerun the install.
- Back up first:
reg export HKLM\SOFTWARE\YourVendor C:\backup.reg - Open
regedit.exeas admin. - Navigate to the vendor's leftover key. Common spots:
HKLM\SOFTWARE\,HKLM\SOFTWARE\WOW6432Node\,HKCU\SOFTWARE\, andHKLM\SYSTEM\CurrentControlSet\Services\. - Right-click the whole vendor folder and Delete. Don't try to delete children one by one — that's exactly what triggers the error in the first place.
- Reboot, then reinstall the app.
If Regedit refuses to delete and throws its own error, the key is genuinely locked. See Cause 1. If it deletes but the error returns after reinstall, the installer itself is broken — grab the latest version from the vendor, don't use the one on the old CD.
Cause 3: Antivirus or Backup Software Scanning a Transient Key
Third most common on my bench. Real-time scanners and backup agents enumerate the registry constantly. When a legitimate uninstall or update is mid-flight, the scanner catches the key in its pending-delete state and logs 0xC000017C. The error is harmless noise, but it floods the event log and scares people.
The Fix
Verify it's actually benign before you change anything.
- Open Event Viewer (
eventvwr.msc) and filter by the source logging the error. - Check the timestamp. If it lines up with a Windows Update, driver install, or app update, it's the scanner catching a transient state. Ignore it.
- If it's happening constantly and there's no install activity, add the vendor's registry path to your AV exclusion list. In Microsoft Defender: Virus & threat protection → Manage settings → Add or remove exclusions → Add → Process, then pick the process doing the churn.
- For backup tools like older Veeam or Acronis agents, update to the current build. Most shipped a patch for this exact enumeration bug.
When It's Not a Software Bug: Developer Causes
If you're writing code and hitting this, the answer is simpler. RegDeleteKeyEx and RegDeleteTree mark keys for deletion immediately. Any further RegOpenKeyEx against that key or its children returns STATUS_KEY_DELETED. Stop doing that.
Correct pattern:
// Close all handles BEFORE deleting
RegCloseKey(hChild);
RegCloseKey(hParent);
// Then delete
RegDeleteTree(HKEY_LOCAL_MACHINE, L"SOFTWARE\\YourVendor");
// Do NOT reopen or query the key afterward
If you need to verify deletion, do it after a short delay and expect ERROR_FILE_NOT_FOUND, not success. The pending state can last until the last handle in the system closes, which is sometimes milliseconds, sometimes until reboot if another process latched on.
Quick Reference
| Symptom | Likely Cause | Fix |
|---|---|---|
| Error repeats every few seconds from one process | Service holding handle to pending-delete key | Stop service, reboot; disable auto-start if it returns |
| App won't reinstall, error during setup | Buggy uninstaller left orphaned keys | Manually delete vendor key in regedit, reboot, reinstall |
| Error only during updates or installs | AV or backup scanner enumerating transient keys | Add process exclusion; update backup agent |
| Error in your own code path | Reopening a key after RegDeleteKeyEx | Close handles, delete once, never reopen |
Nine times out of ten, a reboot clears it. The tenth time, you've got a service or scanner that needs to be told to stop. Back up the registry before you start deleting anything by hand — one wrong click in regedit and you'll be reinstalling Windows instead of fixing a registry error.