Fix ERROR_SIGNAL_REFUSED (0x0000009C) – The recipient process refused the signal

1. The genuine fix: a hung service or driver that won't take the signal

This error almost always shows up when Windows tries to send a termination or control signal to a process, and that process just says "nope." I've seen it most often with:

• Service Control Manager trying to stop a service that's stuck – usually after a forced reboot or update gone wrong.
• A driver that's hung during a shutdown or power state change (like trying to sleep or hibernate).
• A third-party antivirus or security tool that's locked up and won't let the system signal it.

The fastest fix: kill the stubborn process or service from an elevated command prompt. Here's the exact steps:

1. Open Command Prompt as Administrator (right-click Start, choose it).
2. Run tasklist /svc to find the PID of the culprit. Look for the process name if you know it – like avgnt.exe or svchost.exe hosting a specific service.
3. Then run taskkill /F /PID [PID number]. The /F forces termination. If it won't die, try taskkill /F /IM [processname.exe] instead.
4. If it's a service, use sc queryex [servicename] to get its PID, then kill it, then sc stop [servicename] after it's dead.

I had a client last month whose print spooler threw this error constantly. Turned out a corrupt print driver was refusing the stop signal. Killed spoolsv.exe from taskkill, deleted the rogue driver from C:\Windows\System32\spool\drivers, and the error vanished.

2. Second cause: permission problem – your user account can't signal the process

Sometimes the error isn't the process being stubborn – it's that Windows literally won't let your user account send that signal. This happens when:

• You're running a tool like kill.exe or a custom script without admin rights.
• The process is owned by SYSTEM or a different user (like a service running as LOCAL SYSTEM).
• You're trying to signal a process from a remote machine via WinRM or PowerShell, and the credentials aren't right.

Fix it: Always run your command prompt or PowerShell as Administrator. Don't just double-click – right-click and pick "Run as administrator." If you're using PowerShell, the command Start-Process powershell -Verb RunAs does it too.

For remote signals (like using Invoke-Command or Stop-Process -ComputerName), make sure you're using domain admin credentials or that the account has SeIncreaseQuotaPrivilege and SeDebugPrivilege on the remote machine. You can check those with whoami /priv.

If you're still blocked, check the local security policy: run secpol.msc, go to Local Policies > User Rights Assignment, and make sure your account or group has "Adjust memory quotas for a process" and "Debug programs." This isn't common, but I've seen it on locked-down corporate boxes.

3. Third cause: driver conflicts during sleep or shutdown

This one's sneaky. You'll get error 0x0000009C in the system log when the PC tries to go to sleep or hibernate, and a device driver refuses the power state change signal. Common culprits:

• Old Wi-Fi or Bluetooth drivers (Broadcom and Realtek are repeat offenders).
• USB hub drivers that don't handle selective suspend.
• Graphics drivers (NVIDIA and AMD have both had issues with modern standby).

Quick test: Open Event Viewer (eventvwr.msc), go to Windows Logs > System, and filter by Event ID 7030 or 7031. If you see a service marked as "hung" around the time of the error, that's your driver. Also check Microsoft-Windows-Kernel-Power event logs.

Fix it: Update the driver from the manufacturer's site (not Windows Update). If it's a network adapter, try disabling its power saving feature:

1. Open Device Manager.
2. Right-click the device (say, your Wi-Fi adapter) > Properties.
3. Go to the Power Management tab.
4. Uncheck "Allow the computer to turn off this device to save power."

If the error keeps happening on a specific driver, you can try pnputil /enum-drivers to list them, then pnputil /delete-driver [publishedname] to remove the bad one. But that's a nuclear option – only do it if you're sure which driver is the problem.

Another real scenario: a client's Dell laptop would freeze when closing the lid. System log showed 0x0000009C from the Intel serial IO driver. Updating to the latest chipset driver from Dell's site fixed it.

Quick-reference summary table

Bottom line: 0x0000009C isn't common, but it's always fixable. Start with force-killing the stuck process, check your permissions, and then look at drivers. If you're still stuck, check the Event Viewer around the exact time the error popped – that log entry will name the process or driver. Save yourself the headache I've watched others go through.