0x139F ERROR_INVALID_STATE – fix the 'not in correct state' hang

Quick answer

Restart the service or process that owns the resource (net stop service /y then net start service), or kill the handle with handle.exe -c PID from Sysinternals. If it's a Volume Shadow Copy issue, reboot.

What's actually happening

This error (0x0000139F) is the kernel's way of telling you, "I can't do that because the thing you're asking about is mid-transition." The group or resource—could be a service, a COM object, a file handle, or an SMB session—is in a state like PENDING_STOP, PENDING_START, LOCKED, or DELETED. The operation you attempted (open, close, query, control) requires a different state, usually ACTIVE or STOPPED.

I see this most often on Windows Server 2019 when trying to stop a service that's already stopping, or when a VSS writer is stuck and backup software throws the error. On workstations, it shows up when you try to modify a registry key that another process has open with KEY_NOTIFY access while a change is being applied. The key insight: the error doesn't mean the resource is broken—it means your request arrived at the wrong moment.

Fix steps

1. Identify the resource. Look at the full error message. Apps usually tell you which group or service failed. If not, check Event Viewer under Windows Logs > System. Filter by source SERVICE_CONTROL or volsnap. The event details often include the service name or volume GUID.
2. Restart the dependent service. If you see 0x139F when accessing an SMB share, run net stop server /y then net start server. If it's a Hyper-V checkpoint failure, restart the Volume Shadow Copy service: net stop vss, net start vss. The /y flag forces dependent services to stop—don't skip it.
3. If restart fails, kill the handle. Download Sysinternals handle.exe. Run handle.exe -a -p servicename.exe to find the PID and handle number. Then forcibly close it: handle.exe -c handle_number -p PID. This is risky—you're telling the OS to release a lock that a process still thinks it owns. Only do this if you're sure the process is hung.
4. Reboot. If steps 1-3 don't work, a full reboot is your last resort. The system resets all service states, clears orphaned handles, and lets VSS writers start fresh. On a server, schedule downtime. On a workstation, just restart.

Alternative fixes if the main one fails

• Check for pending operations. Open an admin PowerShell, run Get-Service | Where-Object {$_.Status -eq 'StartPending' -or $_.Status -eq 'StopPending'}. If you see one, wait 30 seconds and try again. Some services (like Software Protection) take a while to transition.
• Disable and re-enable the device. If the error involves a hardware device (USB, network adapter), open Device Manager, find the device, right-click > Disable, wait 10 seconds, then Enable. This forces a fresh driver state.
• Use Process Explorer to close handles. Open Process Explorer (Sysinternals), find the process that owns the resource, double-click, go to the Handles tab, search for the resource name, and close the handle. Safer than handle.exe because you can see the full context.
• If it's VSS-related, run vssadmin list writers from an admin prompt. Any writer with state [1] Stable is fine. If you see [5] Waiting for completion or [8] Failed, restart the VSS and SWPRV services. If that fails, the writer's parent service (like SQL Server or Exchange) needs restarting.

Prevention tip

Don't script rapid service starts/stops in loops. If your automation restarts a service every minute, you'll hit this regularly. Add a 5-second delay between net stop and net start commands. Also, avoid opening registry handles with KEY_NOTIFY and then keeping them open while you make changes—close the handle before applying new values. For VSS writers, schedule backups with a 2-minute gap after any service restart completes. The kernel isn't being difficult—it's enforcing a contract that your operations are violating.