File Explorer Not Responding - Mapped Network Drive to Deleted Azure File Share Freezes and Prevents logins for All Users in Win 10 Multi-session

Question

I'm posting this to make other community members aware of the issue until File/Windows Explorer can be patched.

This does look like a bug with Windows/File Explorer that will cause instability in an AVD environment for all users on the session host. This would be a smaller issue if it didn’t impact all AVD users on the system. In this case, the issue prevents logins, applications from opening, and locks up the session host for 6 minutes every time file explorer is opened when a user has a mapped drive to an Azure File share that has been deleted.

Description of issue:
In an AVD Windows 10 multi-session desktop, if a mapped network drive to an Azure File Share exists in a user profile. Then the Azure file share is deleted. The mapped drive will then cause instability for ALL AVD Desktop users in the Windows 10 multi-user session. When File/Windows Explorer is opened in a user profile with the mapped drive to an Azure File share that no longer exists, File/Windows explorer will become unresponsive for approximately 6 minutes. During those 6 minutes, other AVD Desktop users will not be able to log in or use applications inside their AVD Remote session. This issue only impacts users if they are using the AVD Desktop or HTML5 clients to log in to the multi-session host. Standard Remote Desktop test users were not impacted.

Build Test Environment
-Full Azure Virtual Desktop setup, with domain controller VM
-Azure File Share
-FSLogix Deployed
-3 Test accounts (A, B, C)

After the test environment is configured and users can log in. Follow these steps to replicate the issue:

Step 1: Create an Azure File share and allow User A to access
Step 2: Login as User A and Map a network drive to the Azure File share. Verify the mapped drive to the Azure File share is available and you can create a file inside it.
Step 3: Log Out User A.
Step 4: Delete Azure File Share.
Step 5: Login as User A and verify File Explorer Locks Up for approximately 6 minutes before displaying the mapped drive is not available.
Step 6: Login using AVD Desktop Client with User B, while User A has the session locked up. (Login will hang until File Explorer is responsive)
--- If User B is logged in while User A uses File Explorer. User B will not be able to use File Explorer or other applications until File Explorer clears up in User A's session.
Step 7: Login using Standard Remote Desktop with User C while User A has the session Locked up. (User C will be able to log in and work normally with all applications)

Findings:

• Approximately for 6 Minutes File/Windows Explorer Locks up the Windows 10 Multi-session host for AVD Client users only.
• No AVD desktop client or HTML5 Web users can log in or open applications from their desktop while the Windows Explorer is Not Responding.
• This does not impact Standard Remote Desktop Session or Users Logged into the system.
• FSLogix Excluded users also have these issues. FSlogix can be ruled out.
• If you only remove RBAC permissions to the Azure File Share, the drive mapping will go away inside the user’s profile. Deleting the file share causes the issue.
• Windows/File Explorer doesn't seem to have the proper protocols to handle this situation, and the impact on the environment is severe.

Answer 1

For the following works: boot into safe mode, enter cmd and use net use * /delete