Updated ATM Tool

Back in the good old days, when Vista was just coming out, I produced a free tool called ATM. ATM poked around inside the kernel to figure out how your RAM was being used and produced a nice pretty graph (along with way too many numbers to understand).

Back in the good old days, when Vista was just coming out, I produced a free tool called ATM.  ATM poked around inside the kernel to figure out how your RAM was being used and produced a nice pretty graph (along with way too many numbers to understand).  The purpose at the time was to look at how RAM was used for the system file cache.  But it turned out to be great at showing what Superfetch was doing as well.   Thanks to a hint in a blog by Alex Ionescu (the new guy on the Windows Internals 5th Edition book) I figured out how to get information on all 7 levels of Standby Cache and have updated the tool, which is now posted on my site at this link: www.tmurgent.com/Tool_ATM.aspx .  Here is a snapshot:

ATM Screenshot

Simply put, the green colors represent RAM that is actively in use, and the other colors represent “available memory”.  Only the darkest blue color at the top is the zero and free memory pools.  All those other colors represent the standby lists.

Vista and above use a seven layer standby list, as opposed to the single standby list in Windows XP, 2003, and before.  Standby Lists are where memory goes that isn't (completely) in use right now, but contains contents that could be used under the right circumstances.  For example, if a process has it's working set reduced, meaning that some of the process memory has been paged out to the pagefile on hard disk, that memory is initially deposited into a standby list.  If the memory is needed, it can be repurposed immediately, but if the process page faults, the OS will find the old copy in memory and restore it to the process without having to go out to disk (a soft page fault as opposed to a hard page fault).

The other big example use of standby lists is on the Desktop versions of the OS where Superfetch is used.  Superfetch watches your long term file access patterns, and attempts to predict which files you will need soon.  It creates "scenarios", which when triggered, cause Superfetch to ask the system file cache to pre-read (on a low priority CPU thread using low priority I/O requests) the files it expects you to want.  These files are placed directly into the Standby Lists until needed.

In the latest Windows Internals book, they describe how Superfetch produces both AM and PM scenarios.  There are some major scenarios, such as logon and hibernation, but they hint to their being scenarios such as if it detects that if I launch program A, then I am likely to launch program B soon also.

Anyway, memory in these systems now have priorities, and the standby lists are ordered by these priorities.  For example, if you leave the disk indexer enabled, file accesses by the indexer will be placed in lower priority memory and placed on the lower priority standby lists when released.  Superfetch will use higher priority lists.  When memory is needed by an application, the system will allocate from the zero and free memory lists first, and then start stealing from the lowest standby list with memory available. 

The highest priority standby list, which I called "StaticPF"  (the names for the standby lists shown in the tool are my own, we don't know what Microsoft calls them!) is a special pool.  Here, Microsoft places files that it has determined should always remain in memory when not used unless pigs really do fly. 

Anyway, take it for a spin!


Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

In case anyone was wondering about the graph, it is a time based monitor with the most recent poll on the right.  About half way through, I shut down outlook, which freed up a bunch of RAM.  Superfetch subsequently started prefetching things for me.  Since I only shutdown outlook to start VMware Workstation or reboot on this machine, I am guessing that is what is being cached.


With regard to SuperFetch, where is this information retained for the user?  Is this held within a profile context?  Thoughts here turn toward session space in TS, and any benefit derived for session performance for the user.  I realize I am reaching  a bit...:-).  Thanks.



The information is not determined nor stored on a per user basis - it is per machine.  It is stored in the files ending with ".db" in the Windows\Prefetch folder.  You will also find the application prefetch (".pf") files stored in that folder.  Again, those files are calculated per machine and not per user.

This is in part why the "layer cake" model for VDI sounds so good, but for now has all of these nasty little things making a good theory be a bad practice (until the tools catch up).


Oh, and as for TS - Supercache does not run on the server builds (although you do have the priority level standby lists).


Version 3.0 of the tool is now available.  Tool now detects bad memory chips and allows clearing of both the file cache and standby lists (for performance testing).