QueryWorkingSet включает неверные страницы в свой результат - PullRequest
Новая
       26

QueryWorkingSet включает неверные страницы в свой результат

2 голосов
/ 27 ноября 2011

В настоящее время я использую 64-битную Windows 7 и Windows 7. Я играю с некоторыми функциями PSAPI (Process Status API), чтобы узнать немного больше о том, как Windows управляет памятью.

Однако я заметил, что QueryWorkingSet содержит записи, из которых я не мог прочитать (например, стр. 0, и вы не можете прочитать 0x00000000). При попытке выполнить 64-разрядную версию стало понятно, почему это так: QueryWorkingSet содержит ошибки в 32-разрядной системе, поскольку адреса усекаются (отсюда и множественные записи на странице 0).

Тем не менее, некоторые записи, возвращаемые QueryWorkingSet в 64-битной системе, также недоступны. Почему эта явно недоступная память отображается как доступная? Это еще одна ошибка в QueryWorkingSet? Кроме того, почему ни один из загруженных модулей не отображается в результате? Разве они не являются частью рабочего набора? прямо указано в MSDN , что они ...

Это небольшой пример программы, которая использует SEH, чтобы попытаться прочитать страницу, и сообщает о странице, когда она не читается (в то время как QueryWorkingSet говорит мне, что это так): 

#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;
}

32-битная версия выдает следующий вывод: 

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

64-битная версия дает это: 

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

1 Ответ

0 голосов
/ 02 января 2012

Я собираюсь предположить, что это связано с недостатками в Native API.K32QueryWorkingSet довольно наивно использует NtQueryVirtualMemory, предполагая, что он может передать результаты как есть, вызывающей стороне.Согласно этой статье , оскорбительные результаты относятся к таблицам страниц и записям рабочего набора, которые отлично читаются из пространства ядра, но не доступны напрямую из пространства пользователя.

Быстрое исправление будеточистить результат, чтобы адреса, найденные ниже MmSystemRangeStart, считались действительными.Это значение может быть прочитано только в режиме ядра, поэтому его нужно «угадать» для приложений пользовательского режима.Для Windows 7 64-bit это 0xFFFF080000000000.Для 32-битных версий это немного сложнее (из-за настройки 4 ГБ), но я не уверен, действительно ли там происходит ошибка.

...