What does Windows error code 614 (ERROR_NO_CALLBACK_ACTIVE) mean?

 
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 this Win32 error 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 this Win32 error, not substitutes for evidence.

Evidence to preserve

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

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

Recovery and retry

The recovery objective for this Win32 error 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 this Win32 error 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 this Win32 error 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.