Windows memory की गहराई (भाग 1) — वह क्षण जब virtual address physical RAM बन जाता है: शुरू से अंत तक page fault

VirtualAlloc को MEM_COMMIT देने से उसी क्षण Commit बढ़ता है। Working Set, फिर भी, उतनी ही मात्रा नहीं बढ़ता। तो वह memory कहाँ है जिसे आपने allocate सोचा था?

उत्तर यह है कि अधिकतर pages के पास अभी corresponding physical RAM नहीं है। Windows physical page सौंपना तब तक टालता है जब तक ऐप वास्तव में page को छुए। जब पहली access CPU से page fault उठवाती है, memory manager VAD, PTE, protection attributes और backing store जाँचता है, और ज़रूरत हो तो RAM को एक-एक page बाँधता है।¹

यह लेख उस रास्ते का अनुसरण करता है जो «पहला byte जिसे आप छूते हैं» physical RAM तक चलता है। यदि पहले Working Set और Commit जैसी संख्याओं का अर्थ सुलझाना हो, परिचयात्मक लेख «What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File» देखें। यह श्रृंखला वहाँ प्रयुक्त शब्दों को फिर define नहीं करती; यह mechanism की ओर से खोदती है कि «संख्या वैसी क्यों निकलती है»।

«Windows memory की गहराई» — सभी 3 भाग

1. भाग 1 (यह लेख): virtual address और page fault
   हम देखते हैं कि VirtualAlloc से allocate किया क्षेत्र कब physical RAM पाता है।
2. भाग 2: एक physical page का जीवन
   हम देखते हैं कि Working Set से निकला page Modified, Standby, Free और Zeroed से कैसे चलता है।
3. भाग 3: section object और copy-on-write
   हम देखते हैं कि DLL, file mapping और shared memory physical pages क्यों share कर सकती हैं।

भाग 1 जो प्रश्न हल करता है वह केवल एक है।

Commit हो चुका virtual address किस क्षण physical RAM बनता है?

लक्षित पाठक वे developers और operators हैं जो mechanism से Windows ऐप memory usage, startup के तुरंत बाद page fault, 0xC0000005, तथा VMMap और PerfMon की संख्याएँ समझना चाहते हैं। Prerequisites Windows 10/11 या वर्तमान Windows Server हैं, और आवश्यक पृष्ठभूमि pointer तथा VirtualAlloc की मूल बातें हैं; page-table bit layout या kernel debugger का अनुभव नहीं चाहिए। कठिनाई मध्यम है। हम internal structures के नाम इस्तेमाल करते हैं, पर किसी खास Windows build पर निर्भर undocumented layout नहीं मानते।

1. पहले निष्कर्ष

सामान्य private-memory प्रवाह, एक पंक्ति में, यह है।

Reserve virtual address range अलग रखता है, Commit भविष्य में सामग्री रखने की जगह guarantee देने के लिए सिस्टम की commit limit के विरुद्ध commit charge करता है, और पहली access का page fault physical page सौंपता है।

अर्थात् MEM_COMMIT वह आदेश नहीं जो कहे «अभी RAM allocate करो»। Microsoft का VirtualAlloc दस्तावेज़ भी guarantee देता है कि Commit page की प्रारंभिक सामग्री zero है, और समझाता है कि वास्तविक physical page virtual address तक पहुँच तक नहीं सौंपा जाता।¹

इतना कहकर, यह दावा भी गलत है कि «Reserve/Commit केवल VAD में लिखते हैं»। व्यवहार में Reserve मुख्यतः वह VAD बनाता है जो virtual address range और उसके attributes दर्शाता है, और Commit सिस्टम का Commit Total बढ़ाता है तथा range की commit स्थिति दर्ज करता है। मध्य page-table स्तर और अलग PTE ज़रूरत पर lazy बनते हैं, और physical RAM से अंतिम बंधन आमतौर पर पहली access पर होता है।

Commit खाली वादा नहीं; यह पूरे सिस्टम का वादा है कि सामग्री भविष्य में RAM या उपयुक्त backing store में रखी जा सकेगी। वह entry point जो इस वादे को एक-एक page साकार करता है, page fault है।

flowchart TB
    accTitle: Reserve, Commit और पहली access पर क्या होता है
    accDescr: MEM_RESERVE range और attributes VAD में दर्ज करता है, MEM_COMMIT storage का वादा करने के लिए Commit Total खर्च करता है, और पहली access का page fault physical page सौंपकर Working Set में जोड़ता है
    reserve["1. MEM_RESERVE"] --> commit["2. MEM_COMMIT"]
    commit --> touch["3. पहली access（Touch）"]
    reserve -.-> vad["Range और attributes VAD में दर्ज करें"]
    commit -.-> charge["Commit Total खर्च करें（अभी physical page नहीं）"]
    touch --> fault["Page fault"]
    fault --> zero["Zero किया physical page PTE से बाँधें"]
    zero --> ws["Working Set में जोड़ें और instruction फिर चलाएँ"]

चित्र 1: Reserve, Commit और Touch अलग घटनाएँ हैं। Physical RAM केवल अंतिम चरण, पहली access, पर बाँधी जाती है।

2. तीन ledgers जो virtual page का पीछा करते हैं

Virtual address से physical RAM तक का रास्ता समझने के लिए Windows के तीन ledgers को अलग करना चाहिए।

VAD range की जानकारी रखता है, PTE virtual page की, और PFN database physical page की। Page-fault handler इन्हें मिलाकर तय करता है कि access जारी रह सकती है या नहीं।

flowchart TB
    accTitle: Virtual address से physical RAM तक तीन ledgers
    accDescr: Virtual address को VAD range granularity पर और PTE virtual-page granularity पर संभालता है, और PFN database PTE के translation target physical page को physical-page granularity पर track करता है
    va["Virtual address"] --> vad["VAD（range ledger）"]
    va --> pte["PTE（virtual-page ledger）"]
    vad -.->|Reserve/Commit और protection आँकें| pte
    pte -->|Valid translation| pfn["PFN database（physical-page ledger）"]
    pfn --> ram["Physical RAM page"]

चित्र 2: अलग granularity के तीन ledgers। Fault handling VAD और PTE मिलाता है, फिर परिणाम PFN पक्ष पर दर्शाता है।

इस लेख के नायक VAD और PTE हैं। PFN database को हम भाग 2 में physical-page पक्ष से देखेंगे।

3. Reserve, Commit और Touch अलग घटनाएँ हैं

3.1. Reserve — एक address दावा करना

पहले, 256MiB की contiguous virtual address range reserve करें।

void* base = VirtualAlloc(
    nullptr,
    256ull * 1024 * 1024,
    MEM_RESERVE,
    PAGE_NOACCESS);

इस बिंदु पर केवल यही हुआ कि process के virtual space में एक address अलग रखा गया ताकि अन्य allocations इस range का उपयोग न कर सकें। MEM_RESERVE RAM या pagefile में कोई physical storage नहीं सौंपता।¹

क्योंकि 64-bit process का virtual space बहुत बड़ा है, पहले बड़ी range Reserve करना और बाद में केवल ज़रूरी भाग Commit करना व्यावहारिक हो जाता है।

3.2. Commit — वादा कि रखा जा सकेगा

फिर reserved range को Commit करें।

void* committed = VirtualAlloc(
    base,
    256ull * 1024 * 1024,
    MEM_COMMIT,
    PAGE_READWRITE);

सफलता पर वह वादा की गई मात्रा बढ़ती है जो सिस्टम के Commit Total — और आमतौर पर process के Private Bytes — में झलकती है। फिर भी 256MiB physical pages एक साथ नहीं खड़े होते। सामान्य pages पहली access तक physically unsassigned रहते हैं।¹²

तो Commit का मतलब क्या है? यह कि जब सिस्टम वादा नहीं ले सकता, वह Commit के समय failure लौटा सकता है, memory इस्तेमाल के बीच में नहीं।

3.3. Touch — जब physical page आवश्यक हो जाता है

अंत में, निम्नलिखित assignment पहली बार पहले page पर लिखता है।

static_cast<unsigned char*>(base)[0] = 1;

CPU virtual address को physical address में translate करने की कोशिश करता है, पर PTE के पास अभी physical page का valid translation नहीं है। यहाँ page fault होता है।

Control पाने वाला memory manager इसे «Commit और writable private page पर पहली access» मानता है, zero किया physical page लेता है, PTE से बाँधता है, और Working Set में जोड़ता है। फिर वह failed write instruction फिर चलाता है।

ऐप से यह साधारण assignment लगता है, पर भीतर assignment के बीच control kernel में जाता है, physical page सौंपा जाता है, और execution उसी instruction पर लौटता है।

4. VAD — virtual space का range ledger

VAD का मतलब Virtual Address Descriptor है, और Windows process की उपयोग में address ranges को VAD के tree के रूप में संभालता है। WinDbg के !vad से आप start और end VPN, Commit, protection attributes, Private/Mapped, Control Area और और भी देख सकते हैं।³

VAD जो representative जानकारी दर्ज करता है उसमें ये शामिल हैं।

• Address range का start और end
• Type, जैसे Private, Mapped या Image
• Reserve/Commit स्थिति
• Read, write, execute और copy-on-write जैसी protection
• File या section से association
• Guard page जैसे special attributes

Range से संभालने का कारण efficiency है। 256MiB 4KiB पर 65,536 pages हैं। हर page के लिए पहले से पूर्ण management structure बनाने के बजाय, VAD में «यह contiguous range एक reservation है» रखना और ज़रूरत पड़ने पर page realize करना कम waste है।

4.1. VAD मिलना recovery की guarantee नहीं

«यदि VAD में है तो fault resolve होता है; नहीं तो access violation» सुविधाजनक प्रारंभिक व्याख्या है, पर oversimplified है। VAD मिलने पर भी सामान्य access इन जैसे मामलों में जारी नहीं रह सकती।

• केवल Reserve, और लक्ष्य page Commit नहीं
• PAGE_NOACCESS
• Read-only page पर write
• Non-executable page से instruction चलाना
• Guard page का पहला touch
• Section की valid range से बाहर touch

उलटा, भले PTE invalid हो, यदि VAD और PTE की software स्थिति valid access दिखाए, तो demand-zero, Transition restore, page-in या CoW से resolve किया जा सकता है। अधिक सटीक उत्तर है VAD, PTE, protection attributes और access type साथ आँकें।

5. Page table और TLB

ऐप जो pointer रखता है वह virtual address है। CPU के RAM तक पहुँचने के लिए virtual page number को physical page number में translate करना होगा। वह hierarchical translation table page table है, और leaf entry PTE (Page Table Entry) है।

Valid PTE अवधारणात्मक रूप से PFN, read/write/execute protection, user-mode permission, Accessed/Dirty और ऐसी जानकारी रखती है। वास्तविक bit layout CPU और Windows version पर निर्भर है।

हर बार page table walk करना बहुत धीमा होगा, इसलिए CPU हाल के translations TLB (Translation Lookaside Buffer) में cache करता है। Address translation इस क्रम में चलता है।

1. यदि TLB में translation है और access उस protection से मेल खाती है, वह परिणाम प्रयुक्त होता है।
2. यदि TLB में translation नहीं, CPU page table walk करता है।
3. यदि valid PTE है और protection भी मेल खाती है, वह TLB में दर्ज होती है और execution जारी रहता है।
4. यदि valid translation नहीं, या protection violation है, control page-fault entry point पर जाता है। Protection check तब भी होती है जब translation TLB से आया हो।

जैसा यह प्रवाह दिखाता है, TLB miss और page fault अलग चीज़ें हैं। यदि एकमात्र समस्या यह है कि TLB में translation नहीं और PTE valid है, केवल page-table walk होता है। उलटा, भले TLB में translation हो, read-only page पर write या non-executable page पर instruction चलाना जैसा protection violation page-fault entry point पर जाता है। इसलिए CoW page पर write fault कर सकता है भले translation पहले से cache हो।

flowchart TB
    accTitle: Address-translation प्रवाह और page-fault entry point
    accDescr: भले TLB में translation हो, protection mismatch page-fault entry point पर जाता है। यदि TLB में translation नहीं तो page table चली जाती है; valid PTE जो protection से भी मेल खाए TLB में दर्ज होती है और execution जारी रहता है, और invalid translation या protection violation page-fault entry point पर जाता है
    access["Memory access"] --> tlb{"क्या TLB में translation है?"}
    tlb -->|हाँ| perm{"क्या access protection से मेल खाती है?"}
    perm -->|मेल| go["उस translation से जारी रखें"]
    perm -->|Protection violation| entry["page-fault entry point पर"]
    tlb -->|नहीं| walk["Page-table walk"]
    walk --> valid{"Valid PTE और protection भी मेल?"}
    valid -->|हाँ| register["TLB में दर्ज करें और जारी रखें（कोई fault नहीं）"]
    valid -->|Invalid या protection violation| entry

चित्र 3: TLB miss page-table walk से resolve हो सकता है। Control page fault पर जाता है जब translation invalid हो या protection violation हो, और protection violation TLB hit पर भी होता है।

5.1. Invalid PTE केवल खाली नहीं

Invalid PTE भी खाली नहीं। Invalid PTE की software स्थिति से Windows ये जैसे मामले अलग करता है।

• Demand-zero page जो कभी realize नहीं हुआ
• Transition page जो RAM में रहता है
• Shared page जो Prototype PTE का reference देता है
• Pagefile में सहेजा private page
• Protection violation या invalid क्षेत्र

CPU का काम केवल यह तय करना है «यह सामान्य valid translation नहीं» और kernel को सौंपना; अर्थ वहाँ से memory manager देता है।

6. शुरू से अंत तक एक page fault

Commit private page पर पहली write को छह चरणों में देखें।

1. CPU लिखने की कोशिश करता है।
   वह TLB और page table जाँचता है, पर लक्ष्य PTE के पास valid PFN नहीं।
2. CPU page fault उठाता है।
   वह fault वाले virtual address, read/write/execute type, user/kernel, और समस्या translation की कमी है या protection violation, kernel को देता है।
3. Memory manager VAD और PTE जाँचता है।
   वह तय करता है कि page Commit है या नहीं, protection मेल खाती है या नहीं, और demand-zero, Transition, shared, page-in, CoW या exception में से कौन लागू है।
4. यदि demand-zero है, zero किया physical page लिया जाता है।
   नया सौंपा page zero होना चाहिए ताकि दूसरी process का data न leak हो।
5. PTE और PFN management जानकारी update होती है।
   PTE में PFN और protection set होते हैं, physical page Active बनता है, और process के Working Set में जुड़ता है।
6. Failed instruction फिर चलता है।
   क्योंकि fault सामान्य resolve, कोई user-mode exception नहीं दिया जाता, और ऐप assignment सामान्य जारी रखता है।

ETW page-fault events Transition, Demand Zero, Copy-on-Write, Guard Page, Hard Page Fault और Access Violation को अलग types के रूप में भी दर्ज करती हैं।⁴

इसलिए page fault शुरू से «abnormal» का शब्द नहीं। यह shared entry point है जब CPU सामान्य पथ पर translation नहीं कर सका तो OS से निर्णय माँगने का।

flowchart LR
    accTitle: Page-fault resolutions की शाखा
    accDescr: Memory manager VAD, PTE, protection attributes और access type आँकता है, और demand-zero, RAM में बचे page को फिर जोड़ना, backing store से hard fault, copy-on-write, guard-page notification या exception पर भेजता है
    faultIn["Page fault होता है"] --> judge["VAD, PTE, protection, type आँकें"]
    judge -->|पहली access| dz["Demand-zero（soft）"]
    judge -->|अभी RAM में| soft["Standby से फिर जोड़ें（soft）"]
    judge -->|Disk पढ़ना चाहिए| hard["Hard fault（disk I/O）"]
    judge -->|CoW write| cow["Copy करें और PTE बदलें"]
    judge -->|Guard page| guard["Guard हटाएँ और notify करें"]
    judge -->|Unresolved| av["Exception（0xC0000005 आदि）"]

चित्र 4: एक ही entry point से आए faults आँकने के अनुसार छह परिणामों में बँटते हैं। Guard page विवरण खंड 9 में हैं।

7. Demand-zero — soft fault जो disk नहीं पढ़ता

Demand-zero वह representative soft fault है जो Commit private page पहली बार छूने पर होता है। Microsoft का Working Set दस्तावेज़ «process allocated virtual page का पहली बार reference देती है» को भी soft fault का उदाहरण मानता है।⁵

Demand-zero की ये विशेषताएँ हैं।

• Disk से original data पढ़ने की ज़रूरत नहीं
• प्रारंभिक सामग्री zero है
• Available physical page बाँधा जाता है
• Working Set और cumulative Page Fault Count बढ़ते हैं
• अकेले यह handling Memory\\Pages Input/sec नहीं बढ़ाता

इसीलिए startup के तुरंत बाद Page Faults/sec का उछाल अपने आप यह नहीं कहता कि storage bottleneck है।

Lazy allocation का trade-off भी सुलझाना चाहिए। यदि आप 256MiB Commit करें और वास्तव में केवल 8MiB इस्तेमाल करें, शेष 248MiB को RAM से बाहर छोड़ना उचित है। बदले में पहली access fault handling की लागत उठाती है। Latency-sensitive काम के लिए एक डिज़ाइन है जो शुरू से पहले हर page छूकर prefault करता है, पर वह trade-off है जो पहले से RAM residency बढ़ाता है।

8. Soft fault और hard fault

8.1. Soft fault

Soft fault वह fault है जो backing store पर पढ़ने I/O के बिना resolve हो सकता है। Representative उदाहरणों में ये शामिल हैं।

• Demand-zero
• Standby/Transition पर बचे page को फिर जोड़ना
• दूसरे process के Working Set में shared page जोड़ना
• पहले से लाए page को जोड़ना
• Copy-on-Write जिसका original page resident है

Kernel transition, locks, PTE/PFN updates, TLB coherence आदि की CPU लागत अभी भी है, पर storage wait नहीं।⁵

8.2. Hard fault

दूसरी ओर, जब ज़रूरी page RAM में कहीं नहीं और backing store से पढ़ना हो, वह hard fault है। पढ़ने का स्रोत केवल pagefile नहीं।

• Pagefile में लिखा private page
• Memory-mapped file
• EXE या DLL image
• File cache द्वारा referenced data file

ETW HardFault events में FileObject, ReadOffset और ByteCount हैं, इसलिए वास्तविक पढ़ने स्रोत track किया जा सकता है।⁶

इसलिए Hard Fault = pagefile.sys का पढ़ना सत्य नहीं।

जब backing-store पढ़ना चाहिए, request Windows I/O stack में जाता है। IRP और issue/completion का प्रवाह «The Depths of Windows I/O (Part 1)» में है, और file cache से जोड़ «The Depths of Windows I/O (Part 4)» में है। यदि page RAM में है memory manager स्वयं लौट सकता है; यदि नहीं, वह I/O issue करता है और completion तक fault thread की प्रतीक्षा करता है।

9. Unresolved fault exception बनता है

वह fault जो VAD और PTE जाँचने के बाद valid allocation, page-in या CoW के रूप में resolve न हो सके, user mode को exception के रूप में दिया जाता है।

Representative मामला STATUS_ACCESS_VIOLATION है, exception code 0xC0000005। यह invalid address के पढ़ने, लिखने या execute पर होता है; पहला exception parameter access type बताता है और दूसरा violation address।⁷

विशिष्ट पैटर्न में ये शामिल हैं।

• NULL, freed address या array से बाहर address पढ़ना
• Read-only page पर लिखना
• उस page से instruction चलाना जिसे DEP/NX ने non-executable बनाया
• Reserved पर Commit न की range छूना

PAGE_GUARD का अर्थ थोड़ा अलग है। यह access की one-shot notification है: यह STATUS_GUARD_PAGE_VIOLATION उठाता है और stack growth जैसी चीज़ों के लिए प्रयुक्त होता है।⁸

सामान्य lazy allocation, page-in, CoW, guard notification और अंतिम access violation CPU की दृष्टि से एक ही page-fault entry point पर इकट्ठा होते हैं। परिणाम तय करने वाला VAD, PTE, protection attributes और access type का संयोजन है।

10. स्वयं देखें

अब तक का प्रवाह अपनी मशीन पर देखा जा सकता है। निम्नलिखित C++ program 256MiB Reserve करता है, Commit करता है, हर page पर एक byte लिखता है, और अंत में Release करता है। हर चरण पर Enter की प्रतीक्षा करता है ताकि आप VMMap और PerfMon में बदलाव देख सकें।

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <psapi.h>

#include <cstdio>
#include <cstdlib>

#pragma comment(lib, "Psapi.lib")

constexpr SIZE_T kSize = 256ull * 1024 * 1024;

void PrintMemory(const char* stage)
{
    PROCESS_MEMORY_COUNTERS_EX c{};
    c.cb = sizeof(c);
    if (!GetProcessMemoryInfo(
            GetCurrentProcess(),
            reinterpret_cast<PROCESS_MEMORY_COUNTERS*>(&c),
            sizeof(c))) {
        std::printf("GetProcessMemoryInfo failed: %lu\n", GetLastError());
        return;
    }

    std::printf(
        "%-10s WS=%zu MiB  Private=%zu MiB  Faults=%lu\n",
        stage,
        c.WorkingSetSize / 1024 / 1024,
        c.PrivateUsage / 1024 / 1024,
        c.PageFaultCount);
}

void Pause(const char* message)
{
    PrintMemory(message);
    std::puts("Press Enter...");
    (void)std::getchar();
}

int main()
{
    SYSTEM_INFO si{};
    GetSystemInfo(&si);
    std::printf("PID=%lu, page=%lu bytes\n",
                GetCurrentProcessId(), si.dwPageSize);

    void* base = VirtualAlloc(nullptr, kSize, MEM_RESERVE, PAGE_NOACCESS);
    if (!base) {
        std::fprintf(stderr, "Reserve failed: %lu\n", GetLastError());
        return EXIT_FAILURE;
    }
    Pause("reserved");

    if (!VirtualAlloc(base, kSize, MEM_COMMIT, PAGE_READWRITE)) {
        std::fprintf(stderr, "Commit failed: %lu\n", GetLastError());
        VirtualFree(base, 0, MEM_RELEASE);
        return EXIT_FAILURE;
    }
    Pause("committed");

    auto* bytes = static_cast<volatile unsigned char*>(base);
    for (SIZE_T offset = 0; offset < kSize; offset += si.dwPageSize) {
        bytes[offset] = 1;
    }
    Pause("touched");

    if (!VirtualFree(base, 0, MEM_RELEASE)) {
        std::fprintf(stderr, "Release failed: %lu\n", GetLastError());
        return EXIT_FAILURE;
    }
    Pause("released");
}

Visual Studio के x64 Native Tools Command Prompt से निम्नलिखित command से बनाया जा सकता है।

cl /std:c++20 /EHsc /W4 memory_fault_demo.cpp

10.1. VMMap में क्या देखें

VMMap वह tool है जो reserved virtual memory, Commit, Working Set, Private और Shareable type के अनुसार दिखाता है।⁹ हर चरण पर अपेक्षित बदलाव ये हैं।

वास्तविक संख्याएँ runtime, security products, memory pressure और देखने के समय से बदलती हैं। देखें चरणों के बीच संख्याएँ किस ओर गईं, यह नहीं कि ठीक 256MiB निकलीं या नहीं।

10.2. PerfMon में soft और hard अलग करना

PerfMon में निम्नलिखित counters उसी time axis पर रखें।

• Process(<target>)\\Page Faults/sec
• Memory\\Pages Input/sec
• Memory\\Page Reads/sec
• Memory\\Available MBytes
• Process(<target>)\\Working Set - Private
• Process(<target>)\\Private Bytes

Process\\Page Faults/sec में soft और hard दोनों faults हैं। Memory\\Pages Input/sec दूसरी ओर hard fault resolve करने के लिए disk से पढ़े pages की संख्या है।¹⁰

इस program के Touch चरण में Page Faults/sec कूदना चाहिए जबकि Pages Input/sec ज़्यादा नहीं बढ़ना चाहिए। नए Commit pages demand-zero से realize होते हैं, इसलिए disk से original data पढ़ने की ज़रूरत नहीं।

जब कई processes एक नाम share करें, PerfMon संख्याएँ जैसे process#1 restart पर बदल सकती हैं। PID दिखाने वाले counter से मिलाएँ, या Process V2 या ETW/WPA से PID से पहचानें।

11. व्यवहार में बचने योग्य तीन गलत पढ़त

11.1. «Commit बढ़ा, इसलिए RAM leak है»

Commit रखने योग्य सामग्री की वादा की गई मात्रा है; न छुए pages RAM में resident नहीं हो सकते। Leak आँकने के लिए Private Bytes की time series, allocation का breakdown, और processing खत्म होने के बाद संख्या baseline पर लौटती है या नहीं देखें।

11.2. «Page Faults/sec ऊँचा है, इसलिए disk धीमी है»

Soft fault में disk I/O नहीं होता। Page Faults/sec, Pages Input/sec और storage wait अलग करें, और ज़रूरत हो तो ETW HardFault events से स्रोत file और stack का पीछा करें।

11.3. «Working Set खाली करने से leak ठीक होगा»

Working Set से pages निकालना Commit या ownership नहीं छोड़ता। Page Standby या Modified में जाता है और बाद में फिर fault करके आता है। Leak ठीक करने के लिए allocator को VirtualFree, heap free, object destruction आदि करना चाहिए।

वह निकला physical page कहाँ जाता है, हम भाग 2 में देखते हैं।

12. सार

• MEM_RESERVE virtual address range अलग रखता है पर RAM या pagefile में physical क्षेत्र नहीं सौंपता।¹
• MEM_COMMIT Commit खर्च करता है और guarantee देता है कि सामग्री भविष्य में रखी जा सकेगी, पर सामान्य physical page पहली access तक नहीं सौंपा जाता।¹²
• VAD range ledger है, PTE virtual-page ledger, और PFN database physical-page ledger।
• TLB miss page fault नहीं। यदि PTE valid है, केवल page-table walk सुलझा देता है।
• Demand-zero, Transition restore और shared page जोड़ना soft faults हैं जो बिना disk I/O resolve हो सकते हैं।⁵
• यदि pagefile, DLL, EXE या mapped file से पढ़ना चाहिए, वह hard fault है।⁶
• यदि VAD, PTE और protection attributes की जाँच fault न सुलझाए, आपको 0xC0000005 जैसा exception मिलता है।⁷
• Performance फैसले के लिए केवल Page Faults/sec न देखें; उसी time axis पर Pages Input/sec, Available, Working Set, Private Bytes और storage wait देखें।

जारी भाग 2, «एक physical page का जीवन: पाँच lists और pagefile की सच्चाई»।

Commit वादे के physical page बनने के बाद, हम देखते हैं कि Working Set छोड़ने पर वह page कहाँ जाता है, PFN database और page lists से।

संबंधित लेख

• What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File
• The Depths of Windows I/O (Part 1) — Every Read and Write Becomes an IRP: The Big Picture of the I/O System
• The Depths of Windows I/O (Part 4) — Cache Manager: When Does Your WriteFile Actually Reach the Disk?
• Reading Crash Dumps with WinDbg + SOS — A Practical Guide to Analysis After Collection
• An Introduction to Collecting Windows Crash Dumps - WER/ProcDump/WinDbg

संबंधित परामर्श क्षेत्र

KomuraSoft LLC Windows application memory usage, access violation, startup delay, paging और native code defects की जाँच संभालती है।

• Windows ऐप विकास
• बग और कारणों की जाँच
• मौजूदा संपत्तियों का पुनरुपयोग और माइग्रेशन
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

VirtualAlloc को MEM_COMMIT देने से उसी क्षण RAM allocate हो जाती है?

सामान्य private memory में Commit सिस्टम की commit headroom खर्च करता है, पर corresponding physical page पहली access तक नहीं सौंपा जाता। लिखकर पहली बार छुए गए page को demand-zero fault के दौरान physical page मिलता है।

क्या page fault का मतलब कुछ गलत है या performance समस्या है?

नहीं। बिना disk I/O वाले soft fault — जैसे demand-zero या Standby से page लौटाना — सामान्य operations हैं। Performance के फैसले के लिए केवल Page Faults/sec नहीं, Pages Input/sec, storage wait और Available MBytes भी देखें।

क्या TLB miss और page fault एक ही चीज़ हैं?

वे अलग हैं। भले TLB में translation न हो, यदि page table की PTE valid है तो CPU केवल table walk करता है और translation फिर दर्ज करता है। जब PTE invalid हो या protection violation हो तब यह page-fault entry point पर जाता है।

यदि address range VAD में है तो access violation नहीं हो सकता?

ज़रूरी नहीं। VAD होने के अलावा memory manager Reserve बनाम Commit, read/write/execute protection, guard page, PTE state और और भी बातें आँकता है। यदि fault resolve न हो सके तो आपको 0xC0000005 जैसा exception मिलता है।

ऊँचा Page Faults/sec मतलब सिस्टम में RAM कम है?

केवल इससे नहीं पता चलता। Page Faults/sec में बहुत से soft faults भी शामिल हैं। इसे उसी time axis पर Memory\Pages Input/sec, Memory\Page Reads/sec, Available MBytes और disk wait time से जोड़ना चाहिए।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।