What does Windows error code 240 (ERROR_VC_DISCONNECTED) mean?

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: The virtual-circuit session was canceled or disconnected before the operation completed.

Could be also:
Constant	Type	OS
STORAGE_MINIPORT_ERROR	BugCheck Code	Windows

Previous	Next
ERROR_NO_WORK_DONE	ERROR_INVALID_EA_NAME

ERROR_VC_DISCONNECTED

The session was canceled.

ERROR_VC_DISCONNECTED is Windows system result 240 (0x000000F0). Microsoft defines it as “The session was canceled.” 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 a canceled or disconnected session. The correct interpretation depends on the connection-oriented transport, redirector, provider, or legacy subsystem that owned the virtual circuit at the moment of cancellation.

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 legacy network provider or redirector operation.
This result can appear in a session-oriented RPC, terminal, or device-management channel that maps its native status to Win32.
It can appear in a long-running request whose underlying connection is closed by either endpoint.

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

Typical causes

the remote endpoint deliberately canceled the session.
a service restart or failover invalidated an established channel.
idle timeout, keepalive policy, or intermediate network equipment removed the state.
the caller reused a handle after disconnect notification.
a lower-level transport error was translated to the generic virtual-circuit result.

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

Evidence to preserve

Record local and remote endpoint addresses for it.
Record session, connection, or handle identifier for it.
Record first lower-level transport status for it.
Record bytes or protocol phase completed before disconnect for it.
Record service restart, failover, and timeout events for it.

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

Recovery and retry

The recovery objective for it is to Create a new session after the owning provider is ready, then repeat only the smallest operation whose completion is known to be absent.

A bounded reconnect is reasonable for transient transport loss; an immediate loop on the same canceled handle is not. Mutating requests require an application-level completion check first.

Difference from related results

It denotes loss or cancellation of a session. ERROR_CONNECTION_ABORTED and ERROR_REQUEST_ABORTED can describe different layers and should not be substituted without preserving the original code.

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

Practical validation scenario

A management agent sends a request, the remote service restarts, and the next receive returns it. The agent records the session ID, opens a new channel, queries whether the requested change committed, and only then decides whether to resend.

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 vc_disconnected_operation for the producing API, callback, wait, driver, packaging phase, or service transition.
Record vc_disconnected_target for the stable session, selector, device, pin, content, resource, service, or validation identity.
Record vc_disconnected_state_before and vc_disconnected_requested_state using explicit units and enum names.
Record vc_disconnected_raw_status, the original result domain, and any later HRESULT or Win32 conversion.
Record vc_disconnected_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

Client code should separate reconnection from request retry and expose the original provider status. Operators should inspect both endpoints before blaming DNS or credentials, because an established session already existed.

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.