FSLogix Troubleshooting: The Profile Errors That Actually Happen and How to Fix Them

By David, 2026-09-16

"Your profile couldn't be loaded" is the ticket every Azure Virtual Desktop (AVD) admin learns to dread. The user signs in, gets an empty desktop with none of their files, and calls the helpdesk. Nine times out of ten the cause is FSLogix, and the fix is a setting, a permission or a full file share rather than anything exotic.

This guide covers FSLogix troubleshooting for the errors that actually happen in production: temporary profiles, locked VHDX files, full containers, Azure Files permissions and Kerberos, slow attaches, Cloud Cache and antivirus. Each one has the symptom, the cause and the fix. Then it covers where the logs live, how to stop the same ticket coming back, and how Atlas AVD watches for it. It's vendor-neutral until the section on Atlas.

The short version: most "temp profile" tickets are one of four things: the share is unreachable or denies the user, the container is still locked by another session, the share or container is full, or a local profile got there first. Read the user's last LoadProfile line in C:\ProgramData\FSLogix\Logs\Profile, and the error code tells you which.

FSLogix settings and defaults below are taken from Microsoft Learn as of October 2026 (FSLogix 26.08). Each section links to its source so you can check what has changed since.

How FSLogix attaches a profile: the 60-second version

FSLogix replaces the Windows user profile with a virtual disk. Each user's profile lives in one VHDX file on a network share, usually Azure Files or Azure NetApp Files. At sign-in, the FSLogix service on the session host finds that file, locks it, attaches it and mounts it as C:\Users\<user>. Windows thinks it's loading a local profile. At sign-out, FSLogix detaches the disk again.

That's why one profile can follow a user to any host in a pooled host pool, and also why so many unrelated problems look the same to the user. If anything in the chain fails, FSLogix's default is to let Windows carry on with a temporary or local profile. The user still gets a desktop. It's just not theirs.

The registry settings that drive all of this live under HKLM\SOFTWARE\FSLogix\Profiles. Two are required: Enabled set to 1, and VHDLocations, the UNC path to your share. Microsoft's "Standard" configuration adds a handful more (Configuration examples):

When a user tells you their profile "reset", check these first. Most profile tickets trace back to a host where one of them is missing or different.

The errors, one at a time

1. The user gets a temporary or local profile

Symptom. The user signs in to an empty desktop, sometimes with Windows' own "We can't sign in to your account" or "You've been signed in with a temporary profile" message. Their files reappear the next day, or on another host.

Cause. A temporary profile is FSLogix's fallback, not a root cause. Something earlier in the chain failed, and by default FSLogix lets the sign-in continue. The usual culprits (Microsoft Learn):

• FSLogix isn't enabled on that host. Installing FSLogix enables nothing. A host built from an image or a configuration that missed the registry values signs everyone in locally.
• VHDLocations is wrong or unreachable on that host: a typo, a share that was renamed, or DNS that doesn't resolve the storage account's private endpoint.
• The share denies the user (see section 4).
• The container is locked by another session (section 2).
• The share is full, so FSLogix can't create a new container (section 3).
• A local profile already exists. When FSLogix is added to a host that already has user profiles, it honors the local profile by default.

Fix.

1. Find the user's sign-in in the profile log (see Where the logs live below) and read the Status, Reason and ErrorCode lines. Reason 3 means a local profile exists; reason 7 means Windows created a temporary profile; an error status with code 5, 33 or 1326 points to sections 4, 2 and 4.
2. Fix that cause, have the user sign out, and delete the leftover temporary profile on the host.
3. Set DeleteLocalProfileWhenVHDShouldApply to 1 so a stray local profile can never win again. Review which local profiles exist first, because FSLogix deletes them permanently.
4. Decide whether a temporary profile is acceptable at all. PreventLoginWithFailure and PreventLoginWithTempProfile (both default 0) sign the user out with a "contact support" message instead. That stops users working in a profile that won't be saved, but it also turns a degraded sign-in into a failed one. They don't apply to RemoteApp sessions.

A temporary profile is a symptom. The error code in the FSLogix profile log is the diagnosis.

One trap worth knowing. If a user gets a brand-new empty profile, without the "temporary profile" message, check whether anyone changed FlipFlopProfileDirectoryName, VHDNameMatch or a similar naming setting. FSLogix now looks for a folder that doesn't exist, creates a new empty container, and the user's real profile sits untouched at the old path. Revert the setting, or rename the folders while the users are signed out.

2. VHDX locked or in use by another session

Symptom. The profile log shows AcquireExclusiveLock retries, then ErrorCode set to 33 ("The process cannot access the file because another process has locked a portion of the file") and a temporary profile or a blocked sign-in.

Cause. With the default ProfileType of 0, a container can be attached by one session at a time. Something still has it open:

• The user is signed in elsewhere. They disconnected from host A rather than signing out, and connected to host B. In a pooled host pool, the AVD broker normally reconnects them to their existing session, but not if host A was drained, put in maintenance, or the user connected to a different host pool that uses the same share.
• A previous session didn't detach cleanly. The host crashed, was deallocated mid-session, or sign-out hung. The SMB handle on the file share stays open until it times out or someone closes it.
• Something else opened the file: a backup job, an antivirus scan of the share, or an admin who mounted the VHDX to look inside it.

Fix.

1. Find the session. Check whether the user has an active or disconnected session anywhere, and sign it out properly.
2. If there's no session, the lock is orphaned. For Azure Files, use Get-AzStorageFileHandle in PowerShell to list the open handles on the user's folder, and Close-AzStorageFileHandle to close the one on that VHDX. On a Windows file server, use Computer Management → Shared Folders → Open Files.
3. Make sure your backup and antivirus tools exclude the share's *.vhdx, *.vhdx.lock, *.vhdx.meta and *.vhdx.metadata files (section 7).
4. Set LockedRetryCount to 3 and LockedRetryInterval to 15, as Microsoft recommends, so a locked sign-in fails in 45 seconds instead of retrying for a minute while the user stares at "Please wait".
5. Update FSLogix. The 26.08 release fixed an issue where one locked or unresponsive container could block every sign-in and sign-out on a host until it rebooted (release notes).

If users genuinely need two sessions at once, for example a desktop and a RemoteApp from different host pools, look at ProfileType 3 (read-write with read-only fallback). Note that AVD doesn't support multiple connections within the same host pool.

3. Container full, or the share out of space

These are two different problems with similar symptoms.

The user's container is full. Each container has a maximum size, SizeInMBs, which defaults to 30000 (about 30 GB). With IsDynamic at its default of 1, the file only takes up the space it uses on the share, but it can never grow past that limit.

• Symptom: applications fail to save, Outlook or OneDrive complain about disk space, and the user's C:\Users\<user> volume shows as full. If the container fills mid-session, the session can hang or the profile can detach.
• Fix: raise SizeInMBs. Existing containers grow to the new size the next time the user signs in. You can't shrink the limit, so raise it in steps. Then find out what's filling the profile. Outlook's OST, Teams and browser caches, and OneDrive files are the usual suspects. The Office container (ODFC) can separate those, and OneDrive Known Folder Move keeps Documents and Desktop out of the profile entirely.

The file share is full. Azure Files premium shares, and any share with a quota, stop accepting writes when they hit it.

• Symptom: worse and wider. New users can't get a container and land on temporary profiles. Existing users' sessions hang, and sign-outs fail to write back or detach (Microsoft Learn). It usually starts on a busy Monday morning.
• Fix: increase the share's quota (provisioned size on Azure Files premium) right away; it takes effect in seconds. Then work out why it filled: growth in user count, a few oversized containers, or orphaned containers for people who left. The Prevention section below covers how to stop it happening again.

What about compaction? FSLogix compacts dynamic containers at sign-out by default (VHDCompactDisk). It only runs when the container is over 1 GB and at least 20% of its used space is reclaimable, and it needs the Optimize Drives service (defragsvc) set to Manual or Automatic, not Disabled (VHD disk compaction). Compaction stops containers bloating with deleted data. It doesn't help when the data is real.

4. Azure Files permissions and Kerberos authentication

Symptom. Access is denied (error 5) or The user name or password is incorrect (error 1326) in the profile log, often with "Failed to attach VHD", and a temporary profile. It usually affects everyone at once, right after a change.

Cause. Azure Files checks access in two places, and FSLogix needs both (Configure storage permissions):

• Share-level (Azure RBAC). Users need Storage File Data SMB Share Contributor. Microsoft recommends granting it as the default share-level permission for all authenticated identities. Admins who set NTFS permissions need Storage File Data SMB Share Elevated Contributor.
• Directory and file level (NTFS). CREATOR OWNER: Modify, subfolders and files only. Users (your AVD users' group): Modify, this folder only, so they can create their own folder. Admins: Full Control. Users must not be able to open each other's folders.

And before either check, the session host has to get a Kerberos ticket for the storage account, which depends on the identity source:

• AD DS: the storage account is joined to your domain as a computer object. The session host needs line of sight to a domain controller.
• Microsoft Entra Kerberos: Entra ID issues the ticket, so Entra-joined session hosts don't need a domain controller. Each host needs CloudKerberosTicketRetrievalEnabled set to 1 (Intune settings catalog, Group Policy, or HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters), and LoadCredKeyFromProfile set to 1 under HKLM\Software\Policies\Microsoft\AzureADAccount. The storage account's app registration needs admin consent and must be excluded from MFA Conditional Access policies, because there's no way to prompt during sign-in. Hybrid identities work in Azure commercial and Azure Government; cloud-only identities work only in Azure commercial (Microsoft Learn).

Fix. Check from the outside in: can the host resolve and reach the storage account on TCP 445 (private endpoint DNS is a frequent miss), does the user have the share-level role, do the NTFS permissions match the table above, and is the host configured for the right Kerberos source. A storage account can use only one identity source at a time.

The 2026 Kerberos change. Starting with the April 2026 Windows update, domain controllers default to AES-SHA1 instead of RC4 for Kerberos when an account doesn't specify its encryption types, and the rollback option goes away in July 2026. Storage accounts joined to AD DS that only support RC4 stop authenticating, and every user gets access denied at once. Microsoft flags this on every FSLogix page (FSLogix blog): make sure the storage account's AD object supports AES (its msDS-SupportedEncryptionTypes), rotate its password so AES keys exist, and test on a patched host before the update reaches production.

Long sessions on Entra Kerberos. A Cloud Kerberos ticket lasts 10 hours. Before FSLogix 26.08, a session that ran past that could lose access to its container on reconnect. 26.08 refreshes the ticket in the background, which is one more reason to stay on the current release.

5. Slow attach and logon delays

Symptom. Sign-ins sit on "Please wait for the FSLogix Apps Services" or a black screen, sometimes for minutes. Sign-outs hang on the same message.

Cause. Profile attach is usually a couple of seconds. When it isn't:

• Storage that can't keep up. Sign-in and sign-out are bursts of small reads and writes. A standard Azure Files share, or a premium share provisioned too small for its IOPS and throughput, queues those bursts at 9am. Premium Azure Files is the norm for production profiles.
• Distance. Storage in a different region from the session hosts adds latency to every I/O.
• Lock retries. With the default 12 retries at 5-second intervals, a locked container adds a minute before the user even gets a temporary profile.
• Antivirus scanning the VHDX as it mounts (section 7).
• Oversized containers, especially those holding Outlook OSTs, Teams caches or OneDrive data.
• Compaction at sign-out. Normal, but it can add 20 to 30 seconds, and up to 5 minutes, the first time.

Fix. Measure first. The profile log records loadProfile time: and unloadProfile time: in milliseconds for every sign-in and sign-out, so you can tell whether FSLogix is the slow part or something else in the logon is. If it's FSLogix, check the share's IOPS and latency at peak, move storage to the hosts' region, set the faster lock retries, and confirm the antivirus exclusions. Profile attach is only one stage of the logon. If it's fast and logons are still slow, look at Group Policy, AppX provisioning and startup apps: why are Azure Virtual Desktop logons slow? walks through the whole pipeline.

6. Cloud Cache issues

Cloud Cache replaces VHDLocations with CCDLocations, keeps a local cache of the container on the session host, and writes changes to up to four storage providers. It gives you resilience across storage accounts or regions, at the cost of more moving parts.

The problems are different from standard containers:

• Sign-out hangs. If a provider is unavailable at sign-out, Cloud Cache waits so it doesn't lose data. HealthyProvidersRequiredForUnregister and CcdUnregisterTimeout control how long.
• Users sign in with no healthy provider. By default (HealthyProvidersRequiredForRegister = 0) they can, and work only in the local cache. Microsoft recommends setting it to 1 so sign-in fails instead of creating a local cache that may never be written back.
• Local disk fills up. The cache lives on the host's disk under %ProgramData%\FSLogix\Cache. On pooled hosts, set ClearCacheOnLogoff to 1 (Microsoft's recommendation) and size the OS or temporary disk for peak concurrent users.
• Slow sign-in. The first provider in CCDLocations is the one Cloud Cache reads from. Put the closest, fastest one first.

Cloud Cache logs to its own event channels (Applications and Services Logs → FSLogix → CloudCache), and the Microsoft.FSLogix PowerShell module, added in 25.02, has commands to inspect provider health. If you don't need multi-provider redundancy, Microsoft's advice is to stay on the Standard configuration: it has fewer ways to fail.

7. Antivirus exclusions

Symptom. Intermittent and hard to pin down: slow attaches, ERROR_SHARING_VIOLATION and temporary profiles that come and go, sign-outs that hang, or high CPU from the antivirus process during sign-in.

Cause. Real-time scanning of a VHDX while FSLogix mounts it, or of the FSLogix drivers and services themselves.

Fix. Microsoft publishes the exclusion list (FSLogix prerequisites). In short:

• Processes: frxsvc.exe, frxccds.exe.
• Drivers: frxdrv.sys, frxdrvvt.sys, frxccd.sys.
• Folders: C:\Program Files\FSLogix\Apps\, C:\ProgramData\FSLogix\, and each user's AppData\Local\FSLogix\. With Cloud Cache, also %ProgramData%\FSLogix\Cache and %ProgramData%\FSLogix\Proxy.
• Temporary disks: *.VHD and *.VHDX under %TEMP% and %WINDIR%\TEMP.
• On the share: *.VHD, *.VHDX and their .lock, .meta and .metadata files.
• Registry: HKLM\SOFTWARE\FSLogix and HKLM\SOFTWARE\Policies\FSLogix.

Apply them in every layer that scans: endpoint antivirus such as Microsoft Defender, any scanning on the file share, and DLP tools. Then check they actually landed, because an exclusion policy that targets the wrong device group looks exactly like no policy at all.

Where the logs live and how to read them

The profile log is the first place to look. FSLogix writes text logs to C:\ProgramData\FSLogix\Logs by default, one file per day per component. Profile problems are in C:\ProgramData\FSLogix\Logs\Profile\Profile_<date>.log (Logging and diagnostics).

To read one sign-in:

1. Search for LoadProfile: <username> at the time the user reported the problem, and note the thread ID.
2. Follow that thread from Begin Session: Logon to the end of the sign-in.
3. Look for lines starting [WARN:xxxxxxxx] and [ERROR:xxxxxxxx]. The hex number is a Windows system error code.
4. Read the Status set to, Reason set to and ErrorCode set to lines, and loadProfile time: for how long the attach took.

The codes you'll see most:

The same Status, Reason and Error values are written per session to HKLM\SOFTWARE\FSLogix\Profiles\Sessions\<SID>, which is quicker to check on a live host than the log (FSLogix codes).

Event logs. In Event Viewer, under Applications and Services Logs → FSLogix → Apps, the Admin and Operational logs record attach failures and warnings. Cloud Cache has its own CloudCache logs alongside. These are the logs to forward to Log Analytics, so you can alert on them across every host rather than reading them one at a time.

What about frxtray? Older guides tell you to open frxtray.exe, the FSLogix Profile Status tray tool, for a green or red light on the user's profile. Microsoft retired it in FSLogix 25.02 in February 2025, and it's no longer supported. Use the profile log and the Sessions registry key above instead, plus the Microsoft.FSLogix PowerShell module for Cloud Cache. For a support case, the FSLogix Support Tool collects all the logs into one archive.

Prevention: sizing, quotas and monitoring capacity

Most FSLogix incidents are predictable a week in advance. The ones above that hurt most, a full share and a broken permission, are both visible before users notice them.

• Standardize the configuration. Apply the same FSLogix settings to every host from one place (image, Intune or Group Policy) and check for drift. A single host without Enabled set produces "random" temporary profiles that are very hard to trace.
• Size the container for the user, not the default. 30 GB suits most knowledge workers. Heavy Outlook users with large OSTs may need more, or an Office container. Task workers need much less.
• Size the share for growth and for I/O. Plan for the number of users times their average container size, plus headroom for growth and for orphaned containers. On Azure Files premium, also check that the share's provisioned IOPS and throughput cover your peak sign-in rate, not just its capacity.
• Monitor capacity with time to spare. Alert on share usage well before it's full, say at 80% and 90%, and watch the growth rate, not just the current number. A share that's 70% full and growing 5% a week needs action this week.
• Watch the biggest containers. A handful of users usually account for a large share of the space. Find them before their container hits SizeInMBs.
• Clean up leavers. Containers for people who left stay on the share until someone deletes them. Make it part of offboarding.
• Alert on FSLogix events, not just tickets. Forward the FSLogix event logs from your hosts and alert on attach failures and temporary profiles. One failure is a user; ten in five minutes is the share.
• Stay current. Microsoft requires the latest FSLogix release for support, and recent releases fixed locked-container, sign-out and Kerberos issues covered in this guide.

How Atlas AVD watches FSLogix

Everything above works without any third-party tool. The hard part isn't knowing the fixes. It's noticing in time, across every host pool and every share, before users do. That's the part Atlas AVD automates. Here's exactly what it does, and what it leaves to you.

All of it lives on one page: Workspace → FSLogix, titled FSLogix Management, with Overview, Profiles, Storage, Host Coverage, Health, Capacity, Actions and Settings tabs.

Share capacity, watched every 15 minutes. The FSLogix Capacity Monitor checks the quota and used space of every profile share your host pools point at: Azure Files, Azure NetApp Files and plain SMB shares. When a share crosses the warning threshold (85% by default) it raises FSLogix Profile Share Nearing Capacity, and at the critical threshold (95%) FSLogix Profile Share Critically Full, in the notification center. One alert per share, and it resolves itself when the share recovers. Atlas also keeps a month of capacity history, and when a share is on course to reach 85% within the next two weeks, Atlas Advisor raises a recommendation with a suggested new size. That's the "full share on Monday morning" from section 3, caught the week before.

Optional auto-expand for Azure Files. On the Capacity tab, Enable Auto-Expand grows an Azure Files share's quota by a set percentage (10% by default) when it crosses the trigger threshold, and records each expansion in Capacity Event History. It's off by default, and you can set it globally, per tenant or per host pool. Azure NetApp Files and other SMB shares get the warnings but aren't expanded automatically.

Find the biggest containers and the leavers. On the Profiles tab, Scan sizes & orphans walks a pool's Azure Files share and reports each user's container size and last write. It flags outliers, containers well above the pool's median, and orphans: containers whose owner is disabled or no longer exists in Entra ID. Those are the two cleanups the Prevention section above asks for.

The same FSLogix settings on every host. In a host pool's settings, under Profiles → FSLogix Profiles, you set the share and the FSLogix policy once: FSLogix Enabled, Delete Local Profile, Flip-Flop Directory, Dynamic VHD, VHDX and the container size (40 GB by default), among others. Atlas writes those values to HKLM\SOFTWARE\FSLogix\Profiles on every host it builds, and Push FSLogix re-applies them to the pool's running hosts and restarts the FSLogix service. The Host Coverage tab checks every session host for the FSLogix service, driver and registry settings every six hours, so the one host that's missing Enabled, the source of section 1's "random" temporary profiles, shows up as Not found or Registry (off) instead of as a mystery.

Test the path before users do. Test Connection checks DNS resolution, SMB port 445, file share access, write permission, the FSLogix service and the FSLogix registry from a session host: most of section 4's checklist in one click. Run advanced diagnostics on a host adds the FSLogix service, registry and profile-container checks and the latest FSLogix errors from its event log.

Slow attaches, measured. With AVD Insights connected, Atlas measures each pool's profile load time from Azure Virtual Desktop's own logon checkpoints and raises FSLogix Slow Profile Load when it passes 8 seconds (you can change the threshold), which can also go to Teams, Slack or a webhook. The Logon Breakdown card on the Analytics Experience tab shows each logon phase, so you can see whether the profile or something else is the slow part. When Atlas sets up AVD Insights, its data collection rule also collects the FSLogix Admin and Operational event logs into your Log Analytics workspace.

Storage and antivirus helpers. The Storage tab can create a FileStorage account (Premium LRS by default) and a share with a quota, or designate an existing one. If you use CrowdStrike Falcon, the Falcon connector's FSLogix exclusions tab applies the VHD, VHDX and FSLogix driver exclusions from section 7 in one step.

FSLogix from the current release, and its release notes in your feed. When Atlas bakes FSLogix into an image, it downloads Microsoft's current release rather than a pinned old build. The Atlas Feed tracks FSLogix release notes and tells you when a new version ships.

What Atlas doesn't do, so you can plan for it:

• It doesn't set up identity-based access to the share. Configure AD DS or Microsoft Entra Kerberos, the share-level roles and the NTFS permissions yourself, as in section 4. Test Connection then tells you whether a host can actually use the share.
• It doesn't set the lock-retry, PreventLoginWithFailure / PreventLoginWithTempProfile or Cloud Cache settings. Add those through your image, Intune or Group Policy if you want them.
• It doesn't release a locked VHDX. Use the handle commands in section 2.
• It doesn't set Microsoft Defender exclusions. Apply them with your Defender policy.
• It doesn't read the FSLogix profile log on each host. For a single user's failed sign-in, the log is still the place to look.

New to AVD? What Is Azure Virtual Desktop? explains where FSLogix fits. Planning storage? The AVD sizing guide covers Azure Files tiers. And getting FSLogix wrong is the first of the top 10 AVD mistakes. For the configuration side of FSLogix rather than the errors, see FSLogix optimization for AVD.

FAQ

Why do users get a temporary profile with FSLogix?

Because FSLogix couldn't attach their container and, by default, lets Windows sign them in anyway. The usual causes are a share the host can't reach or that denies the user, a container still locked by another session, a full share, a local profile that already exists, or FSLogix not being enabled on that host. The FSLogix profile log shows which.

How do I fix "VHDX is locked" or error 33 in FSLogix?

Find and sign out the user's other session. If there isn't one, the lock is orphaned: close the open handle on the VHDX with Close-AzStorageFileHandle (Azure Files) or from Open Files on a Windows file server. Then make sure backup and antivirus tools exclude the share's VHDX files.

What is the default FSLogix container size?

SizeInMBs defaults to 30000, about 30 GB. Containers are dynamic by default, so each only uses the space it needs on the share up to that limit. You can raise the limit at any time, and existing containers grow at the next sign-in, but you can't lower it.

What happens when the FSLogix file share is full?

New users can't create a container and get temporary profiles, existing sessions can hang, and sign-outs can fail to write back or detach. Raise the share's quota first, then find out what filled it.

Where are the FSLogix logs?

Text logs are in C:\ProgramData\FSLogix\Logs, with profile sign-in logs in the Profile subfolder. Event logs are in Event Viewer under Applications and Services Logs → FSLogix.

Is frxtray still available?

No. Microsoft retired the FSLogix Profile Status tool (frxtray.exe) in FSLogix 25.02 in February 2025. Use the profile logs and the per-session values in the registry instead.

Does the 2026 Kerberos RC4 change affect FSLogix?

It can. From the April 2026 Windows update, domain controllers default to AES instead of RC4 for accounts without explicit encryption types. Azure Files or file servers joined to AD DS that only support RC4 stop authenticating, and users get access denied. Make sure the storage account's AD object supports AES and rotate its password.

Do I need Cloud Cache?

Only if you need the profile to survive a storage account or region outage. Cloud Cache adds a local cache, more storage cost and more ways to fail. Microsoft recommends the Standard configuration for most deployments.

FSLogix product details in this article are taken from Microsoft Learn as of October 2026: Configuration settings, Configuration examples, Issues with old, temp or local profiles, FSLogix codes, Logging and diagnostics, Prerequisites and antivirus exclusions, Storage permissions, Entra Kerberos, VHD disk compaction and the release notes. FSLogix changes with every release, so check those pages before you change production.