A field guide to fixing FSLogix Profile Container failures on AVD, Windows 365, and Citrix in 2026. Decode log status codes, debug Azure Files Kerberos, and survive Cloud Cache outages without losing user data.
FSLogix profile container troubleshooting starts with one log file: C:\ProgramData\FSLogix\Logs\Profile\Profile-YYYYMMDD.log. If you can read that file and translate its status codes into VHDX, Azure Files permissions, or Kerberos problems, you can fix roughly 90% of FSLogix tickets in an Azure Virtual Desktop (AVD), Windows 365 Cloud PC, or Citrix DaaS environment. In this guide I'll walk through the diagnostic order I actually use on production session hosts in 2026, including the FSLogix 2.9.8884 logging changes, Entra Kerberos for Azure Files, and Cloud Cache failure modes.
FSLogix logs at C:\ProgramData\FSLogix\Logs\Profile and ...\ODFC are the single source of truth. Always read them before changing settings.
Status 0x00000005 means access denied to the VHDX share; 0x00000003 means the path doesn't exist; 0x0000003B means the VHDX itself is corrupt or in use.
For Azure Files with Entra Kerberos, both the storage account RBAC role and the NTFS ACL on the share must be configured (missing either causes silent fallback to a temp profile).
Cloud Cache writes to the first healthy provider only; if your primary container is broken, Cloud Cache will look healthy while silently using the secondary.
Disable FSLogix per-session with HKLM\SOFTWARE\FSLogix\Profiles\Enabled=0 and reboot. Never delete the VHDX while a user is signed in.
FSLogix 2.9.8884 (2026 release) adds structured ETW logging via frxtray and changes default redirections.xml behaviour for Teams 2.1.
What is FSLogix and how does it actually work?
FSLogix is the user-profile virtualisation layer Microsoft ships with Azure Virtual Desktop, Windows 365 Cloud PC, and Citrix DaaS deployments. At sign-in, the frxsvc service mounts a per-user VHDX (or VHD) file from a network share as if it were the local C:\Users\<username> folder. At sign-out, frxsvc dismounts the VHDX, leaving a clean session host with no user data left behind. In my experience the magic that makes pooled non-persistent desktops feel persistent is also where everything goes wrong, because there are now six things that can fail instead of one: the share, the VHDX file, the mount, the redirections, the Office container, and Cloud Cache replication.
The official FSLogix overview on Microsoft Learn is worth bookmarking, but it does not cover real-world failure modes. The 2026 release stream introduced version 2.9.8884 with new ETW providers and a reworked Office Container handler, and I'll point out where that matters below.
Step 1: Read the FSLogix logs the right way
Before I touch a single setting I open the log directory. On every session host, FSLogix writes to:
C:\ProgramData\FSLogix\Logs\Service\Service-YYYYMMDD.log: frxsvc startup and configuration parsing.
C:\ProgramData\FSLogix\Logs\Search\Search-YYYYMMDD.log: Outlook search index in the container.
The default log level is Info, which is too quiet for real diagnostics. For an open ticket I temporarily switch to Verbose by setting HKLM\SOFTWARE\FSLogix\Logging\LogLevel = 0 (DWORD) on the affected session host, then restart frxsvc:
Reproduce the sign-in while tailing the log. You're looking for the line that begins [ERROR: followed by a hex status code, which is almost always an NTSTATUS or HRESULT value. The frxtray utility (shipped in the FSLogix MSI) also lets users see their own profile status in the system tray, so install it on session hosts to cut helpdesk calls. Turn LogLevel back to 1 (Info) once you're done; verbose logging produces hundreds of megabytes per day on a busy host.
Why is my FSLogix profile not loading?
Honestly, "profile won't load" is by far the most common FSLogix ticket. In practice it has four root causes, in decreasing order of frequency: the share is unreachable, the VHDX is locked by another session, the VHDX is corrupt, or Entra Kerberos authentication to Azure Files has expired. Each one shows a different pattern in the log.
If the share is unreachable you'll see RetrieveUserPolicy returned status 0x00000003 (path not found) or 0x00000035 (network path not found). Test the path directly from the session host running as SYSTEM with PsExec from Sysinternals:
psexec -s -i cmd
dir \\storageacct.file.core.windows.net\profiles
If that fails as SYSTEM but works as a user, you have a Kerberos/SMB issue, not a network one. If the VHDX is locked by another session you'll see 0x000003E6 (sharing violation) followed by an automatic retry. This happens when a user has a hung session on another host. Kill the orphan session via the AVD portal or Get-SmbOpenFile | Where-Object Path -like "*username*" | Close-SmbOpenFile -Force on the file server. For more on cross-server Kerberos behaviour see our Kerberos troubleshooting guide for 2026, which covers the RC4 deprecation that broke many older FSLogix shares.
Common FSLogix error codes and what they mean
The status codes FSLogix surfaces are mostly standard Win32 / NTSTATUS values that the FSLogix team did not bother to translate. Here are the ones that account for the bulk of tickets I see:
Status code
Meaning
What to check first
0x00000003
Path not found
VHDLocations value, DNS, share existence
0x00000005
Access denied
SMB share permissions and NTFS ACLs
0x00000020
Sharing violation
Antivirus scanning the .vhdx; exclude path
0x00000035
Network path not found
Private endpoint / DNS for Azure Files
0x0000003B
I/O error / VHDX corrupt
Mount manually with frx.exe list-redirects; rebuild if torn
0x000003E6
Invalid handle / locked
Concurrent session on another host
0x80070003
HRESULT path not found
Same as 0x3 but raised by the COM layer
0x80070522
Privilege not held
SeCreateSymbolicLink missing on session host
For corrupt VHDX files (0x0000003B) I never try to repair the user's only copy in place. Copy the .vhdx out to a workstation, mount it with Mount-VHD in Hyper-V, run chkdsk /f on the mounted volume, then copy the user's data into a fresh container. The Microsoft FSLogix configuration reference documents every registry value, but it doesn't tell you which ones matter most: VHDLocations, SizeInMBs, IsDynamic, and DeleteLocalProfileWhenVHDShouldApply are the four I touch in 95% of deployments.
Azure Files + Entra Kerberos: the permission stack
If you store containers on Azure Files with Microsoft Entra Kerberos (now the default for Windows 365 deployments in 2026), permissions live in two places and both must be right. Get one wrong and FSLogix silently falls back to a temporary profile.
RBAC on the storage account. Users need Storage File Data SMB Share Contributor; admins need Storage File Data SMB Share Elevated Contributor to manage NTFS ACLs.
NTFS ACLs on the file share root. From an Entra-joined client mount the share once with net use Z: \\storageacct.file.core.windows.net\profiles, then apply icacls Z:\ /grant "Domain Users:(M)" with This folder only scope. Do not grant rights below the root or new VHDX creation breaks.
The order matters: RBAC controls whether the SMB connection is allowed; NTFS controls what you can do once connected. If a sign-in produces a temporary profile (desktop labelled "TEMP", no Start menu pins), check both. To verify Entra Kerberos itself is working, run klist -li 0x3e7 on the session host as SYSTEM after a sign-in, and you should see a ticket for cifs/storageacct.file.core.windows.net. If not, see the troubleshooting steps in our Microsoft Entra ID Conditional Access guide; a policy blocking the storage resource will also block FSLogix mounts.
For deployments that still use Active Directory-joined storage accounts, the AD computer object for the storage account needs SPN registration via Set-AzStorageAccount -EnableAzureActiveDirectoryKerberosForFile or the older Join-AzStorageAccount module. The 2026 Az.Storage 6.x cmdlets removed the legacy switches, so old runbooks will fail on first run.
Cloud Cache failure modes you won't see in the GUI
Cloud Cache (CCDLocations) lets FSLogix replicate the user's container across multiple providers (for example, two Azure Files shares in different regions). I hit this exact gotcha on a Citrix DaaS rollout last year: it's marketed as high availability but operates more like a write-through cache with eventual consistency. There are two failure modes you have to actively look for:
1. Silent fallback to secondary. If the primary provider returns 0x00000005 (access denied), Cloud Cache will write to the secondary without raising a user-facing error. The user signs in successfully, but their data is now diverging across providers. The only signal is in ODFC-YYYYMMDD.log: Provider 1 unhealthy, using Provider 2. I monitor that string with Azure Monitor and alert on more than ten matches per hour per host.
2. Torn container on host crash. If the session host bluescreens while Cloud Cache is replicating, the local .VHDX in C:\ProgramData\FSLogix\Cache can be ahead of both providers. On next sign-in, frxsvc will refuse to mount with status 0xC000000D (invalid parameter) until you delete the cache directory. The fix is brutal but reliable:
# Run on the affected session host as administrator
Stop-Service -Name frxsvc -Force
Remove-Item -Path "C:\ProgramData\FSLogix\Cache\*" -Recurse -Force
Start-Service -Name frxsvc
This forces Cloud Cache to re-fetch from the providers on next sign-in. You will lose any session writes that hadn't yet replicated, usually a few minutes of work. Communicate that to the user before you run it.
Profile Container vs Office Container (ODFC): which do you need?
One of the most common questions I get from new AVD admins is whether to enable the Office Container alongside the Profile Container. The Profile Container holds the entire user profile (Desktop, Documents, AppData, registry hive). The Office Container (ODFC) holds only Outlook OST, OneDrive cached files, OneNote, and Teams Classic cache, and only when you also enable Profile Container. So you can run with Profile Container alone, but not ODFC alone.
I use Profile Container only in 90% of deployments. ODFC adds value in exactly two scenarios: (1) you need to keep Outlook OSTs in a separate storage tier (premium Azure Files for OSTs, standard for everything else), or (2) you use Citrix Profile Management for the main profile and only want Office data in FSLogix. Both are niche. For everyone else, ODFC doubles the number of VHDX files you have to monitor and doubles the failure surface. The Microsoft container types reference spells out the design tradeoffs in full.
Teams 2.1 and the redirections.xml change
The new Teams 2.x client (now mandatory after the September 2025 Classic Teams retirement) stores its cache in %LOCALAPPDATA%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache rather than the Classic path. The default redirections.xml shipped with FSLogix 2.9.8612 excluded the Classic path; 2.9.8884 includes the new path but also adds the MSIX package state, which can double the size of profile containers on chatty users. Audit your custom redirections.xml after upgrading.
A minimal modern redirections.xml that works with Teams 2.1, OneDrive 25.x, and Outlook Monarch looks like:
Place this file at \\storageacct.file.core.windows.net\profiles\redirections.xml and set RedirXMLSourceFolder in the registry to that share path. FSLogix re-reads it on every sign-in, so changes take effect on the next session. No host restart required.
How do I safely disable FSLogix for one user or one host?
Sometimes the cleanest fix during a P1 outage is to disable FSLogix temporarily so users can sign in with a local profile while you fix the underlying storage problem. The supported way to do this is the registry switch:
The reboot is required because frxsvc reads Enabled only at service start. After the reboot, sign-ins create local profiles on C:\Users. Tell users their changes won't follow them to other hosts until you re-enable FSLogix and run a one-time profile migration with frx copy-profile. Don't ever delete a user's VHDX file as a "fix" while they're signed in elsewhere. The file is open, the delete will silently fail, and the next sign-out will write back over your cleanup.
If you're rolling out FSLogix via Intune, our Intune device enrollment troubleshooting guide covers how to verify the FSLogix configuration profile actually applied. A common cause of "FSLogix isn't working on new hosts" is that the policy never reached them.
Prevention: monitoring you should set up today
The single highest-ROI piece of monitoring for FSLogix is alerting on the Profile log for any line containing [ERROR: or FailedOperation. Ship the log directory to Azure Monitor with the AMA Custom Logs source, then build a KQL alert that triggers when more than three errors land from the same host inside a five-minute window:
FSLogixProfile_CL
| where RawData has "[ERROR:" or RawData has "FailedOperation"
| summarize count() by Computer, bin(TimeGenerated, 5m)
| where count_ > 3
Three errors in five minutes from the same host almost always means an in-progress incident. Catching it before users notice is the difference between a routine ticket and a director-level escalation. Pair this with disk-space alerts on the storage account (Azure Files quotas silently break VHDX growth at 100%) and you'll catch most outages before they page. Add the Profile log path to your standard SIEM ingestion playbook and you've covered the long tail too.
Frequently Asked Questions
Where are FSLogix logs stored by default?
FSLogix writes per-day log files to C:\ProgramData\FSLogix\Logs\ on each session host, with subfolders for Profile, ODFC, Service, and Search. The default log level is Info; set HKLM\SOFTWARE\FSLogix\Logging\LogLevel to 0 and restart frxsvc to capture Verbose output for an active investigation.
What is the difference between a Profile Container and an Office Container?
The Profile Container virtualises the entire user profile (Desktop, Documents, AppData, registry hive) in a single VHDX. The Office Container (ODFC) is an optional second VHDX that holds only Outlook, OneDrive, OneNote and Teams cache data, used when you want to tier those files to different storage. You can run Profile Container alone, but ODFC requires Profile Container.
How do I fix FSLogix error 0x00000005?
Status 0x00000005 is access denied, almost always at the SMB share or NTFS ACL layer. For Azure Files with Entra Kerberos, verify the user has the Storage File Data SMB Share Contributor RBAC role on the storage account AND that NTFS permissions on the share root grant Modify to the user. Both layers must allow access; either one denying causes 0x5.
Why is my FSLogix profile loading slowly at sign-in?
The two top causes in 2026 are antivirus scanning the VHDX file (exclude *.vhdx and *.vhd in the FSLogix container path from real-time scanning) and bloated profiles caused by missing redirections.xml exclusions for Edge, OneDrive, and Teams caches. A healthy Profile Container should mount in under three seconds; anything over ten seconds warrants investigation.
Can I move an FSLogix VHDX between users or hosts?
You can move a VHDX between session hosts (that's the whole point of the design). You cannot move a VHDX between users because the registry hive inside contains the original user's SID. To migrate data between users, mount the source VHDX with frx copy-profile, copy the data to a new container created for the target user, and discard the source.
A 2026 troubleshooting playbook for macOS Platform SSO with Microsoft Entra ID. Fix registration loops, smart card key errors, and Conditional Access blocks with diagnostic commands tier-1 staff can run.
A field-tested walkthrough of Windows Autopilot error 0x80180014, what the MDM enrollment failure actually means, how to read the IME logs, and four fixes confirmed on Surface and Dell hardware.
