What does Windows error code 614 (ERROR_NO_CALLBACK_ACTIVE) mean?

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: A callback-return system service was invoked although the thread has no active matching callback frame.

Previous	Next
ERROR_REGISTRY_QUOTA_LIMIT	ERROR_PWD_TOO_SHORT

ERROR_NO_CALLBACK_ACTIVE

A callback return system service cannot be executed when no callback is active.

ERROR_NO_CALLBACK_ACTIVE is Windows system result 614 (0x00000266). Microsoft defines it as “A callback return system service cannot be executed when no callback is active.” The value should be captured immediately at the producing boundary because later diagnostics, cleanup, or retry code can overwrite a thread-local last-error value or collapse a richer native status.

How to classify the result

This result represents an invalid callback-return state transition. The correct interpretation depends on the thread and callback mechanism that should have established an active callback frame before the return service was invoked.

The most important boundary for it is whether the operation reached a documented final state.

Where it can appear

This result can appear in a subsystem callback crossing a user/kernel or client/server boundary.
This result can appear in compatibility code that wraps a low-level callback-return service.
It can appear in instrumentation or hooking code that disturbed callback stack discipline.

When it is found only in a log, preserve the logger, event provider, process, thread, and translation path.

Typical causes

the callback-return routine was called outside its callback.
the thread changed before the return path executed.
an exception or long jump skipped callback bookkeeping.
a hook invoked the return service twice.
stack corruption damaged the active callback state.

These causes are starting points for it, not substitutes for evidence.

Evidence to preserve

Record callback type and owner for it.
Record entry and return thread IDs for it.
Record entry and return stack pointers for it.
Record exception or hook activity between entry and exit for it.
Record crash dump or trace at the first invalid return for it.

Also retain decimal 614, hexadecimal 0x00000266, UTC time, machine build, component version, and a correlation identifier.

Recovery and retry

The recovery objective for it is to Restore balanced callback entry and return control flow; remove any second return, cross-thread handoff, or stack switch not supported by the callback contract.

This state error is deterministic. Retry cannot create the missing callback frame and can worsen corruption; stop the operation and fix the control-flow defect.

Difference from related results

It is not the same as a user APC not running. It specifically rejects a callback-return service because no matching callback is active.

Keep the original constant in telemetry rather than replacing it with a nearby result that seems more familiar.

Practical validation scenario

A hook catches an exception inside a subsystem callback and directly invokes the callback-return helper after the normal unwinder has already removed the frame. A debugger breakpoint shows the second return and identifies the hook.

A useful test report for it includes the failing call, exact input, state before the call, raw output, expected state, and observed state after recovery.

Telemetry and support fields

Record no_callback_active_operation for the producing API, callback, wait, driver, packaging phase, or service transition.
Record no_callback_active_target for the stable session, selector, device, pin, content, resource, service, or validation identity.
Record no_callback_active_state_before and no_callback_active_requested_state using explicit units and enum names.
Record no_callback_active_raw_status, the original result domain, and any later HRESULT or Win32 conversion.
Record no_callback_active_attempt, elapsed time, process and thread IDs, server or device instance, and correlation ID.

Alerting for it should reflect the classification above.

Developer and administrator guidance

Treat this value as a programming or corruption signal, not a transient service outage. Production telemetry should capture a dump or at least a stack hash on the first occurrence.

Developers should preserve it at module boundaries and document whether ownership of buffers, handles, mutexes, callbacks, or transition contexts changes on return.

References

Looking for a different code? Search another status or error code.