RDP Disconnect, Sign Out, and Restart: What Happens to Applications?

If you want an application to keep running on a remote Windows computer, disconnect from RDP when you leave. Disconnecting normally keeps your Windows session and its applications running. Signing out closes the applications in that session. Restarting the computer stops running processes across the machine.

That answers what each action does immediately. For an overnight job, you also need to know whether a policy will log you off later and whether the application can keep working without an attached desktop.

What each action changes

RDP gives you access to a Windows session on the remote computer. Your RDP client, that session, and the application's own progress are separate things.

Microsoft's disconnect command documentation describes reconnecting to a retained session with its applications still running. Its RDS logoff documentation confirms that logoff ends the user session and closes its applications.

A service running outside your desktop session has a different lifecycle: signing out of your account does not, by itself, stop that service. A machine restart still interrupts it. Check which process actually performs the work; an application's window may only control a separate background component.

Illustrative comparison. Keeping a session open does not prove that its application is healthy.

Disconnect when you want to leave work running

Use the RDP client's disconnect action. In the classic Windows Remote Desktop Connection client, closing the connection window normally disconnects it. Read any confirmation message, especially if you use a different client or a provider's web console. Choose an action that explicitly disconnects the connection.

Inside an RDS session, Windows also provides:

1tsdiscon

This disconnects the current session when used without arguments. Run it only when you intend to lose the connection, and make sure you know how to reconnect. Microsoft's documentation notes that the console session cannot be disconnected with this command.

Save editable documents before leaving, even when you plan to disconnect. A later crash, logoff, or restart can still interrupt the work.

Check the policies that can close a session later

Ask the administrator for the effective settings under Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits.

These settings can appear under Computer Configuration and User Configuration; computer settings take precedence when both are configured. Microsoft documents these behaviors in its TerminalServer policy reference.

Ask for the resulting policy on your host. An unset local option is not enough to establish the effective limit in a centrally managed environment. Record the approved limits before choosing how long to test.

Test whether the application keeps making progress

Use a harmless test workload and an account authorized for that host. Avoid real customer actions or other work that would be costly to repeat.

1. Record the host, account, current application state, and a progress marker such as an output timestamp or completed-item count.
2. Where permitted, run query user on the remote host and record your session ID and logon time.
3. Disconnect through the supported client action.
4. Wait for a useful test interval within the administrator's rules, then reconnect to the same host and account.
5. Compare the session details and application output. Confirm that work advanced while you were disconnected.

The read-only query user command reports session IDs, active or disconnected state, idle time, and logon time. Microsoft lists permission requirements for using it. If access is denied, ask the administrator to inspect the session.

A window that reappears proves very little about progress. Check fresh output or application logs. If you reconnect to a different session, investigate the connection route and session assignment before starting another copy of the workload.

A short test covers only that interval. An overnight workload needs a test that accounts for the relevant session limits and planned maintenance.

Prepare for sign-out and unattended operation

Before signing out, save your work and stop tasks through the application's supported procedure. Treat unsaved desktop state as something you can lose when the session closes.

For work that must run when nobody is logged on, check whether the vendor supports a Windows service, a command-line worker, or a scheduled task. Microsoft's service guidance explains that services cannot directly interact with users on modern Windows. A desktop application that expects dialogs or user input needs a compatible background mode.

Task Scheduler also distinguishes interactive and noninteractive logon types. An interactive-token task requires the user to be logged on; other supported logon types have different credential and access requirements. See Microsoft's task logon types and task security contexts.

Choosing “Run whether user is logged on or not” does not establish that a GUI application supports unattended execution. Verify the vendor's deployment instructions, account permissions, required resources, and logging. Check compatibility and security before using a service wrapper.

Test restart recovery separately

A restart ends the current processes. Reopening the same program afterward creates a new process; continuing the previous job depends on saved state and the application's recovery features.

Plan a maintenance window, confirm backups and recovery access, and agree who may restart a shared server. Then:

1. Save a checkpoint and record the last completed work.
2. Confirm the intended startup method, account, and dependencies. Establish whether startup occurs at boot or requires user logon.
3. Perform the approved restart.
4. For a workload intended to run before login, check its logs or health signal before reconnecting through RDP.
5. Confirm fresh output, required external connections, and recovery from the expected checkpoint. Check for duplicate instances or repeated work before resuming normal operation.

Illustrative recovery sequence. If the application needs a user logon, document that dependency and test it explicitly.

Keep restart recovery and crash recovery as separate checks. A startup mechanism may launch the program at boot without detecting a later application failure. Decide what will detect a stalled workload and whether retrying it requires reconciliation first.

When an application stops unexpectedly

Record the last successful output, disconnect time, and any subsequent logon or maintenance. Use that timeline to separate the likely causes:

These are diagnostic starting points, not proof of a cause. Microsoft's RDS connectivity troubleshooting guidance helps investigate connection failures; the application vendor's logs and guidance explain workload-specific failures.

Write down the tested exit method, effective session limits, startup procedure, and recovery checks. For a desktop job that should continue after you leave, start with a controlled disconnect test and verify actual progress before relying on it unattended.

Technical guidance checked against Microsoft documentation on 3 October 2026. The RDP, policy, sign-out, and restart procedures were not executed on a live host. Images are a generated cover and original explanatory diagrams.