Accurately checking the Citrix PVS “cache in Ram, Overflow to disk” RAM cache size

Citrix_Provisioning_Services_ImplementationCitrix Provisioning services “Cache in RAM, overflow to disk”, even with it’s challenges is something I’ve always felt was a great idea, hell, I foresaw it’s implementation back in 2012!

Not withstanding the issues that can occur when the cache is heavily in use, it’s a great piece of technology. One of the features you see on twitter repeatedly is trying to report on the exact size of the PVS cache in RAM.

Many blogs and scripts (Matt’s here, as an example) will take the raw performance counter details for Non Paged Pool memory and assume this is the size of the cache. This is faulty logic, but close enough. It’s like looking into a can of beans and trying to determine which one gave you gas.

The Non paged Pool is a collective pool of memory used by the system that guarantee’s the services using it (drivers, etc) that the contents will never reach the disk and will always be maintained in memory. As an example, imagine you created your own disk driver, but the disk driver tried to reference it’s memory and it had since been flushed to the disk…. Chicken and Egg stuff!

Microsoft has a fairly clear description here:

The memory manager creates the following memory pools that the system uses to allocate memory: nonpaged pool and paged pool. Both memory pools are located in the region of the address space that is reserved for the system and mapped into the virtual address space of each process. The nonpaged pool consists of virtual memory addresses that are guaranteed to reside in physical memory as long as the corresponding kernel objects are allocated.

So with this in mind, taking a total of the Non Paged Pool memory and assuming it’s PVS is “OK”… But not accurate. Many other sources can bloat that memory cache, particularly in x64 systems where limits on these pools are now enormous compared to the tiny pools we had to deal with in x86 architectures.

Nerdy digression aside, if you REALLY want accurate information on what’s going on inside of this pool. You need to grab a copy of Poolmon from the Windows Driver Kit (WDK). Download the WDK, install it and you’ll find your poolmon in:

C:\Program Files (x86)\Windows Kits\10\Tools\x64\poolmon.exe

Once you have a copy, fire up poolmon and you’ll see in all their glory.


Pro tip: Press “p” once to sort my non pooled, then “b” to sort by bytes used.

Each pool tag and the respective space they are using. Interestingly, the Citrix caching technology seems to use the “VhdR” pooltag allocation. There’s also a Microsoft Pool tag for this ( but the case sensitivity differences between VhdR and VHDr may make all the difference.

I did reach out to Citrix on this one, but they didn’t provide any further insight.

Any-who, if you want to see the size of your PVS cache accurately? Use PoolMon. Here’s a quick script using poolmon to get the GB value back:

$poolmonpath= "d:\poolmon.exe"
$poollog= "$env:temp\poolmon.txt"
if(test-path $poollog){Remove-Item $poollog}
Start-Process-FilePath $poolmonpath -ArgumentList "-n $poollog" -Wait
((Get-Content $poollog | ? {$_ -like "*VhdR*"}) -split "\s+")[6] /1gb
if(test-path $poollog){Remove-Item $poollog}

Related Posts

While using the ShareFile mobile applications, NTF... Here's a weird little bug I caught in the wild while deploying XenMobile Enterprise. While browsing NTFS shares, published as connectors in the ShareF...
UnSticking an AppDisk provisioning task in XenDesk... Here's a wee little bug I've no idea how i created, but managed to clear it out anyway. After creating an AppDisk, it got a little stuck. I tried d...
Cannot Log into XenMobile 10.3 Appliance after ini... Here's a horrendous bug I just came across in the field today while deploying a XenMobile 10.3 Proof...

3 Comments About “Accurately checking the Citrix PVS “cache in Ram, Overflow to disk” RAM cache size

  1. Pingback: Digging into PVS with PoolMon and WPA - Cliff Davies Cliff Davies

  2. Pingback: Citrix Newsletter - September '15 - RUMINATION

  3. Pingback: PvS – Create Devices | Carl Stalhood

Leave a Reply