Azure Virtual Desktop: RemoteApp Sessions Not Disconnecting

Question

Azure Virtual Desktop: RemoteApp Sessions Not Disconnecting

Katie-0688 0

Problem description

I am experiencing an issue with my Azure Virtual Desktop environment where RemoteApp sessions do not disconnect as expected. Specifically, when users close published applications like ArcGIS or FME Workbench, the application windows close, but the user sessions on the session host do not transition to 'Disconnected'. Instead, they remain in the 'Active' state, preventing the automatic logoff behavior that is supposed to occur when sessions are disconnected.

Environment

Azure Virtual Desktop host pool publishing RemoteApps, using T4 GPU-based VMs, affecting Windows 10 and Windows 11 session hosts, located in an unspecified region.

What I've already tried

I have updated the affected session hosts to the latest updates, including Windows and the Azure Virtual Desktop agent. I also updated Windows App to the latest version. I verified that the published application processes are fully closed after exit, and I compared behaviors under different exit conditions, such as shutting down the client device or logging out, which do result in session disconnection. Additionally, I confirmed that the issue is limited to one host pool and does not occur in others. No error messages or codes have been reported, and no changes to session timeout policies or scaling plans seem to influence the behavior.

Current status

I am seeking guidance on identifying why sessions remain active after closing RemoteApps and how to ensure they transition to 'Disconnected' to trigger automatic logoff. Any suggestions on troubleshooting steps or configuration adjustments to resolve this issue would be appreciated.

Stefan Claassen 0 Reputation points

2026-11-06T05:04:19.42+00:00

Hi,

The session closes based on windows, not on your app's process. When all active application windows and all user-launched notification area icons are closed, the session remains active for 20 more seconds. If another application or system tray icon isn't launched within that time, the RDP session is disconnected.

So ArcGIS and FME can exit cleanly, and the session still stays Active. Something else in the user's session is holding a window or a tray icon. It could also be a child process. If the specified program spawns a new process, that new process is considered part of the program and the session will not terminate until that process also terminates. Microsoft's documented example is splwow64.exe after printing from a 32-bit app.

That fits your symptoms. Logging off or shutting down the client forces a disconnect. Closing the app does not.

Find the process that is holding the session

Close the RemoteApp, wait 30 seconds, then run this on the session host as admin:

$user = 'jdoe' # affected user

$sid = (quser $user 2>$null | Select-Object -Skip 1) -replace '\s{2,}',',' |

ForEach-Object { ($_ -split ',')[2] }

Get-Process -IncludeUserName | Where-Object SessionId -eq $sid |

Select-Object Name, Id, MainWindowTitle, Path |

Sort-Object Name | Format-Table -AutoSize

Compare the output with the same user on a host pool that works. Watch for processes that have a window title or a tray icon. Likely candidates:

ArcGIS licensing or notifier processes

An FME tray helper

The NVIDIA control panel or container processes (only your T4 pool has these)

OneDrive, Teams, or security agent UI

splwow64.exe

The issue only affects one host pool. That suggests software on that image, not AVD itself. The NVIDIA GPU driver stack is the clearest difference. I cannot confirm it from documentation, so treat it as something to test, not the cause.

Fixes, once you know the process

If it is a background helper that is safe to kill, add it to the Sysprocs list. You can add the process to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Sysprocs to tell the operating system that the process may be safely terminated automatically, as a REG_DWORD with value data 0. Test it on one host first.

If it is a startup or tray app, stop it from launching in RemoteApp sessions. Use a Run key cleanup, startup task removal, or app config.

After that works, check that your disconnected-session limit is set. The RDS policy "Set time limit for logoff of RemoteApp sessions" logs users off after a RemoteApp session disconnects. Neither setting helps while the session is still Active.

Send me the process list from one affected session and I will tell you which entry to fix.

Sources:

https://learn.microsoft.com/troubleshoot/windows-server/remote/remoteapp-sessions-disconnected

https://learn.microsoft.com/troubleshoot/windows-server/remote/rd-or-remoteapp-session-not-terminate
Hemant Bharadwaj 370 Reputation points Microsoft Employee

2026-11-06T09:09:52.32+00:00
Good isolation so far. Since app processes exit but sessions remain active, this is usually a session-lifecycle or agent-side timeout policy issue rather than an app crash issue.

Validate host pool session timeout and disconnect policy settings.

Check whether disconnected/idle session limits are applied at host pool level and via group policy/Intune baseline on session hosts.

Confirm there is no conflicting policy that keeps disconnected sessions alive indefinitely.

Verify RemoteApp close behavior and shell/session process handling.

In AVD diagnostics, confirm whether the session host receives app-exit and user-logoff/disconnect events consistently.

Compare a normal app close vs forced client close to see whether the broker receives disconnect events in both paths.

Review agent/version consistency across affected hosts.

Ensure AVD agent and bootloader are current and consistent on all hosts in the pool.

If behavior differs by host, drain one host and retest with a single known-good host to isolate host-specific state.

Scale/maintenance mitigation while root cause is investigated.

Use session timeout/disconnect policy as temporary protection so stale sessions do not block capacity.

References:

https://learn.microsoft.com/azure/virtual-desktop/troubleshoot-user-session-issues

https://learn.microsoft.com/azure/virtual-desktop/rdp-properties

https://learn.microsoft.com/azure/virtual-desktop/troubleshoot-agent

“If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”

1 answer

Your answer

Hemant Bharadwaj 370 Reputation points Microsoft Employee

2026-11-06T09:09:52.32+00:00

Good isolation so far. Since app processes exit but sessions remain active, this is usually a session-lifecycle or agent-side timeout policy issue rather than an app crash issue.

Validate host pool session timeout and disconnect policy settings.

Check whether disconnected/idle session limits are applied at host pool level and via group policy/Intune baseline on session hosts.

Confirm there is no conflicting policy that keeps disconnected sessions alive indefinitely.

Verify RemoteApp close behavior and shell/session process handling.

In AVD diagnostics, confirm whether the session host receives app-exit and user-logoff/disconnect events consistently.

Compare a normal app close vs forced client close to see whether the broker receives disconnect events in both paths.

Review agent/version consistency across affected hosts.

Ensure AVD agent and bootloader are current and consistent on all hosts in the pool.

If behavior differs by host, drain one host and retest with a single known-good host to isolate host-specific state.

Scale/maintenance mitigation while root cause is investigated.

Use session timeout/disconnect policy as temporary protection so stale sessions do not block capacity.

References:

https://learn.microsoft.com/azure/virtual-desktop/troubleshoot-user-session-issues

https://learn.microsoft.com/azure/virtual-desktop/rdp-properties

https://learn.microsoft.com/azure/virtual-desktop/troubleshoot-agent

“If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”

Answer 1

A RemoteApp session disconnects based on open windows and tray icons, not on the app process. The docs say the session stays active for 20 seconds after the last RemoteApp window and user-launched tray icon close. If nothing else starts, it disconnects. A leftover window or tray icon in that session would keep it Active, so look for one on the affected pool.

A process spawned by the app can also hold the session open. The docs give splwow64.exe after printing from a 32-bit app as an example.

Close the RemoteApp and wait 30 seconds.
On the session host, list the processes in that user's session. Look for ones with a window or tray icon.
Compare with the same user on a working host pool.
If a background helper is safe to end automatically, add its name under HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Sysprocs as a REG_DWORD with value 0. Test on one host first.

What processes remain in the session after you close the app?

References:

If this solved it, please click Accept Answer and upvote so others with the same problem can find it.