Troubleshoot FSLogix Profile VHD File Handles Issues

Troubleshoot FSLogix Profile VHD File Handles Issues

By default, FSLogix profiles can only be accessed by one machine/user session at a time. When a user attempts to sign in to a machine while the VHDx file has a file lock/handle on it, by default FSLogix refuses to serve the user a session and presents a black screen. The error may be something like this:

ERROR:00000020 / The process cannot access the file because it is being used by another process

Most often, the file handle error is caused by one of the following scenarios.

Scenario #1: The User is Assigned to Multiple Host Pools that use the same Storage Account

While assigning users to more than one host pool is supported, a single user with multiple sessions across host pools that attach to the same FSLogix profile VHDx is not supported. For example, if host pool A and host pool B both have the same file path set for VHDLocations. In this case, user "Bob" is already logged into a session within host pool B, which is either disconnected (didn't fully sign out) or is actively being used. Bob then tries to connect to a new session for host pool A. Bob can not connect successfully because the session from host pool B is already using his profile.

To avoid this, it is recommended that users are either assigned to a single host pool, or you create separate storage accounts for each host pool. If the latter is used, it is important to note that the user profiles are separate and therefore are not synchronized. That is, the user's profile is confined to each host pool.

Scenario #2: A Stuck or Ghost Session Locks the Profile

Sometimes the AVD agent on a session host can become unresponsive. This causes the AVD Management service to become unaware of the existence of sessions on the session host. When the user "Bob" tries to sign in to AVD, the AVD service assumes this is a new session and directs them to connect to session host A, unaware that there already is an old session from the user that is holding on to the user's profile.

Because the AVD service is unaware of the unresponsive session, looking up the user's session from either Nerdio Manager or the Azure portal provides no results of existing sessions, meaning either the offending machine must be connected to and the user's session manually signed out, or for the entire VM must be restarted.

It is recommended that you use auto-scale's "Auto-Heal" functionality to prevent unresponsive hosts from remaining stuck. See Enable Dynamic Host Pool Auto-scaling for details.

Scenario #3: A User Directly Signed in to a Session Host (with FSLogix Enabled) using Traditional Remote Desktop Connection (not AVD)

This situation is common for admin users who use remote desktop to "jump box" or directly connect to session hosts.

FSLogix is used for other VDI solutions aside from AVD (Citrix, VMware, etc.). As such, FSLogix treats all RDP-based connections the same. Therefore, RDP causes an FSLogix profile to be attached. However, since the traditional remote desktop connection is not using the AVD management broker, the AVD service is unaware of this session. So when "Bob" tries to sign in, it assumes no sessions are active and it is safe to send Bob to a new session host.

Tip: If there is a need to use RDP connections for management and troubleshooting purposes, and a consistent profile is not required, it is recommended that you add the admin users to the "FSLogix Profile Exclude List" local group. Here is a command that can be used with Scripted Actions - Windows Scripts to add users to hosts, or run on the image VM:

Add-LocalGroupMember -Group "FSLogix Profile Exclude List" -Member "<Domain Group or User UPN>"

Be sure to replace <Domain Group or User UPN> with the group or username before running this script.

Find the IP of the Machine Responsible for the File Handle

Generally, file handles hold information about the source of the file lock. With all the methods below, finding the IP of the machine is possible. Then from there, referencing against VM information or IP address tables pinpoints the culprit computer.

Note: It is important to note that while you can attempt to close the file handles using these various tools, in most cases the FSLogix service in the session causing the lock attempts to reestablish the connection, causing the file to be locked again.

Find the IP for Azure Files Storage Accounts

The following methods enable you to view file handles for Azure Files storage accounts.

Method #1: Use Nerdio Manager (Recommended)

  1. Navigate to StorageAzure Files.

  2. Locate the storage account used for FSLogix.

  3. From the drop-down menu, select File Handles.

  4. Type the username that is used in the profile path.

    Note: This search queries the VHD profile file path, so keep in mind that using the full UPN of a username, for example, "", does not yield results. Try using just the SAM account name, for example, "jsmith", depending on your naming scheme.

  5. Select Close file.

Method #2: Use Azure PowerShell directly

If Nerdio Manager is unavailable to you, you can find the file handles using the Azure PowerShell module. The Get-AzStorageFileHandle cmdlet (requires Az module) can provide the necessary information.

We have provided a helpful script that uses this command.

To run the script:

  1. Download the script here.

  2. Unzip the file, and then change the file extension from .txt to .ps1.

  3. Run the script on a system that can connect to the storage account, such as a session host, and has the Az PowerShell module installed.


  • Nerdio is not responsible for the misuse of this script. Please run it at your own discretion.

  • If you are using private endpoints for the storage account containing the FSLogix file share, you need to grant the Nerdio Manager app access to that storage account. This will allow the app to look up the file handles. To learn more, see Configure Azure Storage firewalls and virtual networks | Microsoft Learn.

Was this article helpful?

0 out of 0 found this helpful
Have more questions? Submit a request

Comments (0 comments)

Please sign in to leave a comment.