Using VaDump to Look Inside Your Working Set

You may want to get a better understanding of the pieces inside the working set of your application. For example, you might save a lot of code space with the Working Set Tuner only to discover that the code space is only a small portion of your overall working set. In fact, this might even be something you want to do before you go to all the trouble to tune your code.

You probably want to make these measurements on a test computer. Choose a computer large enough to hold your entire working set tuning test scenario in memory. You might need to discover this size through the trial and error process described in this section.

To do this, you can use Virtual Address Dump (VaDump). VaDump looks inside the working set of a process and determines the nature of each page.

Note

Link your application using the -debug and -debugtype:coff options, so you get full use from VaDump.

Create a test scenario for tuning the working set your application.
Start your application.
Start Tlist. VaDump expects the process identifier (PID) of the application to be in decimal. Tlist lists PIDs in decimal form.
Start System Monitor and leave it running. Open a command window so you can run VaDump.
Type the following in the command window, but don't press ENTER yet.
vadump -o -m -p pid > app.vad

The -o option tells VaDump to monitor the working set in the original style, the -m option tells VaDump to use the mapped symbols, and the -p option indicates the process identifier (pid), in decimal, of the process to measure. In the example command line, the output is directed to the file App.vad. Again, do not press ENTER yet.

Flush everything from memory and the disk cache. Running the Clearmem tool a few times generally completes the flush. However, to make sure everything flushes, you may want to watch your working set with System Monitor.
Switch to your application and run the test scenario you devised for tuning the working set.
Switch to the VaDump window and press the ENTER key to run the VaDump command created earlier.

The output from VaDump shows the nature of each page in the working set of your process:

0x00010000 PRIVATE Base 0x00010000
0x00020000 PRIVATE Base 0x00020000
0x0012d000 PRIVATE Base 0x00030000
0x0012e000 PRIVATE Base 0x00030000
0x0012f000 PRIVATE Base 0x00030000
0x00130000 PRIVATE Base 0x00130000
0x00140000 PRIVATE Base 0x00140000
0x00141000 Process Heap
0x00142000 Process Heap
0x00143000 Process Heap
0x00240000 PAGEFILE_MAPPED Base 0x00240000
0x00250000 DATAFILE_MAPPED Base 0x00250000 unicode.nls
0x00251000 DATAFILE_MAPPED Base 0x00250000 unicode.nls
0x00253000 DATAFILE_MAPPED Base 0x00250000 unicode.nls
0x00260000 DATAFILE_MAPPED Base 0x00260000 locale.nls
0x00263000 DATAFILE_MAPPED Base 0x00260000 locale.nls
0x00270000 DATAFILE_MAPPED Base 0x00270000 sortkey.nls
0x002c0000 DATAFILE_MAPPED Base 0x002c0000 sorttbls.nls
0x002d0000 PRIVATE Base 0x002d0000
0x002e0000 PAGEFILE_MAPPED Base 0x002e0000
0x002f0000 PRIVATE Base 0x002f0000
0x01000000 menappl.exe
        (1000) _except_list
0x01001000 menappl.exe
        ( 165) LogDisplayDlgProc@16
        (  24) GetSystemPerfData@16
        ( 1a0) UpdateSystemData@8
        (  1c) MemorySize@4
        (  29) GetObjectDefByTitleIndex@8
        (  14) LogCollecting@4
        ( 113) DrawAlerts@8
        (  d2) DrawLog@8
        (  4c) SmallFileSizeString@8

The page virtual addresses appear on the left. For each section of address space, the base is shown on the right. PRIVATE pages are dynamic data pages that are private to the process. Process Heap pages are dynamically allocated from the process heap. It can be difficult to determine who is using this space, and you might need to look at pointers within your application using the debugger.

The system pages are those allocated for the page tables and for the working set packing list itself. This might be larger than your application actually needs, because VaDump needs to scan them. So use System Monitor as described to determine the difference. For this example, when we looked at the working set of System Monitor while charting, running VaDump added five pages to the working set.

If COFF symbols are included and the module was linked with the -debug flag, other pages that belong to specific modules are indicated by listing which public symbols occur within the page. This helps you to understand why a particular page has been brought into memory. If the module was compiled without the correct flags, you will see only the module name.

Any pages listed as belonging to the module "Error" are pages that did not resolve to a particular module.

You will also find some DATA pages at the upper end of the application's address space. These are for such system-related items as the Process Environment Block, the Thread Environment Blocks, the Per-Thread Data Area, and so on.

Pages in the range starting at 0xC0000000 are page table pages. They are listed showing the range of pages they map, how many of those are in memory (these are called resident pages), and the range of resident pages and their modules.

Finally, there is a summary of pages and who owns them. These pages summarize the pages already listed, so avoid counting them again.

Take a look at System Monitor again and get the new size for your application's working set. This is likely to be larger than before, because VaDump itself must bring some pages into the working set to scan all the page tables and working set entries for your application.
Run the scenario in your application again. System Monitor should get no page faults in your application during this run. If it does, you may not have enough memory on the system to hold your application's working set.