We recently experienced an issue where a user could not connect to our AVD environment. This has occurred a few times in the past and sometimes support has had to restart Session Hosts to clear issues.
When they attempted to connect the session would load and immediately kick them out. At the same time, it would create a corrupt FSLogix profile disk in the Azure File Share.
Every time the user attempted to reconnect they would be sent back to the same Session Host!
This was odd as a search for the user in the Users section of the Azure Virtual Desktop blade showed no connected sessions for the user.
No matter what we did the session would keep trying to connect to the same Session Host and fail every time. Even when the Session Host was set to Drain Mode.
When checking on the Session Host in question the user was showing. However, the user state was showing as Unknown.
So, I had a look directly at the Session Host.
I opened a Command Prompt and ran qwinsta to show all connected sessions.
Straight away I could see the “Unknown” session present. We can see that it is showing a state of Down
Removing Remote Session
So now I knew this was due to a stuck session, I had to go about the process of manually it to allow the user to log in to the AVD environment.
We should be able to do this with a simple logoff command
Logoff <session ID> /server:localhost /vm
This will attempt to log the session off as in the below example.
However, in our case, this failed with an Access Denied error similar to the below:
Next, I wanted to see what processes were running for this user session and see if I could understand why the logoff failed.
In cases like this, it is likely a process is failing to close and causing the session to get “stuck”
Running the query process command allows you to easily see all processes running for a specific session id.
Query process /id:4
The results of this command show a number of processes. We are mainly interested in processes running under the stuck session username.
We can see a process with PID 20820 running for this user. It is highly likely that this process is stopping the logoff from completing correctly.
So next we can try to remove the process using Taskkill
Taskkill /FI "Session eq 4" /pid 20820 /F
This command may gracefully remove the process. If so perfect.
We can now re-run the logoff command to get rid of the session!
Failed to Remove (Access Denied)
However, when we attempted to run Taskkill we received an Access Denied error like the below:
In our case, this was because our Antivirus software requires a unload password to be entered before it can be disabled (to stop the service from being tampered with.
So, to fix we had to first unload the Antivirus service for all users. With this disabled and the process terminated for all users, we could then proceed with the logoff command. Once the stuck user was removed we re-enabled the Antivirus service for all users.
If you get an access denied error against the stuck process you will need to investigate. In the worst-case scenario, you may need to restart the Session Host to clear the stuck processes. In my case, I was lucky to avoid that.