By David,
An FSLogix profile is "locked" when the user's VHDX container is still attached somewhere else, so the new sign-in can't take FSLogix's exclusive lock on it. By default FSLogix lets a container be used by one connection at a time. When the lock can't be taken, FSLogix retries, then gives up and, by default, signs the user in with a temporary profile. The fix is almost always to find what's holding the container (a disconnected session on another host, a session that didn't detach cleanly, or another process with the file open) and release it safely.
The short version: Find the user's sessions with
Get-AzWvdUserSessionand sign them out. If the container is still locked, look at the open SMB handles on that one VHDX withGet-AzStorageFileHandle, confirm nothing live is using it, then close them. Set Microsoft's recommended retry values so a locked sign-in fails fast, keep FSLogix on the current release, and don't turn on concurrent access to "fix" it: Microsoft doesn't support concurrent connections on Azure Virtual Desktop.
This guide goes deeper on one failure from our FSLogix troubleshooting guide. Everything below is from Microsoft Learn as of November 2026, with each source linked.
Why FSLogix locks the container
FSLogix attaches the user's profile container (a VHD or VHDX on your file share) when they sign in, and keeps an exclusive lock on it while they're connected. Microsoft's words: "The default configuration of FSLogix prohibits a user from using their container in more than a single connection" (container locked). That lock is what stops two sessions writing to the same disk and corrupting it.
So when a second sign-in arrives and the first session still has the container, the second one can't attach. What happens next depends on two settings:
- The retry settings decide how long FSLogix keeps trying.
- PreventLoginWithFailure decides what the user sees when it gives up. At the default of 0, the sign-in continues with a temporary local profile. At 1, FSLogix shows an error and the user can only sign out (configuration settings).
How to recognize a locked container
In the FSLogix profile log on the session host (C:\ProgramData\FSLogix\Logs\Profile), find the user's LoadProfile line for that sign-in and read the warnings and errors after it. A lock usually shows as repeated retries followed by a Windows error code such as:
| Code | Windows name | Meaning |
|---|---|---|
| 32 (0x20) | ERROR_SHARING_VIOLATION | The process cannot access the file because it is being used by another process |
| 33 (0x21) | ERROR_LOCK_VIOLATION | The process cannot access the file because another process has locked a portion of the file |
FSLogix's own documentation doesn't list these codes; it says warning and error codes "come from Windows" and correspond to System Error Codes (error codes). Our FSLogix logs and status codes reference explains how to read the rest of the log.
The user-facing symptoms are the ones you'd expect: a long "Please wait for the FSLogix Apps Services", then an empty desktop and "You've been signed in with a temporary profile", or an FSLogix error if PreventLoginWithFailure is on.
The four usual causes
- The user is still signed in on another host. They disconnected rather than signed out, then connected again and landed on a different host. The AVD broker normally reconnects users to their existing session, but not if that host is in drain mode, unavailable, or in a different host pool that points at the same share.
- A previous session didn't detach cleanly. The host crashed, was deallocated mid-session, or sign-out hung. The file share can keep the SMB handle open until it times out or someone closes it. Microsoft documents CleanupInvalidSessions for exactly this: set it to 1 under
HKLM\SOFTWARE\FSLogix\Appsand FSLogix "attempts to clean up these invalid sessions", for both profile and Office containers (configuration settings). Microsoft also asks you to fix the root cause of abrupt sign-outs rather than rely on it (container locked). - Sign-out compaction was still running. FSLogix compacts dynamic containers at sign-out. Microsoft's FAQ says that if the user reconnects while compaction is still running, the disk is in use and "under default conditions, the user is signed in with a temporary profile" (FAQ). See FSLogix profile size and compaction.
- Something else opened the file: a backup job, an antivirus scan of the share, or an administrator who mounted the VHDX to look inside it.
Step by step: release a locked FSLogix container
1. Find and end the user's sessions
Start in Azure Virtual Desktop, not on the file share. List the user's sessions in the host pool:
Get-AzWvdUserSession -ResourceGroupName "rg-avd" -HostPoolName "hp-pooled-01" |
Where-Object { $_.UserPrincipalName -eq "jdoe@contoso.com" } |
Select-Object Name, SessionState, CreateTime
If there's a Disconnected session on another host, sign it out. That detaches the container cleanly, which is always better than closing a handle:
Remove-AzWvdUserSession -ResourceGroupName "rg-avd" -HostPoolName "hp-pooled-01" `
-SessionHostName "avd-0.contoso.com" -Id 3
Check every host pool that uses the same profile share, not just this one. On a single host, qwinsta or Task Manager's Users tab shows the same thing (open file handles). The cmdlets are documented as Get-AzWvdUserSession and Remove-AzWvdUserSession.
2. Look at the open handles on the container
If the user has no session anywhere and the container is still locked, something on the share still holds it. On Azure Files, list the handles under that user's folder:
$ctx = (Get-AzStorageAccount -ResourceGroupName "rg-storage" -Name "stavdprofiles").Context
Get-AzStorageFileHandle -Context $ctx -ShareName "profiles" -Path "S-1-5-21-<...>_jdoe" -Recursive |
Sort-Object ClientIP, OpenTime
The ClientIP tells you which machine holds it. If that's a session host the user is no longer signed in to, it's a stale handle. If it's a backup server or an admin's workstation, deal with that process first. Microsoft's guidance is to identify which application is acquiring the handle before you break it (Azure Files SMB troubleshooting). The Az.Storage handle cmdlets need Az module 2.4 or later.
3. Close the stale handles, safely
Close a handle only when all of these are true: the user has no session in any host pool that uses the share, the client IP isn't a host they're working on, and nothing else (backup, antivirus, an admin) needs the file. Preview first, then run it without -WhatIf:
Close-AzStorageFileHandle -Context $ctx -ShareName "profiles" `
-Path "S-1-5-21-<...>_jdoe/Profile_jdoe.vhdx" -CloseAll -WhatIf
Closing a handle on a container that's still attached cuts the disk out from under a live session: writes in flight are lost and the VHDX can be left needing repair. That's why step 1 comes first.
Other file servers. On a Windows file server, use Computer Management → Shared Folders → Open Files → Close Open File (open file handles). On Azure NetApp Files, Microsoft says the MMC can't be used to manage sessions and open files (Azure NetApp Files SMB FAQ), so signing the user out is the dependable route there.
4. Sign the user in again and confirm
Have the user sign in. The new LoadProfile entry should end with Status 0 and Reason 0, "The container is attached", and Get-AzWvdUserSession should show one Active session.
Stop it happening again
Set the retry values Microsoft recommends. The defaults retry a locked container 12 times, 5 seconds apart, and try to reattach a dropped disk 60 times, 10 seconds apart. Microsoft's Standard configuration example sets all four lower so a failure surfaces quickly (configuration examples, settings reference):
| Setting (HKLM\SOFTWARE\FSLogix\Profiles) | Default | Standard example |
|---|---|---|
| LockedRetryCount | 12 | 3 |
| LockedRetryInterval (seconds) | 5 | 15 |
| ReAttachRetryCount | 60 | 3 |
| ReAttachIntervalSeconds | 10 | 15 |
Keep FSLogix current. Microsoft says customers "are required to install and use the latest version", and recent releases fixed exactly this class of problem. FSLogix 26.08 (3.26.826.17182, August 2026) "fixed an issue where a locked or unresponsive container could block all sign-ins and sign-outs on a host until reboot, and improved retry handling for locked container files", and fixed a stuck storage provider that could hang sign-out and leave containers attached. 25.04 fixed containers that didn't detach and stopped users signing in to a new session (release notes).
Drain hosts before maintenance, and let sessions end. A host in drain mode won't accept new sessions, but existing ones stay until users sign out. Deallocating or reimaging a host with sessions still on it is a reliable way to leave containers attached.
Set idle and disconnected-session time limits so a disconnected session signs out on its own rather than holding the container for days.
Keep backup and antivirus off live containers. Exclude the profile share from on-access scanning on the session hosts, and schedule share backups or snapshots outside working hours.
Should you turn on concurrent access instead?
No, not on Azure Virtual Desktop. FSLogix's ProfileType setting can let a container be used by more than one connection through differencing disks: 0 is normal behavior, 1 read-write only, 2 read-only only, and 3 tries read-write and falls back to read-only. But Microsoft is explicit: "Concurrent connections are NOT supported by Session Hosts running in an Azure Virtual Desktop Host Pool." Multiple connections on different computers are only supported with differencing disks, OneDrive doesn't support either scenario, and Microsoft says not to mix ProfileType 0 with any other value (concurrent and multiple connections, settings reference). Fix the lock; don't route around it.
How Atlas AVD helps
In Atlas AVD, Workspace → FSLogix brings every host pool's profile containers into one place. The Host Coverage tab shows each session host's live FSLogix state, and Profiles lists every user's container with its size and account status. When a user's profile is beyond saving, Reset Profile signs them out of that host pool and moves their container aside, keeping it on the share as a backup renamed with _RESET_ and a timestamp, so a fresh profile is created at their next sign-in. A Detach Container action appears in the same menu but isn't available yet; until it is, release locks with the steps above. The FSLogix optimization page covers the rest of what Atlas does for profiles.
FAQ
What does "FSLogix error 33" mean?
33 is the Windows system error ERROR_LOCK_VIOLATION: "The process cannot access the file because another process has locked a portion of the file." In FSLogix it almost always means the user's container is still attached to another session or held open by another process.
Why does a locked container give the user a temporary profile?
Because FSLogix's default is to let the sign-in continue when the container can't attach. Set PreventLoginWithFailure to 1 if you'd rather show an error than let users work in a temporary profile they'll lose.
Is it safe to close an open handle on an FSLogix VHDX?
Only when you're certain no live session is using it. Sign the user out of every host pool first, check the handle's client IP, and preview the close with -WhatIf. Closing a handle under a live session can lose data and damage the container.
Can one user have two AVD sessions with the same FSLogix profile?
Not with the default configuration, and Microsoft doesn't support concurrent connections on AVD session hosts. Multiple connections on different computers need ProfileType 3 and differencing disks, which OneDrive doesn't support.
Which FSLogix version fixes locked containers?
Microsoft requires the latest version. FSLogix 26.08 fixed a locked or unresponsive container blocking every sign-in and sign-out on a host until reboot, and improved retry handling for locked container files.
FSLogix settings, defaults and behavior are from Microsoft Learn as of November 2026: container locked, open file handles, configuration settings, configuration examples, concurrent and multiple connections, error codes, the FAQ and the release notes. Windows error names are from System Error Codes.