| Previous | Next |
| ERROR_TOO_MANY_TCBS | ERROR_DISCARDED |
ERROR_SIGNAL_REFUSED
What ERROR_SIGNAL_REFUSED means
The target process refused the signal sent by the caller. This legacy process-control result represents an explicit rejection, not inability to locate the process. The target exists but is unwilling or unable to accept the requested signal under its current state or policy.
Common causes
- The target disabled handling for that signal
- The process is shutting down or in a protected state
- The signal is not valid for the target execution mode
- A compatibility layer rejects cross-session or cross-subsystem signaling
How to investigate
- Record the target process, signal number, session, and caller identity
- Check the target state and registered handlers
- Verify the signal is supported by the target subsystem
- Test a benign signal against the same target to separate policy from state
Developer guidance
Treat refusal as a defined response. Do not escalate immediately to forceful termination; provide a timeout, alternate control channel, and clear audit logging.
Administrator and support guidance
Check whether security, session isolation, or service policy intentionally blocks the operation before changing permissions.
How this code differs from related results
ERROR_NO_SIGNAL_SENT means no eligible handler was reached; refusal means the target actively declined or could not accept the signal.
Evidence worth collecting
For ERROR_SIGNAL_REFUSED, begin the trace at the operation where the target disabled handling for that signal. Preserve the exact API boundary, numeric result, process and thread identifiers, relevant object state, and the component version. The first verification point should be to record the target process, signal number, session, and caller identity. This evidence distinguishes the specific this result contract from a later secondary failure.
Recovery and verification
Recovery for it should address the observed condition rather than merely retrying the same call. After the change, reproduce the scenario in which the target disabled handling for that signal, then confirm that the intended operation completes and that cleanup returns all associated resources. Also verify that the next repeated operation follows the same successful path without increasing the resource class implicated by this result.
When to escalate
Escalate this result with a minimal reproduction focused on the failing process-control boundary. Include the operating-system build, binary architecture, runtime or compatibility-layer version, the exact input values, and a timestamped trace showing the target disabled handling for that signal. For the result escalation record, note whether changing concurrency, object lifetime, target process, module set, or endpoint location alters the result.
References
Looking for a different code? Search another status or error code.