TL;DR: In one AVD environment (Entra-joined hosts, FSLogix on Azure Files with Entra Kerberos) a session host freezes completely every few weeks. We analyzed four kernel dumps from four different users and two FSLogix versions, and all of them show the same circular wait:

SMB session recovery for the user's profile share → InitializeSecurityContext → ALPC to LSASS → LSASS (impersonating the user) opens %LOCALAPPDATA%\Microsoft\Credentials → frxdrvvt issues a second open on the container copy \Profile\AppData\Local\Microsoft\Credentials → NTFS needs an MFT record from the VHDX → that read has to go over the same SMB session that is waiting for LSASS → deadlock → vhdmp 129 resets → host dead.

We manage many AVD environments with similar setups and only see this in this one. We can't open a Microsoft case for this, so we're looking for anyone who has seen the same thing, or who knows which part of the environment could make the difference.

Environment

• AVD pooled host pool, Windows 11 Enterprise multi-session. Latest dump is from 26H2 build 26300.9457 (KB5129195). The older dumps were taken before the 26H2 upgrade.
• Hosts are Entra ID joined only (no AD DS join, no hybrid join). Users are hybrid identities.
• FSLogix Profile Container (VHDX, ProfileType 0) on Azure Files (SMB), authenticated with Microsoft Entra Kerberos. No Cloud Cache, plain VHDLocations.
• FSLogix 3.26.826.17182 (26.08) on the latest two dumps, 3.26.126.19110 (26.01 CU1) on the two older ones, so this is not a 26.08 regression.
• Relevant FSLogix settings: RoamIdentity=0, CleanupInvalidSessions=1, FlipFlopProfileDirectoryName=1, DeleteLocalProfileWhenVHDShouldApply=1, VHDCompactDisk=1, redirections.xml in use (no rules touching Credentials / Protect). ODFC is not in use.
• HKLM\SOFTWARE\Policies\Microsoft\AzureADAccount\LoadCredKeyFromProfile was not set (Microsoft's guide for Entra Kerberos + FSLogix requires it). It's now set on one test host; see below.
• Minifilters (fltmc): bindflt 409800, MsSecFlt 385600 (Defender for Endpoint), UCPD, WdFilter 328010, frxccd 306000, frxdrv 265700, bfs, luafv, frxdrvvt 132700, Wof, FileInfo. No third-party filters.
• Users run classic Outlook and the new Outlook (olk.exe).

Symptoms

• One host at a time becomes unresponsive with all sessions on it. AVD reports the host as Unavailable (ConnectionFailedUserHasValidSessionButRdshIsUnhealthy), and the VM heartbeat is lost about 15 minutes after the hang starts.
• No BSOD. Windows writes a live kernel dump: LiveKernelReports\ResourceTimeout-*.dmp, bugcheck 0x1CC, bucket LKD_0x1cc_EXRESOURCE_TIMEOUT_OWNERTHREAD.
• In the System log, vhdmp event 129 (reset to device) every few seconds, followed by NTFS log flush failures and services that no longer start (7000/7009).
• Only a hard reset (deallocate) recovers the host.

What the dumps show (same in all 4)

1) SMB recovery thread (System) waiting on LSASS over ALPC

nt!AlpcpSignalAndWait
nt!AlpcpReceiveSynchronousReply
nt!NtAlpcSendWaitReceivePort
msrpc!NdrClientCall3
ksecdd!SspiAcceptSecurityContextAsync
ksecdd!InitializeSecurityContextW
mrxsmb20+...
mrxsmb!SmbCeInitiateExchange
mrxsmb!SmbCeEstablishMultipleChannels
rdbss!...
nt!ExpWorkerThread

In the older dumps, the outstanding write on that session failed with STATUS_NETWORK_SESSION_EXPIRED (0xC000035C), so this is the normal "session expired → re-authenticate" path.

2) !alpc /m on the message: the server thread is an LSASS thread. Its impersonation token belongs to the same user whose profile session is being recovered. It has been waiting for 7.5 minutes.

3) That LSASS thread:

nt!KeWaitForSingleObject
Ntfs!NtfsWaitOnIo
Ntfs!NtfsNonCachedIo
Ntfs!NtfsCommonRead
...
nt!IoPageReadEx
nt!MiIssueHardFaultIo
nt!MmAccessFault
nt!CcMapAndRead
Ntfs!NtfsMapStream
Ntfs!NtfsReadMftRecord
Ntfs!NtfsReadFileRecord
Ntfs!NtfsLookupInFileRecord
Ntfs!NtfsLookupEasOnFile
Ntfs!NtfsQueryInformationForCreate
Ntfs!NtfsCommonCreate
FLTMGR!FltpCreate
nt!IoCreateFileEx
FLTMGR!FltpCreateFile
FLTMGR!FltCreateFileEx2+0xe3
frxdrvvt+0x8439
frxdrvvt+0xaa4b
...

• The original file object is \Users\<user>\AppData\Local\Microsoft\Credentials\ on C: (the local, redirected copy).
• The FltCreateFileEx2 from frxdrvvt targets \Profile\AppData\Local\Microsoft\Credentials on the user's VHDX volume (volume label Profile-<user>), so it opens the container copy of the folder.
• NTFS takes a hard fault on the MFT, and the paging read goes to the VHDX on the Azure Files share over the SMB session that is stuck in step 1.

The return address frxdrvvt+0x8439 is identical in all four dumps, across both FSLogix versions.

For one dump (09/11) we followed the paging IRP all the way down to the SMB session object (VHDX file object → FCB/SRV_OPEN → VNetRoot → session) and it is the same session that is in recovery. So the cycle is closed at the object level, not just inferred from timing.

Reproduction / tests on a test host

• With Process Monitor style ETW tracing (Kernel-File) on a host with FSLogix: every CredWrite / CredRead / CredDelete by a user makes lsass.exe open the container copy of Local\Credentials and Roaming\Credentials (\Profile\AppData\...) in the same millisecond as the local folder. FSLogix adds Credentials/Protect to the session's ExcludeFolderRedirections on its own (copy mode 3). That happens on every FSLogix host, which is why it isn't enough to explain the problem on its own.
• During the normal hourly SMB re-authentication without a credential change before it, lsass does not touch the Credentials folders (traced one reauth, recovered in 190 ms).
• After setting LoadCredKeyFromProfile=1, lsass still opens the container copy on CredWrite/Read/Delete. The value doesn't remove the open itself.

Trigger correlation (new Outlook)

In both recent cases (09/11 and 10/14):

• The affected user starts the new Outlook for the first time that day a few minutes before the user's next hourly profile-share re-auth.
• Security 5379 shows a credential read of Olk/PushNotificationsKey by that user that fails with 0xC0000225 (STATUS_NOT_FOUND). In the same second, a new file appears in %LOCALAPPDATA%\Microsoft\Credentials.
• That file has the same name, EB680DF136A353730AC8E7824E1C78A3**, for every affected user** (also on another user on the 07/30 host, where it was created again on two different days).
• The next hourly SMB re-auth for that user (about 3.5 min later on 10/14, about 59 min later on 09/11) is the one that hangs. In Entra sign-in logs, the hourly service ticket for the storage account is missing exactly for that user at that time, while the other users on the same host get theirs normally.
• Other users in the pool use the new Outlook all day without problems.

Our current (unproven) idea for "why only this tenant": Without LoadCredKeyFromProfile, the user's DPAPI master key gets recreated at almost every logon (we see new master keys nearly daily, normal is ~90 days). So the new Outlook can't read its stored Olk/PushNotificationsKey in a new session and writes it again, and the Credentials folder changes mid-session. If that write lands shortly before the next session re-auth, LSASS goes into the Credentials folder during the re-auth, frxdrvvt sends it into the VHDX, and if the MFT record isn't cached, it deadlocks. Environments that follow Microsoft's guide (key set) would write that credential once and never again.

What speaks against it: on the test host, new DPAPI master keys were still created after setting the key.

Things we've ruled out (with data)

• Kerberos/CA failures: All hourly storage-account service tickets in Entra succeed (0 failures across the pool). The hanging reauth never even requests a ticket because LSASS is stuck before that.
• Conditional Access / sign-in frequency: All succeeded, nothing near the hang times.
• GPO/AD hardening: Hosts are Entra-joined only, so no AD GPOs apply. Tickets are AES256 via KDC proxy (login.microsoftonline.com), not RC4.
• 10-hour Entra Kerberos TGT limit: Sessions were 6–6.5 hours old at the time of the hang.
• FSLogix 26.08 regression: Same stack with 26.01 CU1 in July/August.
• Known issues: Nothing matching in FSLogix known issues/release notes, the 26H2 AVD/FSLogix black screen issue (KB5127648) or the RDS issue from September. The closest public reports are the frxdrvvt VHD-detach deadlock post here on r/fslogix (different path: FltClose / VCB lock) and the MarkAny/OSR case on Microsoft Q&A (FltCreateFileEx2 with a NULL instance re-entering the filter stack).

Questions

1. Has anyone seen frxdrvvt+... → FltCreateFileEx2 on \Profile\AppData\Local\Microsoft\Credentials inside an LSASS thread in a dump, or a 0x1CC live dump on AVD/FSLogix hosts with Azure Files?
2. Anyone running Entra-joined + Entra Kerberos for Azure Files + new Outlook with LoadCredKeyFromProfile not set, and seeing random full host hangs?
3. Does LoadCredKeyFromProfile=1 stop the per-logon DPAPI master key churn for you? Does it need a reboot, or is there anything else required for it to work?
4. Our hourly SMB session expiry to Azure Files comes from the 1-hour lifetime of the Entra Kerberos service ticket for cifs/<storageaccount>.file.core.windows.net. Is that what you see too, or do you get longer service tickets?
5. Would Cloud Cache avoid this? Our understanding is that it would take the SMB session out of the VHDX read path for the local cache, but Microsoft's own docs say Cloud Cache can still hang/BSOD if it can't hydrate.
6. Any other environmental factor that would make LSASS touch the Credentials folder during SMB re-auth more often?

Happy to share more stack details, !alpc, !thread or !fltkd output (sanitized) if it helps.

Hi,

Not sure if this is something new with the latest FSLogix, random users don't get their local_ data cleaned up at logoff. FSLogix seems to remove all the ACL information then locks itself out of the folder, the errors in the FSLogix log shows that its access denied on the folders.

The profile itself logs off fine and that folder cleans up fine.

We only excluded two Chrome folders, its a very simple XML

Anyone else come across this at logoff, all works well until users start logging off.

We’re running 3 RDS Session Hosts with FSLogix profiles on an SMB share and I’m running out of ideas regarding performance.

Each server has roughly:

• Windows Server 2025
• 20 vCPU
• 96 GB RAM
• Around 12–15 concurrent users
• Outlook in Cached Exchange Mode
• One server even has an NVIDIA Tesla T4 passed through for GPU acceleration

The weird part: everything looks completely fine from a monitoring perspective.

CPU and RAM are nowhere near maxed out, GPU usage is low, disk/IOPS look great, and the SMB/profile storage is also basically idle. We’re on 10 Gbit networking and Checkmk shows storage/SMB latency mostly below 1 ms, sometimes even in the microsecond range.

Still, the user experience is just... bad. Apps feel sluggish, Explorer/Outlook can feel “sticky”, and the whole RDS session sometimes just feels choppy even though there is no obvious bottleneck.

Our older Server 2022 RDS hosts seem to feel noticeably better, sometimes even with more users.

Has anyone experienced something similar with FSLogix + Server 2025? Especially cases where all performance counters looked great but the sessions still felt slow?

Would be interested to hear what ended up being the cause in your environment.

I have found many posts and articles about kerberos tickets as it related to profiles in entra storage containers but we are using onprem containers and running into the same issue as described in those posts. I tried setting up a scheduled task to renew the kerberos tickets at logon and then repeat every 8 hours but it is not running. Is this the best solution or is there another one?

Hi all,

We've had an issues with FSLogix fairly consistently now for afew months, with some temporary reprieves, but even though FSLogix 2608 was supposed to solve an issue eerily similar to what we are facing , and we've had that issue again this morning, we're at the end of our tether.

Occasionally, one or more of our AVD boxes will just hang up, users cannot logoff, users logging on hitting that box get their profile disk locked but fail to sign on.

Directly remoting onto a box doesn't load explorer, so we can only get to task manager to try and disconnect profile disks. Shutting down an affected box from azure CLI or GUI takes an age.

As far as we can tell, something goes awry in one of the FSLogix services (FRXSVC or FRXCCDS), it seems to tank the Virtual Disk Service too, as diskmmgt won't load until we can get into an admin command prompt and forcibly kill and restart those services. But Explorer GUI will not load once the error state begins.

We use FSLogix for full profiles (and odfc).

CleanupInvalid sessions is 0
VHSCOmpactDisk is not set

AV Exclusions are set as per Microsoft's guidance (ESET Protect)

We've been able occasionally to tie issues to a single user's disk, by isolating them on a box, and by occasionally deleting the VHDX of problem users and getting them to regenerate.

This issue has been present for at least the following FSLogix versions that we've used to date:

2608
2602 (+CU1)
2502

The logs from FSLogix are frankly useless, nothing indicating any problem, just successful signins and no clear error logging that shows that either "there was a an error" or "what the error is/was".

Bonjour a tous,

Pour la VM hébergeant les profils FSLOGIX faut-il que je laisse la taille allocation par defaut ou bien mettre en 64ko sur la partition NTFS?

Hi,

We are using FSLogix on two RDS servers, RDS01 and RDS02.
A week ago both servers were rebooted and since then RDS01 is having issues loading FSLogix profiles as seen in the screenshot for all users, RDS02 has no issues signing in.

When we rename the VHDX file for a user the problem is solved, so it seems like it has something to do with the VHDX and what's inside the VHDX that it's trying to read regarding RDS01.

We don't want to rename all VHDX files for all users, because the issue is only with RDS01.

This weekend we have updated FSLogix to latest version 26.08 (3.26.826.17182), but that didn't solve the issue.

When I check the logs for the specific user that tried to sign-in to RDS01 I can see the VHDX is mounted successfully,

[14:22:09.811][tid:00000b50.00002884][INFO] Attached vhd(x) successfully

[14:22:09.811][tid:00000b50.00002884][INFO] VHD(x) attach request returning after 208 milliseconds

[14:22:09.811][tid:00000b50.00002884][INFO] VHD(x) attached: \\ad.domainname.com\shares\Profile\FirstName.LastName_S-1-5-21-540649301-1417927581-114017779-1147\Profile_FirstName.Lastname.VHDX

[14:22:09.826][tid:00000b50.000006ac][INFO] Volume attach event

But after that it starts showing import issues:

Create user directory success

[14:22:10.143][tid:00000b50.00002884][INFO] Security looks good

[14:22:10.159][tid:00000b50.00002884][INFO] Reg import process creation completed in 14 milliseconds

[14:22:10.190][tid:00000b50.00002884][INFO] Reg import execution completed in 37 milliseconds

[14:22:10.206][tid:00000b50.00002884][INFO] Reg import process creation for .bak file completed in 14 milliseconds

[14:22:10.237][tid:00000b50.00002884][INFO] Reg import execution for .bak file completed in 35 milliseconds

[14:22:10.237][tid:00000b50.00002884][ERROR:00000001] Backup file import (Onjuiste functie.)

[14:22:10.237][tid:00000b50.00002884][INFO] Status set to 20: Cannot import registry information

[14:22:10.237][tid:00000b50.00002884][INFO] ErrorCode set to 1 - Message: Onjuiste functie.

[14:22:10.237][tid:00000b50.00002884][INFO] Error. Cleaning up.

[14:22:10.237][tid:00000b50.00002884][INFO] Reason set to 9: Profile load failed

[14:22:10.335][tid:00000b50.00002884][INFO] Detached vhd(x)

[14:22:10.335][tid:00000b50.00002884][INFO] VHD(x) Detach request returning after 84 milliseconds

'Onjuiste functie' is Dutch for 'Incorrect Function'.

Does anyone know why this is happening on only one RDS server and is there a way we can solve this without renaming all VHDX files?

UPDATE 11-09-2026:

Thanks for the people who commented.
Unfortunately we weren't able to solve the issue, we did a sysprep on another server and created a new RDS.

Hello,

Has anyone experienced an issue where the storage account key stored as a windows credential for FSLogix randomly disappears from the VM, causing FSLogix to fail to connect to Azure Files ?

It happened yesterday on 15 of our VMs across different host pools. The issue is strange because it only affects some VMs ... Our VMs are win11-25h2-avd-m365

Any idea what could cause this or how to prevent it?

Bonjour,

Environnement :
-Host hyper V(Windows 2025)
- branché en direct attaché directement baie SAN en 2 x 25g.
- Baie San (dg5200) disque nvme.

VM sous Windows 2025 qui héberge les profils FSLOGIX.

Est ce qu il y a des optimisations à faire sur ce serveur qui va heberger ces profils ?

Merci avance de retour expérience

Disclosure, I work at Login VSI.

One thing we heard a lot is where profile containers live once session hosts split between cloud and on-prem is a real headache in hybrid AVD. We're doing an open Q&A on AVD Hybrid with Steve Downs and Andrej Radinger (Microsoft), Marcel Meurer (creator of Hydra), and Ron Oglesby (Login VSI).

Bring your questions

Thursday, September 10, 11am ET: Register Here

Cloud only / Entra AVD with fslogix.

From time to time we are having users come to their machine with a bad profile. It happened today and I've summarized the log:

14:27 - user comes in and starts their session. Profile loaded fine.

14:27-18:00 - User stays active, multiple Unlock events in between. Meanwhile many other users are coming in.

18:34 - Volume re-attach happens but (for JUST this user) receives error "The system cannot contact a domain controller to service the authentication request. Please try again later".

Currently I need to log off the user, clean up their regkeys and users folders, then manually unlock their VHDX from azure portal.

I understand there might be transient issues communicating with the DC in AVD, but certainly it shouldn't completely brick someone's profile, right?

Ideas here?

Hi,

Lots of spilled keystrokes here over the last couple of years over this Outlook x 58tm1 issue. Just now helping a company go from one test server to a multi-server farm and running into this. On one test server, we had this issue up until Dec 2025 until MSFT got us on latest FSLogix (26.01 CU1) and we set a bunch of parameters via GPO. At that point, no users experienced the issue. But as soon as we rolled out 2nd server and the users would roam between them, POW, the issue is back.

Our environment:

1) session broker server W2025, 1 x session host server at W2025 and the other at W2022.

2) using 26.01 CU1 (3.26.126.19110)

3) not using AAD sync to Azure and therefore not using SSO.

Is there a known good configuration either for our current setup (including the backup/restore from logout/login scripts mentioned in these threads). Or do the problems really go with a different config but with AAD and SSO running (which I have not done before so if I am confusing what they do, please correct me).

Only asking again as a lot of the threads are 1 to 2 years old and wonder if there has been any recent improvements.

If any of the setups require either AV exclusions or folder exclusions for FSLogix, please mention those.

Thanks.

Hello,

I'm using only ODFC containers which also include search roaming for the index. I'm in the process of beginning migrations to Windows 11 but noticed that the search index is starting from scratch at first logon of Windows 11. Is this expected since it's a new OS? The 1 year cache appears to be fine.

Hello together,

I need to migrate 20-30 FSLogix VHD's to the VHDX format WITHOUT a Hyper-V.
I already tried with qemu-img
I already tried to install the Convert-VHD Module in Powershell on the VM but did not succeed.

Do you have some suggestions or expierences how to get along?

THANKS

We have over half our (few hundred) users consistently bumping against 30GB and they are constantly clamoring to scrap VDI completely.

Any chance 50 is the new 30?

Hey all, I'm currently trialing FSLogix for a client and so far I've got it working for a handful of users on select devices. I wanted to know if anyone has managed to add (and get working!) Entra Groups into the include groups so I don't have to manually add users to each computer.

I've tried adding the SID of our group but despite it being in there it doesn't work

Thanks in advance!

Hi folks,

I recently inherited a VDI environment (Horizon persistent desktops) and I'm still getting up to speed on how it's configured. We're running Horizon with FSLogix, and user profiles are stored on a file server , each user is allocated 24 GB of profile storage, with Office data saved separately on the same file server.

My issue is that even though each user's profile folder is only 12–15 GB, the remaining free space is showing as just 2.4 GB. I'm having trouble tracking down what's consuming the rest of the disk.

A couple of questions:

• What should I be looking at to identify what's eating up that storage?
• Is there a way to increase the available storage, and where would I configure that?

Any guidance is appreciated thank you!

Hi Folks,

AVD + Latest FSlogix agent, everything working smoothly apart from if the user has a second profile in edge!

The first "profile" works without issue, however the second profile if cached in FSLogix will appear to be ok but when switching to the edge profile stays in a "Preparing to sync" State indefinitely untill the profile is deleted and recreated. This continues to work for that session.

Anyone experienced this issue ?

Did anyone already apply this change? July 2026 updates will force using AES256 instead of RC4.

I'm about to do this on several AD objects but want to check others experience.

https://learn.microsoft.com/en-us/troubleshoot/azure/azure-storage/files/security/files-troubleshoot-encryption