b26010 - ISSUE - Hyper-V remote console / auto lock won't hide window on Server Core


Repro steps:

Connect to a Hyper-V VM (without enhanced mode)

interactively login

leave the Hyper-V console window open and don't touch

user session will be "locked" due to inactivity timeout

first noticed in b26010. Reproducible in 26052.

on Server core this will cause a new cmd window but the previous one from the session (sconfig / or other) will remain visible. Depending the position this might even disclose information despite the device is locked.
Sidenode you can use the "lock screen" to erase the clipping issue in the background by moving the window.



expected behaviour:
the auto-lock should hide all other windows in the background or refresh the video output.

4 Replies

here is another example where I intentionally moved the "working window console" to the upper side of the Hyper-V console screen.

you can see the "lock screen" in the foreground, not only this causes the screen can still be read (unless you close the Hyper-V console), but also you cannot read the lock screen (logonui.exe).

So the "solution" would be to force "redrawing / freshing" the entire Hyper-V console window content when the screen lock event happens.



it seems like this is fixed in Azure Stack HCI 23H2 but it needed to be double checked if there is a difference using "extended mode" Hyper-V connection console or default one.

another example Azure Stack HCI 22H2. The session is locked (extended Hyper-V Session) and you cannot press anything but the screen is not refreshed revealing the console output as it was before the screen got auto-locked.

if you use action > ctrl-alt-delete the logon screen appears.
So the problem seems to be that the sessions screen with and without enhanced session does not receive a refresh, even if the Virtual machine Connection is an active window.



when using ctrl+alt+delete the lock screen is a different console window, depending of the original location still reveals information. I suspect that this new behaviour could be related with the change of sconfig and how it is invoked automatically? if this is the case the behaviour would be same on WS 2022 and not the same on WS 2019. Will test that.