Question

I’m currently using a 64-bit Windows 7 with I’m using Windows 7. I’m playing around with some PSAPI (Process Status API) functions to learn a bit more about how Windows manages memory.

I noticed, however, that QueryWorkingSet included entries from which I couldn’t read (e.g. page 0, and you can’t read 0x00000000). When trying it on 64-bit, it became apparent why this was the case: QueryWorkingSet is bugged on 32-bit, as the addresses are truncated (hence the multiple page 0 entries).

Still, some entries returned by QueryWorkingSet on 64-bit are not accessible either. Why does this obviously inaccessible memory show up as accessible? Is this another bug in QueryWorkingSet? Furthermore, why don’t any of the loaded modules show up in the result? Aren’t they part of the working set? It is explicitly stated on MSDN that they are…

---

This is a small example program that uses SEH to try read the page, and reports the page when it is not readable (while QueryWorkingSet tells me it is):

#include <windows.h>
#include <psapi.h>
#include <stdio.h>

char z;

int main(int argc, char **argv) {
    unsigned int counter;
    HANDLE thisProcess = GetCurrentProcess();
    SYSTEM_INFO si;
    PSAPI_WORKING_SET_INFORMATION wsi_1, *wsi;
    DWORD wsi_size;

    GetSystemInfo(&si);

    wsi_1.NumberOfEntries = 0;
    QueryWorkingSet(thisProcess, (LPVOID)&wsi_1, sizeof(wsi));

#if !defined(_WIN64)
    wsi_1.NumberOfEntries--;
#endif
    wsi_size = sizeof(PSAPI_WORKING_SET_INFORMATION)
             + sizeof(PSAPI_WORKING_SET_BLOCK) * wsi_1.NumberOfEntries;
    wsi = (PSAPI_WORKING_SET_INFORMATION*)HeapAlloc(GetProcessHeap(),
        HEAP_ZERO_MEMORY, wsi_size);

    if (!QueryWorkingSet(thisProcess, (LPVOID)wsi, wsi_size)) {
        printf("# Second QueryWorkingSet failed: %lu\n"
            , GetLastError());
        return 1;
    }

    for (counter = 0; counter < wsi->NumberOfEntries; counter++) {
        unsigned long long page = (unsigned long long)wsi->WorkingSetInfo[counter].VirtualPage;
        DWORD protection = (DWORD)wsi->WorkingSetInfo[counter].Protection;

        __try {
            if (*(char*)(page * si.dwPageSize) || TRUE) {
                z = (protection & 5) ? '-' : 'T';
            }
        } __except(GetExceptionCode() == STATUS_ACCESS_VIOLATION) {
            z = (protection & 5) ? 'F' : '-';
        }

        if (z == 'F') {
            printf("%p %p : %c%c%c%c%c %c\n"
                , (LPVOID)(page * si.dwPageSize)
                , (LPVOID)((page + 1) * si.dwPageSize)
                , protection & 16 ? 'G' : '-'
                , protection &  8 ? 'V' : '-'
                , protection &  4 ? 'w' : '-'
                , protection &  2 ? 'x' : '-'
                , protection &  1 ? 'r' : '-'
                , z
                );
        }
    }

    return 0;
}

The 32-bit version gives the following output:

7DBED000 7DBEE000 : --w-- F
7DBEE000 7DBEF000 : --w-- F
7DC00000 7DC01000 : --w-- F
80008000 80009000 : --w-- F
01080000 01081000 : --w-- F
01000000 01001000 : --w-- F
00000000 00001000 : --w-- F
7DA00000 7DA01000 : --w-- F
40001000 40002000 : --w-- F
003F7000 003F8000 : --w-- F
003FF000 00400000 : --w-- F
003BA000 003BB000 : --w-- F
00001000 00002000 : --w-- F
003B9000 003BA000 : --w-- F
40000000 40001000 : --w-- F
00006000 00007000 : --w-- F
00002000 00003000 : --w-- F
00000000 00001000 : --w-- F
0039A000 0039B000 : --w-- F
003A6000 003A7000 : --w-- F
003A8000 003A9000 : --w-- F
003AC000 003AD000 : --w-- F
00003000 00004000 : --w-- F

The 64-bit version gives this:

FFFFF6FB7DBED000 FFFFF6FB7DBEE000 : --w-- F
FFFFF6FB7DBEE000 FFFFF6FB7DBEF000 : --w-- F
FFFFF6FB7DC00000 FFFFF6FB7DC01000 : --w-- F
FFFFF6FB80008000 FFFFF6FB80009000 : --w-- F
FFFFF70001080000 FFFFF70001081000 : --w-- F
FFFFF70000000000 FFFFF70000001000 : --w-- F
FFFFF70001000000 FFFFF70001001000 : --w-- F
FFFFF7000107F000 FFFFF70001080000 : --w-- F
FFFFF6FB7DA0F000 FFFFF6FB7DA10000 : --w-- F
FFFFF6FB41FFF000 FFFFF6FB42000000 : --w-- F
FFFFF683FFFFF000 FFFFF68400000000 : --w-- F
FFFFF6FB40001000 FFFFF6FB40002000 : --w-- F
FFFFF680003FF000 FFFFF68000400000 : --w-- F
FFFFF6FB7DA00000 FFFFF6FB7DA01000 : --w-- F
FFFFF6FB40005000 FFFFF6FB40006000 : --w-- F
FFFFF68000A00000 FFFFF68000A01000 : --w-- F
FFFFF6FB40000000 FFFFF6FB40001000 : --w-- F
FFFFF68000000000 FFFFF68000001000 : --w-- F
FFFFF680003B9000 FFFFF680003BA000 : --w-- F
FFFFF68000001000 FFFFF68000002000 : --w-- F
FFFFF680003B6000 FFFFF680003B7000 : --w-- F
FFFFF680003B7000 FFFFF680003B8000 : --w-- F
FFFFF683FF7FA000 FFFFF683FF7FB000 : --w-- F
FFFFF683FF7EC000 FFFFF683FF7ED000 : --w-- F
FFFFF6FB41FFB000 FFFFF6FB41FFC000 : --w-- F
FFFFF680003F7000 FFFFF680003F8000 : --w-- F
FFFFF680003BA000 FFFFF680003BB000 : --w-- F

Answer 1

I’m going to assume that this is due to a shortcomings in the Native API. K32QueryWorkingSet uses NtQueryVirtualMemory pretty naively, assuming it can pass the results as-is to the caller. According to this article, the offending results refer to page tables and working set entries, which are perfectly readable from kernel space, but not directly accessible from user space.

A quick fix would be to clean up the result, so that addresses found below MmSystemRangeStart are considered valid. This value can only be read in kernel mode, so it has to be ‘guessed’ for user mode applications. For Windows 7 64-bit, it is 0xFFFF080000000000. For 32-bit versions is a bit more tricky (due to 4GB tuning), but I’m not sure if the bug actually occurs there.