Talking about Windows 2000 / XP File Cache Realization
Webcrazy (http://webcrazy.yeah.net)
Disclaimer: The contents of this article are the Cache management content of Windows NT / 2000 / XP, which involves Microsoft undocunted content. I have been analyzed after referring to a lot of information, and there will be some mistakes in the content. It is even incorrect, but it is the purpose of learning communication, the right is to write down (http: // Webcrazy.yeah.Net, I hope to add more communication (TSU00@263.net) so that I will update an error later.
I remember that the efficacy of SmartDrv.exe under the early DOS once made me have a deep impression. I don't remember when I am interested in this small file and learn from it, this is my impression of File Cache. In Windows NT / 2000 / XP, the Cache Management section makes me a modern operating system to implement the overall concept of File Cache. After reading "Inside Windows 2000" or "Windows NT File System Internals" is definitely understood, I don't prepare for what they have already involved too, I found that many things they involved were not. In-depth (although it is a bit), it may not be necessary to talk about the specific implementation, this will change as a new version of Windows. I have benefited from these two books and many other information, and I also suggested looking at them before I see this article down.
We know that the most important of the Cache part is that the IO operations such as file (including network remote files) are high-speed cache (in relatively fast memory), since the objects they operate are mainly File (there are many things in Windows in Windows The bottom layer is as a File object), and our narrative has also begun to start. A file object, all have section_Object_pointers definition (detailed definition, see NTDDK.H or File_Object in Ntifs.h). I pointed out its definition in "Exploring the Windows NT / 2000 Copy On Write Mechanism:
Typedef struct _section_object_pointers {
PVOID DATASECTIONObject; // Control Area
Pvoid SharedCacheMap;
PVOID imageSECTIONObject; // Control Area
} Section_object_pointers;
Because membership DatasectionObject and ImageeSecionObject are pointed to the internal structure called Control Area, while the Control Area structure is also directed to an internal structure called segment. Segment consists of one or more prototype PTE (PROTOTYPE PTE, PPTE). PPTE is a software structure, I mentioned PPTE at the end of the "Small Agendon Windows NT / 2000 Page Mechanism", also mentioned that PPTE is different from the conventional hardware PTE described above. One purpose of PPTE is to implement page sharing. And one or more PPTE (s) forms a subsection. These, the output results of the Kernel Debug's CA command are analyzed.
Members SharedCachemap are the structure used by real File Cache. Different from another member of File_Object, for the same file, any opencachemap of the File_Object structure pointed to this file pointing to this file is the same value, which is also a guarantee for shared files. Let's look at the two file_Object (addresses 80d37550 and 80db4860) at a certain point in the system:
// Point the first file_Object :: fobj 80d37550 from shdocvw.dll
DeviceObject *: 80ee2888
VPB *: 80ee2800
FSCONText *: E14D2D90
FSCONTEXT2 *: E14D2EE8
SecOBJPOINTER *: 80DD15F4
PrivateCachemap *: 80EA70A0
.
.
.
FILENAME: /WINDOWS/SYSTEM32/shdocvw.dll
.
.
.
// Point the second file_Object of Shdocvw.dll:
: FOBJ 80DB4860
DeviceObject *: 80ee2888
VPB *: 80ee2800
FSCONText *: E14D2D90
Fscontext2 *: E1183678
SecOBJPOINTER *: 80DD15F4
PrivateCachemap *: 80D6F2D8
.
.
.
FILENAME: /WINDOWS/SYSTEM32/shdocvw.dll
.
.
.
From the result of the above SOFTICE, we are easy to find section_object_pointers to point to the same memory area, so SharedCachemap certainly points to the same value, and privatecachemap is two complete values, further analysis, FSContext also points to the same value, and fscontext2 is different In fact, when FSD is implemented, these two members are defined for File Control Buffer (see fsrtl_common_fcb_header in ntif.h), a specific usage can be referred to in NTIFS in the NTIFS in the implementation of Fastfat or CDFS, not The discussion scope of this paper.
After analyzing, FILE_OBJECT, we can get a conclusion: We can get one or two Control Area of this File object via FILE_OBJECT, and we can get segment through Control Area, 既 而 而 而 下 下 下,, 另 另 o,, You can also get the SharedCachemap of all instances of this file. In fact, SharedCachemap also has a pointer to file_Object, and I will continue to explain.
I remember that I have defined such a structure in "Analyze Windows NT / 2000 Pile Insurance and Virtual Memory Organization":
Typedef struct vad {
Void * StartingAddress;
Void * endingaddress;
Struct Vad * Parentlink;
Struct Vad * LeftLink;
Struct Vad * RightLink;
Ulong flags;
Ulong mmci;
Ulong Protopte;
VAD, * PVAD;
In fact, MMCI is also Control Area, I also explain in "exploring the Windows NT / 2000 Copy On Write mechanism". Protopte is PPTE.
With such a concept, we can easily discover how PPTE is shared by page. When the system accesses the PPTE, the system is invalid because the PPTE's bit 0 is invalid, so that the Page Fault is handed over, that is, the control is handed over by the Kitrap0E in ntoskrnl.exe, and then checks VAD. You can locate the PFN Database from the PPTE to PPTE, read the contents of the disk to implement the sharing of the contents of the disk. After detail, after FILE_OBJECT, we turn to File Cache discussions. Windows 2000 / XP retains two system virtual memory areas pointed to System Cache by MMSystemCacheStartextra. This special area is divided into VACB_MAPPING_GRANULARITY (defined in ntifs.h, the value is 0x40000, the 256KB). The usage of each view is represented by one of the systems called VACB. In this system, there is a VACB array and is specified by CCVACBS. "Inside Windows 2000" lists four members of Vacb, pointing out that it contains an important member, named SharedCachemap, below! The output of the DSO command:
KD>! DSO VACB // Kernel Debug Extension Build 2167 Free
Structure Vacb - size: 0x18
000 baseaddress 004 SharedCachemap
008 Overlay 010 Lrulist
But by analysis, I found that the VACB in Windows XP is actually consisting of 6 DWORD values, and its second DWORD is SharedCacheMap. Windows XP uses 6 DWORDs, which may be its specific implementation of Larger Mapped Files (file_offset uses large_integer, although "Inside Windows 2000" also points out FileOffset members, but I don't know why the output of the DSO command is not explicitly provided. A member, and I am very confused, is it the difference between the versions?). Below is an analysis under XP:
KD> DD CCVACBS L 1
80542fec 80ec000
KD> DD 80ECC000 // DD Vacb
80ec000 CB440000 80EAAC78 00300000 000,0000000
80ec010 80eceda0 80ecf598 D4040000 80EAAC78
80ec020 01000000 00000000 80ecd6a8 80ecede8
80ecc030 C1100000 80eefed0 0000000000000000
80ecc040 80ece050 80542fe0 Deb40000 FFA55538
80ecc050 00000000 00000000 80ECD558 80ECC958
KD> DD 80EAAC78 L 12 // DD VACB-> SharedCachemap
80EAAC78 013002FF 00000001 01A95400 00000000
80EAAC88 80EAAC68 80EAAAC0 01B00000 00000000
80EAAC98 ffffffff7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFfff 7FFFFFFF
80eaaca8 00000000000000000000 million 0000000000000000002
80EAACB8 80EAA910 80EE2A80
Above I mentioned SharedCachemap also pointed to file_Object, I found that the position is on the 18th DWORD, below DUMP out of File_Object. KD> DD 80EE2A80 L 6 // DD file_Object
80ee2a80 00700005 80ee2888 80ee2800 80e7f9b0
80ee2a90 00000000 80ee23a4
File_Object definitions have been given in NTDDK.H, so it is easy to get its section_object_pointers.
KD> DD 80EE23A4 L 3 // DD file_Object-> section_object_pointers
80ee23a4 80e7f710 80eaac78 00000000
KD>! CA 80E7F710 //! CA Section_Object_Pointers-> DatasectionObject
Controlarea @ 80e7f710
Segment: E127A548 FLINK 0 Blink 0
Section Ref 1 PFN REF 275 Mapped Views 5f
User Ref 0 Waitfordel 0 Flush Count 0
File Object 80ee2a80 MODWRITECUNT 0 System Views 5F
Flags (8088) NomodifiedWriting File Waspurged
FILE: / $ MFT
.
.
.
This way, we are DUMP out of the first VACB content in the system cacbs, from the output of the CA command We can see that the first View of System Cache is used by NTFS metadata $ MFT. KERNEL Debug also provides a command called FileCache, I have reviewed its documentation when using! Filecache command, mentioned in the document (Windbg: 6.0.00007.0):
Each line of this extension's output represents a virtual address control block (VACB). When named files are mapped into the VACB, the names of these files are displayed. If "no name for file" is specified, this means that this VACB is being Used to cache metadata.
From the above note I also thought that the FileCache command passed through the VACB array, DUMP has all Control Area, just like the manual analysis Vacb process I above. But in fact, this command is not only only these contents. By analyzing the implementation of FileCache in KDexts.dll (Windows XP), it is found to achieve Dump FileCache by psloadedModuleList (see further learning).
Finally, it is also pointed that the system judges whether the file is cased by ccisfilecached macro. It is defined in NTIFS.H, which is very easy to understand after the above analysis:
#define ccisfilecached (fo) (/
((Fo) -> SectionObjectPointer! = NULL) && /
(((Psection_object_pointers (fo) -> SectionObjectPointer) -> SharedCachemap! = NULL) /
)
This article does not involve another very important data structure PFN database, specified by mmpfndatabase, the shared page in the PFN database has a definition of PPTE, and after the Page Fault that points to the PPTE page, after the VAD is found, the system will be based on the PFN database. PPTE completes the next step. It is actually the specific definition of Control Area, SubSection, PPTe, Vacb, SharedCachemap, etc., I am more interested, and I still have some concepts on this so far. This is also my purpose, I also hope to reach the role of throwing jade (TSU00@263.net).
