Discussion on Windows 2000 / XP Pagefile Organization Management
Webcrazy (http://webcrazy.yeah.net)
The system memory resource is relative to disk space. Because of the virtual memory mechanism, we can have a relatively rich address resource (usually 32bit virtual addresses, 4G addressing space), and these resources are always more than enough for physical memory. So in the modern operating system, some strategies are always used in relatively nervous, such as FIFO, LRU, etc. Place some pages of physical memory into relatively inexpensive disk space resources. A general Unix system, use a partition independently, namely Swap Partition. And this regard of Windows is just using ordinary files, usually named PageFile.sys, located in the root of each partition. Windows can support up to 16 PageFile.sys can be supported due to restrictions on PTEs used for PageFile (4bit to identify the PAGEFILE of the operation).
From the above description, PageFile.sys itself is a relatively special file, which is scalable depending on the system, usually we can use the "control panel" "system" small applet. Due to its specialty, Windows will establish the corresponding file_object for each PageFile.sys in the startup phase, and set the sharedread field to false, and in the System process, each file_object has a handle pointing, which is only allowed to be Its operation avoids the user to delete it.
In order to manage PageFile.sys, there is an array of lengths 16 in Windows for organizations for PageFile.sys. Each member corresponds to a PageFile. This array is directed by system variable MmpagingFile, each member is a structure pointing to Mmpaging_File, which has the following format:
0x000 Size: UINT4B
0x004 Maximumsize: uint4b
0x008 minimumsize: uint4b
0x00c FreeSpace: uint4b
0x010 CURRENTUSAGE: UINT4B
0x014 peakusage: uint4b
0x018 hint: uint4b
0x01c highestpage: uint4b
0x020 Entry: [2] PTR32 _MMMOD_WRITER_MDL_ENTRY
0x028 Bitmap: PTR32 _RTL_BITMAP
0x02c file: ptr32 _file_Object
0x030 PageFileName: _unicode_string
0x038 PageFileNumber: uint4b
0x03c extended: uchar
0x03D HintSettozero: uchar
0x03e bootpartition: uchar
0x040 FileHandle: PTR32 VOID
Through this structure, we can easily get the use of the corresponding PageFile (Maximumusage, Peakusage, see Windbg! VM Command), which corresponds to File_Object, etc. In addition, through File_Object's DeviceObject and VPB field, we can know the file system and other information such as the partition and partitions used in this PageFile. Let's introduce the Bitmap member. Bitmap is a structure of RTL_bitmap, which is defined in NTDDK.H:
Typedef struct _rtl_bitmap {
Ulong sizeofbitmap; // number of bits in bit map
Pulong buffer; // Pointer to the bit map itself
} RTL_bitmap;
Like the page frame database (PFN Database), like virtual memory (X86 platform Page_SIZE 4K), Windows also splits PageFile into a size of 4K block, called a page, each page is specified by Bitmap. 1 is occupied, 0 is idle. Find the unused page of these files by using RTLFindClearBits or RTLFindClearBitsAndset. Although Bitmap indicates that the Windows is often 4K, but in order to improve performance, Windows is usually 64K (MMModifiedWriteClustersize page). There is MMMOD_WRITER_MDL_ENTRY, and then explain it when I mention the relevant content below.
First use Windbg to digest the discussion above:
KD> DD MMPAGINGFILE L 10 // From the output result, you can see that I have two PageFiles on my machine.
80547020 80d2af80 feec1548 00000000 00000000
80547030 00000000100000000000000000000000
80547040 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
80547050 000000000000000000000000000000000000000000000000000000000000000000000000000000
KD> DD @ $ p1 40 // The case of the first PageFile.
80D2AF80 00006400 0000C800 00006400 0000c38
80D2AF90 000057C7 000057C7 000000 00000000
80D2afa0 feEA1CB8 Feea1c18 fecb000 feddc428
.
.
.
KD> DD FEDDC428 L 4 // The mmpaging_file given from above is easy to get File Object (Offset 0x2c).
FEDDC428 00700005 80ECF2F0 80ECF268 Fee66C10
KD>! DEVOBJ 80ECF2F0 // AFILE_Object is given in NTDDK.H, and its third DWORD is Device_Object.
Device Object (80ecf2f0) is for:
HarddiskVolume2 / driver / ftdisk driverObject 80d97030
Current IRP 00000000 REFCOUNT 1316 TYPE 00000007 Flags 00001150
VPB 80ecf268 DACL E13D1484 Devext 80ecf3a8 DevObjext 80ecf490 Dope 80ecf210 DevNode 80D95BD0EXtensionFlags (0000000000)
AttachedDevice (Upper) 80D954B8 / Driver / Volsnap
Device queue is not busy.
In addition, the fourth DWORD (FeE66C10) of File_Object is the VPB structure, you use! VPB analysis analysis, limited to space, I will not listed here.
Through the analysis of WindBG above, we have basically a certain understanding of PageFile, which is transferred to the Organization management of the memory series and the IO subsystem (call FSD) to PageFile.
Typically, for the process, it is always a virtual address, accessing a virtual address, for the unsatisfactory address (for x86, the P bit of the PTE is 0), by triggering hardware interruption (x86 is int E), These PTEs are parsed by software, such as prototype PTE (I am introduced in "exploring Windows 2000 / XP prototype PTE"), or transition PTE (transition PTE, some pages due to process work set repair, etc. The page being used, but the content of these pages is still valid for these processes. You can reuse it at any time, so Windows uses Transition This term is different from the pure Free or Zeroed list, I am in "Resolving WinNDOWS 2000 / XP Physical Memory Management" Referral to the PFN list), etc.
So let's explain the PageFile PTE before continuing to discuss, its format is as follows:
Valid: POS 0, 1 bit
PageFilelow: POS 1, 4 BITS
Protection: POS 5, 5 BITS
Prototype: POS 10, 1 Bit
Transition: POS 11, 1 Bit
PagefileHigh: POS 12, 20 bits
For Prototype PTT and Transition PTE, there are always 1 bit to identify the corresponding PTE, such as the prototype field, but for the PageFile PTE, there is no corresponding identification bit, actually MidispatchFault (called Kitrap0e), is parsing Prototype PTE MiResolveProtoPteFault), Transition after PTE (MiResolveTransitionFault), as well as MiResolveDemandZeroFault, just call MiResolvePageFileFault, of course, in MiResolveProtoPteFault processing and final call of MiResolvePageFileFault.
Suppose we have access to a page that is currently residing in the pagefile. After transferring the MIDISPATCHFAULT, the control is transferred to MIRESOLVEPAGEFAULT, he will index the mmpaging_file array according to PTE PageFilelow, ie, which PageFile.SYS is determined, because PageFileLow is 4 bits, so Windows can support up to 16 PageFile.sys. Such a memory subsystem removes this PageFile's file_object (described above) from the page file structure described in MmpagingFile according to this index. Plus the offset value of the PageFile.sys specified by PagefileHigh, MIRESOLVEPAGEFAULT Note this page by returning a special NTSTATUS that is 0xc0033333. The prototype of IOPAGEREAD is as follows (defined in ntifs.h): NTkernelapi
NTSTATUS
IopageRead
In Pfile_Object FileObject,
In Pmdl MemoryDescriptorList,
In Plarge_integer Startingoffset,
In Pkevent Event,
OUT PIO_STATUS_BLOCK IOSTATUSBLOCK
);
Of course, before calling IOPAGEREAD, the memory manager must allocate a physical page. When necessary, call Miremove AnPAGE to make a space, then call miinitializeReadInProgressPFN, set this page into the ReadInProgress status, then put the MDL parameter required for IOPAGEREAD MDL parameter MemoryDescriptorList points This page. MDL's virtual address fields are also virtual addresses of page mapped by IOPAGEREAD, i.e., met the page errors we have previously assumed.
IOPAGEREAD actually passes an IRP with allocate, using Direct_io's way (ie we provide MDL), then sets a Complete Routine to cancel the ReadinProgress status before reading, and then call the IOCallDriver call IO subsystem call the corresponding File System Driver (It is usually determined by the File_Object's VPB parameter), as for how FSD reads PageFile.sys, this is not discussed, the source code of the Fastfat provided by NTIFS is the direction of learning.
What needs to be pointed out is that IOPAGEREAD is a synchronous operation, that is, it can be processed down after waiting for the page reading. This is also the main reason why MIDISPATCHFAULT can only run under Dispatch_level IRQL. IOPAGEREAD is synchronized by the flag of IRP_Synchronous_Paging_io assigned by the device. In addition, he also sets IRP_PAGING_IO, IRP_NOCACHE logo for special communication requirements between FSD.
Due to the needs of work set, the MIMODIFIEDPAGEWRITER (MPW) thread is implemented in Pagefile. MPW use _MMMOD_WRITER_MDL_ENTRY type of MMPAGING_FILE structure Entry to operate, _MMMOD_WRITER_MDL_ENTRY not only used by MiModifiedPageWriter, he also let MiMappedPageWriter use (for Mapped file), so _MMMOD_WRITER_MDL_ENTRY structure not only has a letter MDL members, also includes Control Area, and so on. Limited to the space, I don't list it. MPW writes the page in front of the MMModifiedWriteClustersize page that is previously described in front of the MMModifiedWriteClustersize page. IRP FLAG used for IoasynchronouSpageRead is IRP_Paging_IO and IRP_NOCACHE, indicating that he is asynchronous. This can also be seen from his name, distinguishing another related process IOSYNCHRONOUSPAGEWRITE provided by Windows, he is synchronized. Tell this, some basic impressions managed for the organization of Page File should be. The last thing to point out is that for IOpageRead is not only for PageFile, but also MIMODIFIEDPAGEWRITER, or if it avoids deadlock, it will not distinguish between MIMAPPAGEWRITER, actually Windows Internal Memory Manager for Pagefile and MappedFile The management use is basically the same, and the process of FSD is only a little difference. So combining the concepts, such as Control Area, such as Control Area, etc., the understanding of mapped file, etc., can also be referred to this article. There is also the same sentence, and the error will hope to get your pointing.
