| Previous | Next |
| ERROR_AUDIT_FAILED | ERROR_INSUFFICIENT_LOGON_INFO |
ERROR_TIMER_RESOLUTION_NOT_SET
What ERROR_TIMER_RESOLUTION_NOT_SET means
Windows tracks timer-resolution requests so that a component can balance each request with a corresponding release. This code indicates unbalanced lifetime management or use of a timer configuration that is not active for the caller.
Where it commonly appears
- Multimedia and low-latency applications
- Timing libraries that wrap system timer APIs
- Cleanup after partial startup
- Processes with several modules requesting different resolutions
Likely causes
- The release path ran even though the set operation failed
- A resolution was released twice
- Different modules do not share ownership consistently
- Shutdown occurred on a different object instance than startup
Diagnostic checklist
- Log every successful timer-resolution acquisition and release with the requested value
- Check process startup and failure paths for unbalanced cleanup
- Verify whether libraries independently change timer resolution
- Reproduce with one owner and one explicit lifetime scope
Guidance for developers
Use RAII or another ownership mechanism so only a successful acquisition creates a releasable token. Do not globally change timer resolution for the lifetime of a process unless necessary; higher resolution can increase power consumption and wakeups.
Guidance for administrators
This usually requires an application fix rather than a system configuration change. Restarting the process clears its requests, but recurring events should be reported with application logs.
Example incident
An audio engine calls its cleanup routine after device initialization fails before the timer request is made. The unconditional cleanup tries to release the resolution and receives this code. Tracking acquisition success eliminates the false cleanup error.
Related conditions
The status is about request bookkeeping, not clock drift or a defective hardware timer. Timing accuracy problems require different diagnostics.
Operational decision points
Before retrying, the responder should classify the incident as a timer ownership condition and not merely a transient API failure. For ERROR_TIMER_RESOLUTION_NOT_SET, the deciding evidence is requested resolution, confirmed acquisitions, releases, module owner, shutdown order. Preserving this first-occurrence evidence is more useful than increasing retry frequency for investigation sequence 23.
- Impact boundary: identify the exact process, account, device, file, session, host, or connection affected by this result; do not assume the whole machine is in the same state.
- State change required: the next attempt is justified only after the relevant timer ownership state can differ from the failed attempt.
- Partial outcome: verify whether the operation allocated resources, changed data, sent a request, or modified policy before this result was returned.
- Escalation evidence: preserve requested resolution, confirmed acquisitions, releases, module owner, shutdown order together with component version and the first preceding failure.
Concrete recovery example
Consider a case where cleanup released a timer request that startup never acquired. Repeating the same call leaves the underlying condition unchanged and produces another this result. The durable response is to balance only successful acquisitions through explicit ownership. Validation for it should use one controlled operation and inspect both the returned status and the resulting state associated with case 23.
Monitoring and validation
A monitoring rule for it should distinguish first occurrence from repetition, group events by affected object, and correlate them with deployments or configuration changes. The recovery is complete only when the expected timer ownership state is present and consistent; absence of another log line by itself is not sufficient proof.
Retain the original this result event until validation for investigation case 23 is complete. After it is corrected, verify that no partial or stale artifact specific to remediation sequence 23 remains before declaring recovery complete. This it-specific verification prevents a hidden secondary problem from surviving after remediation step 23.
References
Looking for a different code? Search another status or error code.