I'm having a serious issue with our PVS write cache on Win10 VDI. We're trying to switch from cache on local drive to RAM cache with overflow (512MB ram cache), and the vdiskdif.vhdx is just exploding in size. I've been able to get rid of most of the disk writing, so when the system is idle the cache file doesn't grow, but when I log in, the cache file just explodes again way beyond my profile size. So far, the only thing procmon is turning up has been WebEx logging, and I'm trying to figure out how to either stop that logging or move it. Major changes so far: 1. Disable windows search service (not sure how this had been left enabled 😮 2. Disable the

Connected Devices Platform Service

3. Disable the

Connected Devices Platform User Service

4. Disable the `Connected User Experiences and Telemetry`` 5. Disable the NTFS LastAccess timestamps (another one I couldn't figure how/why it had been left enabled 😮 ) 6. Force the Netskope client logs from

C:\ProgramData

to the writecache disk instead (used a symbolic link) Any suggestions on killing/migrating the WebEx logs, and maybe other things to check? I know we still have some of the eventlogs (other than the big 3) writing to

C:\

.. the big 3 are redirected to the writecache disk.

What about your AV?

We're using CrowdStrike, and we have the right exclusions in place. I didn't see any trace of it writing to disk in procmon.

I have taken to just making the PVS image thin provisioned to the same size as the c:\ between MS updating AppX packages, and backend system microupdates, it has just become the standard.

We have 15gb cache disk and 1024 mb ram cache in our windows 10 environment

Yeah.. our cache disks are 20GB, with the 512MB cache right now. During an idle state, I've got it nailed down (Been watching them for 6 hours, and no change in the cache file).. but it's the logging in right now that is killing it 😞 I've got ~6GB profile, but the cache file will go up to 12+ GB within 10m? I'll be logging in again tomorrow for more

procmon

So far, the only significant thing I've seen writing are the WebEx logs and they're written to the user profile under

$env:localappdata

fslogix?

Turns out that's not going to be an option for us.. Had this discussion with my boss yesterday. It's one of those "this little change" will result in a huge architectural change, and turn 5m thing to do into a 5month project. Split data centers, don't have cross-datacenter storage that's kept in sync, etc. In the long run, I firmly believe we need to go to FSLogix or Citrix' profile container, but that's down the line. (on the plus side, it also means that OneDrive/M365 on the App servers is now officially dead).

I hear you about the AV exclusions, I had also all of them in place with CheckPoints (W16), WC filling up, procmon not showing anything (AV drivers runs at a lower level, it doesn't seem procmon capture them). Guess what, I ditched CheckPoint for Defender, same exclusions and after no more filling cache. If I were you, I would do a PoC with Defender and if the WC is not filling up, work with your AV vendor.

It's been awhile, but when I've troubleshot runaway WC disks in the past, NirSoft's FolderChangesView was gold for tracking down writes easily. We had our UEM run the following on boot/prior to session start

.\Nirisoft\FolderChangesView.exe /Start /BaseFolder "C:\" /MonitorSubfolders 1

By chance are you a SCCM shop? If so, BranchCache reenabling when ever CM was updated used to bite us

We do have SCCM, but it's not allowed to touch the Citrix environment. I got the idle VDI cache disk stable (literally unchanged for 24 hours). What I'm wondering is how other people deal with Win10, PVS (ram cache with disk overflow) and the size of the profiles? So far, whenever the cache is set to that mode, it grows pretty steadily and 3-4 hours, the 20GB WC disk is full and the system has to be rebooted. So far, the only thing I can really come up with is to substantially up the size of the WC disks, and that doesn't seem like a good solution. We don't have this problem when we have the cache set to cache on disk.. it's the RAM w/overflow that kills it.

Did you try to increase your RAM cache? Maybe it's too low. 20GB of WC used in 4h for 1 user is massive! It's the same but I have 48GB of WC for W16, 8 users and it doesn't fill up ot very rarely because user behaviour, bad app. 4GB of RAM cache.

FYI - one thing we've noticed is that newer windows versions have a tendency to update a whole bunch of app store/universal apps at login if the versions on the vdisk are out of date in some way that is hard to determine -- you cannot (AFAIK) stop this and you cannot move the data somewhere else (it has a tendency to go into c:\swapfile for example -- a very poorly named file that cannot be moved off the C drive). The solution would be to treat this like windows updates -- boot a new version of the vdisk in private mode, login and let it settle down before promoting the new version.

So far, switching to the UPM profile containers seems to have stabilized the write cache file. It jumped up to about 2.3GB and then stayed there while I was basically idle on the system. And those Store apps are just a nightmare. We have most of them stripped out, and the store is blocked. Thanks everyone 🙂

Actually with Windows 10 VDI you can use the shared AppX package function. That works really nice as 1 person needs to download it to the store, then everyone else can reference it. Keeps storage even smaller, and works for all the appx packages including teams.