Problem Windows Server 2022 + RDS + FSlogix

S

sverchok16

New Member
Oct 14, 2025
4
0
1
Hi,
I have a VM running Windows Server 2022 with RDS farm + FSLogix.
Environment:
  • Proxmox VE 9
  • Kernel: Linux 6.17.4-2-pve (2025-12-19T07:49Z)
  • Host CPU: AMD EPYC 7443P (24 cores, 1 socket)
  • VM CPU: 24 vCPUs (host type)
  • VirtIO drivers version: 0.1.285
Issue:
At random moments the VM CPU usage jumps to 100%.
The “System” process consumes most of the CPU.
Process Explorer shows heavy usage in:
  • vhdmp.sys
  • ntoskrnl.exe
At the same time, disk I/O inside Windows (Resource Monitor) goes to 100%.
This server is used as an RDS farm with FSLogix profile containers.
Has anyone experienced similar behavior?
Could this be related to:
  • VirtIO drivers?
  • Disk configuration?
  • High vCPU count?
  • FSLogix profile containers?
  • Possible misconfiguration of the virtual machine (NUMA settings, machine type, CPU type, ballooning, IO thread settings, storage backend tuning)?
Any suggestions would be appreciated.
CONFIG:
agent: 1,freeze-fs-on-backup=0
allow-ksm: 0
balloon: 0
bios: ovmf
boot: order=scsi1
cores: 22
cpu: host
efidisk0: pvs4-pool-vm:vm-114-disk-1,efitype=4m,ms-cert=2023,pre-enrolled-keys=1,size=1M
machine: pc-q35-10.1
memory: 163840
meta: creation-qemu=10.1.2,ctime=1765794630
name: WINRDS02
net0: virtio=BC:24:11:82:1E:37,bridge=vmbr1,mtu=1500
numa: 0
onboot: 1
ostype: win11
sata0: none,media=cdrom
scsi1: pvs4-pool-vm:vm-114-disk-0,iothread=1,size=700G
scsihw: virtio-scsi-single
smbios1: uuid=f8c7fa8e-e994-4d49-a2c7-9ae5208acf65
sockets: 1
vmgenid: 825a8524-20a3-489b-b62f-db5f0b9a0a9b
 
For my customers we are using rds farm + fslogic on CEPH tbh, not on local disks. Try changing cpu type to something instead of host. Also maybe screenshots of load and io of the VM,maybe you have something like I/O stall?
 
FSLogix profile containers are stored on a high-performance SAN storage and accessed over the network via SMB. We have also tested different CPU types (including non-host types), but the issue persists. We have disabled the VM’s screenshot functionality to rule out any potential impact on performance.
Our RDS farm consists of multiple VMs with identical configurations.
The high CPU / disk activity issue occurs randomly on only a single VM.
If the SAN storage were the cause, we would expect all VMs to experience the same behavior concurrently.
 
sverchok16 said:
FSLogix profile containers are stored on a high-performance SAN storage and accessed over the network via SMB. We have also tested different CPU types (including non-host types), but the issue persists. We have disabled the VM’s screenshot functionality to rule out any potential impact on performance.
Our RDS farm consists of multiple VMs with identical configurations.
The high CPU / disk activity issue occurs randomly on only a single VM.
If the SAN storage were the cause, we would expect all VMs to experience the same behavior concurrently.
Click to expand...
Hi sverchok16,

Have you been able to get in to bottom of this issue and resolve it finally?
We do have exactly same issue on our RDS Session Hosts suddenly. We do have entire RDS SH fleet running on Proxmox + File Server (Windows with DFS) and our 12 session host randomly reach out to 100% CPU (one at a time) causing the system to collapse.
Low level anlaysis proved that the cause for the 100% CPU is coming from SYSTEM dealing with vhdmp.sys.

Problem started out in September, most likely after patching.
 
Hi,Arek K.

Not fully resolved yet, unfortunately, but I can share what we’ve found so far. It may save you some time.


In our case the problem is not caused by the September updates: we were seeing the same hangs before them. The September CU did have a confirmed RDS issue (Remote Desktop Services could stop responding), but Microsoft fixed it with the out-of-band update KB5129237 on 14 Sep, and the fix is included in all later updates, including the October CU. See the Microsoft release health page: https://learn.microsoft.com/en-us/windows/release-health/resolved-issues-windows-server-2022


Also, the symptoms of that issue look different from ours: there, RDS hangs on user logoff, reportedly due to a deadlock between Remote Desktop and the Local Session Manager, not vhdmp disk resets.


What the failure looks like on our side:


  1. Event 11 in Microsoft-Windows-VHDMP-Operational: a Flush fails with 0xC000009A (STATUS_INSUFFICIENT_RESOURCES).
  2. Then disk event 51 and repeated vhdmp event 129 (reset to device \Device\RaidPort3, which is the virtual adapter shared by all mounted FSLogix containers).
  3. Effectively the VM loses the container disk, but FSLogix still treats it as attached. The resets keep piling up until the whole server hangs.

It happens at random. A server can run fine for a month, or hang after just two days, and we haven’t found any pattern across our servers.


What we ruled out: SAN/multipath on the Proxmox node, load on the file server, Kerberos, MTU, the SMB client, and antivirus (it was disabled during both incidents).


We also updated the VirtIO drivers to 0.1.302 and FSLogix to 26.08 (3.26.826.17182). That didn’t help.
 
Hi,

Thanks to you we made some significant progress and I think our issue is extremely close to yours.
Today two of our 12 RDS Session Hosts hit the 100% CPU / System problem. Interestingly, only those two hosts had VHDMP Operational Event ID 11:


Surface for VHD \\...\Profile_<user>.VHDX is invalidated and will be removed (unsurfaced)
because of a Flush operation failure with status 0xC000009A.
Microsoft maps 0xC000009A to STATUS_INSUFFICIENT_RESOURCES.

We also managed to capture Xperf with kernel stacks during an actual 100% CPU occurrence. The dominant System stack was:

ntoskrnl!ExpWorkerThread
-> vhdmp!VhdmpiExecuteSrbPartsWorkerRoutine
-> vhdmp!VhdmpiProcessParseThreadContext
-> vhdmp!Vhd2StartSrbPart
-> vhdmp!Vhd2ProcessSingleSrbRange
-> vhdmp!Vhd2Flush


only hosts with Event 11 failed today


We've seen this against several unrelated FSLogix user VHDXs, so this does not look like one corrupt profile.

We are fully patched on Windows Server 2022 build 20348.5761 and current FSLogix. We also implemented the recommended AV exclusions and the issue still reproduced.

We haven't proven the initiating root cause yet. What we have proven is that the failure is occurring in the Windows VHD/VHDX processing path and involves VHD flushes failing with STATUS_INSUFFICIENT_RESOURCES.

Arek
 
Hi,Arek K.

Thanks for sharing the Xperf results. The vhdmp!Vhd2Flush stack is very useful and matches what we see from the event logs.


As a temporary workaround until we find the root cause, we’ve decided to schedule a weekly logoff of all users and a reboot of the session hosts. This is not a fix, but it should help keep the hosts stable in the meantime. If the issue stops recurring with weekly reboots, that would also point to something building up over time on the host. I’ll report back once we have a few weeks of results.


Some more details about our environment that might help with comparison:


  • We have only two RDS session hosts for about 60 users, so the load per host is quite high.
  • We have tested several different FSLogix settings, including profile folder redirection with AppData excluded using Copy="3" (copied in at logon and back at logoff), Keep Local Directory, and the reattach retry settings. None of them made a difference.
  • We have a third session host with the same Windows build, FSLogix version and configuration, but only about 6 users. It has never had this problem.
  • That host also runs on different hardware. The two affected hosts are on a Proxmox node with an AMD EPYC 7443P (24 cores), while the unaffected one is on an Intel Xeon E5-2630 v4 (10 cores / 20 threads).

So my feeling is that it’s related to load on the host, but we can’t rule out the hardware or platform difference either.


What CPUs are your Proxmox nodes running? If you’re also on AMD EPYC, that would be an interesting common factor.


If either of us finds the root cause or a working fix, I’d really appreciate it if we could share it here. I’ll do the same.
 
Last edited:
We are running our proxmox host on ADM EPYC 9474F 48-Core
Our RDS farm is quite big and we have 12 Session hosts with total number of users 250 at a peak. The issue is happening to us almost every day, at rush hours. One or two SH must be rebooted due to that issue.

We have been running on same setup for 2 years now with no problems at all and it suddenly started to hit us.
I consider now as a workaround to add 2 another SH to the setup to check if the trigger is not some threshold we started to cross.
 
You must log in or register to reply here.
Top Bottom
Back