Reconnected RemoteApp session not showing locked session password prompt

[sberens]

The issue below was observed in v1.2.945 (x64) Windows, I'm unsure if this worked properly in a prior version, or on any other platforms.

In this example, Calculator is shared as a RemoteApp on a Windows Server 2016 Session Host, domain joined and when user sessions go idle for 10 minutes, or reconnects, re-entering their password is required.  Normally, when a session goes idle for 10 minutes, the RemoteApp session will swap to the full session showing the locked screen and the user enters their password and returns to their session. 

I'm experiencing an issue where the users session gets locked, and requires a password to return to the session, but the RemoteApp screen shows the application as if the screen isn't locked.  Blindly entering the password and hitting enter, returns to a working session, and I can interact with Calculator again.  I would expect in this scenario to get see the same behavior as being idle for 10 minutes, i.e. switching to full session showing locked screen so user can enter their password.

1. Launch Calculator from Remote Desktop app
2. Calculator launches, click 9-9-9 
3. Disable Network adapter on local machine, immediately re-enable
4. Observe Trying to reconnect popup from RemoteApp
5. RemoteApp reconnects, shows Calculator with 999
6. Try to click numbers 1-2-3
7. Observe Calculator is not responding to mouse clicks, and window cannot be moved.
   • At this time PSR labels the window Calculator (Reconnecting) (tenantName) rather than just Calculator (tenantName), but the Reconnecting popup has gone away.
8. Blindly enter the users password and press Enter
9. Calculator will flash, and sometimes resize a bit off (chopping off right side slightly) 
10. Click numbers 1-2-3 and observe value is now 999123

I'm happy to share my PSR's with Microsoft, if it'll be any help, but don't want to make them public.  If you need anything else, please reach out.

Kind regards,

Sean

[#2]

Hi @sberens , thanks for reporting the problem. I filed the following for tracking the investigation: 26365018 : Reconnected RemoteApp session not showing locked session password prompt

[#3]

Hi @sberens, are you able to reproduce the issue by running the following command inside the remote session?

rundll32.exe user32.dll LockWorkStation

Thanks in advance!

[#4]

@alvinlau Good day!

I published Command Prompt, and when running the specified command, the lock screen appears as expected.  Password entry is seen and once confirmed, I'm returned to the command prompt.

Then, attempting the same steps described in my initial write-up, Disabling and enabling the network adapter on the local machine, the same symptom is seen on with the Command Prompt window.  The remote screen seems to shift up and to the left slightly exposing black border in the right and bottom.

Clicking out off the RemoteApp and clicking it again will re-render the Title bar, showing old school themeless title bar, with (Reconnecting) in the title, and again, the window cannot be moved, minimized, or closed as none of the interface buttons work.  Blindly entering my password and hitting return will return me to a working command prompt after 3-5 seconds and the command prompt window is no longer skewed and no longer has the additional border.

If you need anything else, please let me know.

Kind regards,

Sean

[#5]

@sberens Thank you for your reply!

To help me understand the issue, I have couple more questions.

Did you wait for 10 minutes to trigger the session idle timeout before disabling the network adapter on the local machine? Did you try entering something other than the password when the RemoteApp window could not be moved, minimized, or closed?

Regards,

Alvin

[#6]

@alvinlau No waiting, at any time I can attempt the network adapter flip and see this behavior.  

Interestingly, taking your advice and trying to enter something else, it seems that the ENTER key is doing the magic and bringing the session back to usable!  I had assumed the lock screen was simply not rendering, but there must be something something else going on behind the scenes. 

Any idea how we further understand what's happening in this scenario?

Thanks for your help so far Alvin, it's really appreciated.

[#7]

Hi @sberens! Do you have the WVD side-by-side stack installed on your session host? If so, what is the version? Meanwhile, let me set up a Windows Server 2016 and see if I can reproduce the issue on my side.

Thanks,

Alvin

[#8]

@alvinlau Good day!

When running qwinsta, there's a sessionname of rdp-sxs200326004 on the two Session hosts configured for the Host pool publishing the Apps used in our scenario.

An FYI that the Server 2016 instances were deployed from the Azure portal gallery, and are not custom images, if that helps.

Thanks again, and if you need anything else, please reach out.  

Kind regards,

Sean

[#9]

Hello @sberens!

I installed the same side-by-side stack on my VM running Windows Server 2016 with all the updates installed.

I could almost reproduce the issue. When auto-reconnect was done, I saw that the title bar of the remote Command Prompt window changed to the old themeless one; However, it turned back to normal in less than a second, and without typing anything on my keyboard, mouse input started working again.

Would you mind if you create a test account on your WVD deployment and let me remote in?

Also, what is the Windows version of your local machine?

Thanks,

Alvin

[#10]

@alvinlau Good day!

Thank you for attempting to repro in your environment, and I'm glad to hear it worked as we would expect.

Unfortunately I cannot provide access to the environment as it is production, but I will try to reproduce in my sandbox and will follow up by Wednesday.

I'm running Windows 10 Pro 1909 (OS build 18363.836), and Remote Desktop v1.2.945.0 (x64).

Kind regards,

Sean

[#11]

@alvinlau Good day!

I was able to validate that my sandbox environment exhibits the same behavior as your environment.  Reconnect popup appears, then shortly after reconnecting, the window theme bounces to classic, then it returns to normal and I can interact with the App, and the UI controls (Min/Max/Close).  No key presses required!  (I also learned that the space bar will return the session to usable, in the original scenario)

I don't know that it would make a difference, but my production host pool has 2 session hosts, but my sandbox only has one.

I'll continue to troubleshoot and compare the two environments for differences, but if you have any recommendations, please don't hesitate to reach out.

Thank you again for your time.

Kind regards,

Sean

[#12]

Hi @sberens!

Thanks for trying it out in your sandbox environment.

I didn't know you had two session hosts in your production host pool. Are you seeing the same issue from both of session hosts? Have you tried connecting to your production session hosts from another local machine?

I'm thinking maybe the network connectivity between your local machine and the production host pool triggered some timing issue in the WVD Client app (msrdc.exe).

If possible, can you please collect Time Travel Trace for me to investigate?

1. Install WinDbg Preview from Microsoft Store.
2. Kill any running instance of msrdc.exe.
3. Make a RemoteApp connection to the production host pool. To make things simpler, better have only one RemoteApp window running.
4. Follow the instruction here to attach WinDbg Preview to msrdc.exe and start Time Travel recording.
5. Disable and re-enable your network adapter to reproduce the issue.
6. Wait for about 10 seconds and then press [space bar] to let the session return to stable.
7. Stop the Time Travel recording.

Since Time Travel Trace is actually a memory dump, it may contain private information. So, please do NOT share it publicly.

Regards,

Alvin