A customer and I ran into an interesting issue in AVD that is quite easy to reproduce. The scenario involved a policy that prevented installation of removable devices. In Group Policy, this is found underneath Computer Configuration -> Admin Templates -> System -> Device Installation -> Device Installation Restrictions:
…which sets this registry key:
When this policy is applied in a vanilla Win11 24H2 multisession image straight out of the marketplace, all new logins experience a black screen for about 30~ seconds, and then get disconnected. The user then stays logged into the session host in a disconnected limbo state. Disconnects/reconnects do not experience it.
Of course, one would immediately think FSLogix is the culprit. The policy could certainly block virtual disks (profiles) from mounting on the session host. I originally didn’t go this route troubleshooting-wise, because this was a completely vanilla image straight out of the marketplace with ZERO FSLogix policies applied. It shouldn’t even try to mount profiles, right!?
(Post has some edits from the original here onward)
I originally went down the FSLogix route, because during my troubleshooting, uninstalling FSLogix appeared to fix the issue. I missed one thing though – my test account had actually previously logged in successfully while the policy was unapplied during my testing (shame on me for losing track of which accounts were logged in previously). This allowed the device to be successfully reutilized since another install wasn’t needed. Brent Bishop pointed me in the right direction on a LinkedIn comment. It’s actually the fact that each connection tries to install a display on the fly and FSLogix has nothing to do with it!
If you have a working session or remote PowerShell into the device, you can check the event logs for install failures using the following:
Get-WinEvent -LogName 'Microsoft-Windows-Kernel-PnP/Configuration' -MaxEvents 500 |
Where-Object { $_.Message -match 'failed|blocked|denied|install' } |
Select TimeCreated, Id, MessageYou can see the blocks happening for the IndirectDisplay drivers, for example:
10/8/2025 5:57:04 PM 430 Device SWD\RemoteDisplayEnum\RdpIdd_IndirectDisplay&SessionId_0005 requires further installation.
10/8/2025 5:57:04 PM 402 Device SWD\RemoteDisplayEnum\RdpIdd_IndirectDisplay&SessionId_0005 had its configuration blocked by policy….
So, if you still “Prevent installation of removable devices,” you can also enable the “Apply layered order of evaluation~” policy and combine that with “Allow installation of devices using drivers that match these device setup classes.” This allows for layering the allows on top with a global deny at the bottom. Add the following GUIDs:
{4d36e968-e325-11ce-bfc1-08002be10318} <- Display adapters
{4d36e96e-e325-11ce-bfc1-08002be10318} <- Monitor class
So it looks like this:
Your subsequent logins should then succeed, and you can see that reflected in the event logs, showing “was configured…” versus “blocked by policy”:
10/8/2025 6:10:55 PM 400 Device DISPLAY\Default_Monitor\1&2e5834bc&0&UID257 was configured….
10/8/2025 6:10:55 PM 400 Device DISPLAY\Default_Monitor\1&2e5834bc&0&UID256 was configured….
10/8/2025 6:10:54 PM 400 Device SWD\RemoteDisplayEnum\RdpIdd_IndirectDisplay&SessionId_0006 was configured….
This allows you to continue restricting devices while allowing the display to function as intended. Hope this helps!