{"id":467,"date":"2010-06-26T12:13:58","date_gmt":"2010-06-26T12:13:58","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2010\/06\/26\/mapping-files-into-memory\/"},"modified":"2026-07-31T19:12:02","modified_gmt":"2026-07-31T19:12:02","slug":"mapping-files-into-memory","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2010\/06\/26\/mapping-files-into-memory\/","title":{"rendered":"Mapping Files into Memory"},"content":{"rendered":"
\"\"<\/a><\/div>\n

After illustrating some of the Memory Manager<\/strong>‘s characteristics as a service provider to the Cache Manager<\/strong> in the previous post<\/a>, today I will demonstrate that mere User-Mode<\/em> applications can also use such services. By mapping files into memory the application gains a range of virtual addresses that contains the file’s content. Access to the file’s content is done simply by dereferencing a pointer, without the need to call the ReadFile()<\/a> or WriteFile()<\/a> functions.<\/p>\n

Want a need for this? Imagine that your application needs to search for a certain string in a file, let’s say “DriverEntry”. In a “rice and beans”<\/em> development, the file handle is obtained through the call to the CreateFile()<\/a> function, and a buffer receives the partial content of the file, let’s suppose 200 bytes. A simple search function from the API could perform such a search in the buffer.<\/p>\n

\"\"<\/p>\n

This solution would be perfect if there were no possibility of the searched word falling at the edges of the buffer, as illustrated below.<\/p>\n

\"\"<\/p>\n

A smarter algorithm would have to be used to identify the prefix and continue the search on the next read of the file.<\/p>\n

This is just a simple example, but it clearly illustrates one of the advantages of mapping files. If there were a simple function that received the path of a file and returned to us a pointer to its content, the search would be quite simple.<\/p>\n

Files mapped into memory can also make writing to their content easier. By writing to the pointer received from such a mapping, the Memory Manager will take charge of doing the necessary I\/O so that this new content reaches the disk.<\/p>\n

A simple mapping function<\/h3>\n

Here I will exemplify the use of the routines that map a file into memory. The comments follow in the explanation.<\/p>\n

\n
\/****<\/span><\/pre>\n
***     MapFileToMemory<\/span><\/pre>\n
**<\/span><\/pre>\n
**      Routine that receives the path of a file that will be<\/span><\/pre>\n
**      mapped into memory for reading. An address is<\/span><\/pre>\n
**      returned to the calling routine as well as the size<\/span><\/pre>\n
**      of the file.<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
DWORD MapFileToMemory(LPCTSTR   tzFileName,<\/pre>\n
                      LPVOID*   ppMemory,<\/pre>\n
                      LPDWORD   pdwSize)<\/pre>\n
{<\/pre>\n
    HANDLE  hFile = NULL,<\/pre>\n
            hMapping = NULL;<\/pre>\n
    DWORD   dwError = ERROR_SUCCESS;<\/pre>\n
 <\/pre>\n
    __try<\/span><\/pre>\n
    {<\/pre>\n
        __try<\/span><\/pre>\n
        {<\/pre>\n
            \/\/-f--> Zeroes output variables.<\/span><\/pre>\n
            *pdwSize = NULL;<\/pre>\n
            *ppMemory = NULL;<\/pre>\n
 <\/pre>\n
            \/\/-f--> Here we open the file to be mapped<\/span><\/pre>\n
            hFile = CreateFile(tzFileName,<\/pre>\n
                               GENERIC_READ,<\/pre>\n
                               FILE_SHARE_READ | FILE_SHARE_DELETE,<\/pre>\n
                               NULL,<\/pre>\n
                               OPEN_EXISTING,<\/pre>\n
                               FILE_ATTRIBUTE_NORMAL,<\/pre>\n
                               NULL);<\/pre>\n
 <\/pre>\n
            \/\/-f--> We check whether the file was opened; if not,<\/span><\/pre>\n
            \/\/      the boogeyman comes and takes us away.<\/span><\/pre>\n
            if<\/span> (hFile == INVALID_HANDLE_VALUE)<\/pre>\n
                RaiseException(GetLastError(),<\/pre>\n
                               0<\/span>,<\/pre>\n
                               0<\/span>,<\/pre>\n
                               NULL);<\/pre>\n
 <\/pre>\n
            \/\/-f--> Although the file size is not necessary<\/span><\/pre>\n
            \/\/      in this function, let's take advantage of having the file's<\/span><\/pre>\n
            \/\/      handle in hand to obtain this information for<\/span><\/pre>\n
            \/\/      the calling routine, which will need it.<\/span><\/pre>\n
            *pdwSize = GetFileSize(hFile,<\/pre>\n
                                   NULL);<\/pre>\n
 <\/pre>\n
            \/\/-f--> Here we create a mapping of the file.<\/span><\/pre>\n
            \/\/      In kernel it would be the equivalent of creating a<\/span><\/pre>\n
            \/\/      section of the file.<\/span><\/pre>\n
            hMapping = CreateFileMapping(hFile,<\/pre>\n
                                         NULL,<\/pre>\n
                                         PAGE_READONLY,<\/pre>\n
                                         0<\/span>,<\/pre>\n
                                         0<\/span>,<\/pre>\n
                                         NULL);<\/pre>\n
 <\/pre>\n
            \/\/-f--> Preventing the boogeyman.<\/span><\/pre>\n
            if<\/span> (!hMapping)<\/pre>\n
                RaiseException(GetLastError(),<\/pre>\n
                               0<\/span>,<\/pre>\n
                               0<\/span>,<\/pre>\n
                               NULL);<\/pre>\n
 <\/pre>\n
            \/\/-f--> Here the mapping is actually done and we get the<\/span><\/pre>\n
            \/\/      range of addresses that will contain the content<\/span><\/pre>\n
            \/\/      of the file.<\/span><\/pre>\n
            *ppMemory = MapViewOfFile(hMapping,<\/pre>\n
                                      FILE_MAP_READ,<\/pre>\n
                                      0<\/span>,<\/pre>\n
                                      0<\/span>,<\/pre>\n
                                      0<\/span>);<\/pre>\n
 <\/pre>\n
            \/\/-f--> The same boogeyman trick I already mentioned.<\/span><\/pre>\n
            if<\/span> (!*ppMemory)<\/pre>\n
                RaiseException(GetLastError(),<\/pre>\n
                               0<\/span>,<\/pre>\n
                               0<\/span>,<\/pre>\n
                               NULL);<\/pre>\n
        }<\/pre>\n
        __finally<\/span><\/pre>\n
        {<\/pre>\n
            \/\/-f--> Here is where we will do all the cleanup,<\/span><\/pre>\n
            \/\/      closing the handles that were opened.<\/span><\/pre>\n
            if<\/span> (hFile)<\/pre>\n
                CloseHandle(hFile);<\/pre>\n
 <\/pre>\n
            if<\/span> (hMapping)<\/pre>\n
                CloseHandle(hMapping);<\/pre>\n
        }<\/pre>\n
    }<\/pre>\n
    __except<\/span>(EXCEPTION_EXECUTE_HANDLER)<\/pre>\n
    {<\/pre>\n
        \/\/-f--> Oops! Something did not go as rehearsed.<\/span><\/pre>\n
        \/\/      Find someone to blame and pretend it is not your problem.<\/span><\/pre>\n
        dwError = GetExceptionCode();<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    return<\/span> dwError;<\/pre>\n
}<\/pre>\n
 <\/pre>\n<\/div>\n
This example is really quite simple, but feel free to add parameters that make this function more flexible and complex.<\/p>\n
\n
“Fernando, even if the file was mapped successfully, you close the file handle and the mapping handle. Shouldn’t that release the references this program has to the file?”<\/p>\n<\/blockquote>\n
Actually, after we create the file mapping using the CreateFileMapping()<\/a> routine, which receives the file handle, an extra reference has already been made to the file, and so we could already close its handle if we wanted to. The same happens with the call to the MapViewOfFile()<\/a> routine, which receives the mapping handle, and which in turn has an indirect reference to the mapped file. In other words, once everything is mapped we can close all the handles and let the indirect references take care of it.<\/p>\n
In the next source code we will see a simple example of using this function.<\/p>\n
\n
\/****<\/span><\/pre>\n
***     _tmain<\/span><\/pre>\n
**<\/span><\/pre>\n
**      Simple use of the file-mapping function.<\/span><\/pre>\n
**      Just so nobody says I did not do every little bit...<\/span><\/pre>\n
*\/<\/span><\/pre>\n
 <\/pre>\n
int<\/span> _tmain(int<\/span> argc, _TCHAR* argv[])<\/pre>\n
{<\/pre>\n
    PBYTE   pBuffer;<\/pre>\n
    DWORD   dwError, dwSize, i;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Passes the file name and obtains the pointer<\/span><\/pre>\n
    \/\/      with its content mapped. Just like that...<\/span><\/pre>\n
    dwError = MapFileToMemory(_T(\"C:\\\\Temp\\\\Test.txt\"<\/span>),<\/pre>\n
                              (LPVOID*)&pBuffer,<\/pre>\n
                              &dwSize);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Testing for errors never hurts.<\/span><\/pre>\n
    if<\/span> (dwError == ERROR_SUCCESS)<\/pre>\n
    {<\/pre>\n
        \/\/-f--> Moments of suspense before touching the address.<\/span><\/pre>\n
        printf(\"Hit any key to access the buffer at 0x%p...\\n\"<\/span>, pBuffer);<\/pre>\n
        _getch();<\/pre>\n
 <\/pre>\n
        \/\/-f--> Prints each character stored in the file.<\/span><\/pre>\n
        \/\/      \"Look, Mom! No ReadFile()!\"<\/span><\/pre>\n
        for<\/span> (i=0<\/span>; i<\/pre>\n
            printf(\"%c\"<\/span>, pBuffer[i]);<\/pre>\n
 <\/pre>\n
        \/\/-f--> Here the mapping is undone.<\/span><\/pre>\n
        UnmapViewOfFile(pBuffer);<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    return<\/span> dwError;<\/pre>\n
}<\/pre>\n
 <\/pre>\n<\/div>\n
At the end of this example we can observe the call to the UnmapViewOfFile()<\/a> routine, which simply receives the base pointer of the file mapping. With this call, all internal references are undone and the file is finally closed.<\/p>\n
Testing the toy<\/h3>\n
So that we can run a silly test, create a text file using Notepad.exe.<\/p>\n
\"\"<\/p>\n
Running the test application we have the output as illustrated below.<\/p>\n
\"\"<\/p>\n
Now in the replay slow motion<\/h3>\n
With WinDbg<\/a> we can observe the exact moment when the application accesses the range of addresses referring to the file’s content. To do this we will place a breakpoint on the file-read routine of the Ntfs.sys<\/strong> driver; this way we will be able to see the Memory Manager’s request being served. For this to happen, the text file cannot be in the system cache, so if you have already run the test application at least once, you will have to restart the system.<\/p>\n
If you have not used WinDbg yet and do not know how to connect it to the system, then read this post<\/a> for a quick start. After connecting WinDbg to the system Kernel, go to the directory where the test application is and run it, but do not press any key yet, leaving it stopped as shown below:<\/p>\n
\"\"<\/p>\n
After that, press Ctrl+Break in WinDbg so that you gain control over the debugged system, which at this moment will remain frozen.<\/p>\n
To place that breakpoint on the file-read routine of Ntfs.sys, we will need to know where this routine is within the driver. We can obtain this information using WinDbg’s !drvobj<\/strong> extension as shown below.<\/p>\n
\n
kd> !drvobj \\FileSystem\\Ntfs 2<\/pre>\n
Driver object (843fd650) is for:<\/pre>\n
 \\FileSystem\\Ntfs<\/pre>\n
DriverEntry:   828f5b75    Ntfs!GsDriverEntry<\/pre>\n
DriverStartIo: 00000000    <\/pre>\n
DriverUnload:  00000000    <\/pre>\n
AddDevice:     00000000    <\/pre>\n
 <\/pre>\n
Dispatch routines:<\/pre>\n
[00] IRP_MJ_CREATE                      8289400a    Ntfs!NtfsFsdCreate<\/pre>\n
[01] IRP_MJ_CREATE_NAMED_PIPE           8165a013    nt!IopInvalidDeviceRequest<\/pre>\n
[02] IRP_MJ_CLOSE                       82896fcf    Ntfs!NtfsFsdClose<\/pre>\n
[03] IRP_MJ_READ                        82818514    Ntfs!NtfsFsdRead<\/span><\/pre>\n
[04] IRP_MJ_WRITE                       82815638    Ntfs!NtfsFsdWrite<\/pre>\n
[05] IRP_MJ_QUERY_INFORMATION           82895a88    Ntfs!NtfsFsdDispatchWait<\/pre>\n
[06] IRP_MJ_SET_INFORMATION             8281e950    Ntfs!NtfsFsdSetInformation<\/pre>\n
[07] IRP_MJ_QUERY_EA                    82895a88    Ntfs!NtfsFsdDispatchWait<\/pre>\n
[08] IRP_MJ_SET_EA                      82895a88    Ntfs!NtfsFsdDispatchWait<\/pre>\n
[09] IRP_MJ_FLUSH_BUFFERS               82884349    Ntfs!NtfsFsdFlushBuffers<\/pre>\n
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION    828b5fc6    Ntfs!NtfsFsdDispatch<\/pre>\n
[0b] IRP_MJ_SET_VOLUME_INFORMATION      828b5fc6    Ntfs!NtfsFsdDispatch<\/pre>\n
[0c] IRP_MJ_DIRECTORY_CONTROL           828b5d41    Ntfs!NtfsFsdDirectoryControl<\/pre>\n
[0d] IRP_MJ_FILE_SYSTEM_CONTROL         8289970e    Ntfs!NtfsFsdFileSystemControl<\/pre>\n
[0e] IRP_MJ_DEVICE_CONTROL              82879466    Ntfs!NtfsFsdDeviceControl<\/pre>\n
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL     8165a013    nt!IopInvalidDeviceRequest<\/pre>\n
[10] IRP_MJ_SHUTDOWN                    8282b36b    Ntfs!NtfsFsdShutdown<\/pre>\n
[11] IRP_MJ_LOCK_CONTROL                82823b7a    Ntfs!NtfsFsdLockControl<\/pre>\n
[12] IRP_MJ_CLEANUP                     828a1d42    Ntfs!NtfsFsdCleanup<\/pre>\n
[13] IRP_MJ_CREATE_MAILSLOT             8165a013    nt!IopInvalidDeviceRequest<\/pre>\n
[14] IRP_MJ_QUERY_SECURITY              828b5fc6    Ntfs!NtfsFsdDispatch<\/pre>\n
[15] IRP_MJ_SET_SECURITY                828b5fc6    Ntfs!NtfsFsdDispatch<\/pre>\n
[16] IRP_MJ_POWER                       8165a013    nt!IopInvalidDeviceRequest<\/pre>\n
[17] IRP_MJ_SYSTEM_CONTROL              8165a013    nt!IopInvalidDeviceRequest<\/pre>\n
[18] IRP_MJ_DEVICE_CHANGE               8165a013    nt!IopInvalidDeviceRequest<\/pre>\n
[19] IRP_MJ_QUERY_QUOTA                 82895a88    Ntfs!NtfsFsdDispatchWait<\/pre>\n
[1a] IRP_MJ_SET_QUOTA                   82895a88    Ntfs!NtfsFsdDispatchWait<\/pre>\n
[1b] IRP_MJ_PNP                         8286137b    Ntfs!NtfsFsdPnp<\/pre>\n
 <\/pre>\n
Fast I\/O routines:<\/pre>\n
FastIoCheckIfPossible                   8288187b    Ntfs!NtfsFastIoCheckIfPossible<\/pre>\n
FastIoRead                              82880c38    Ntfs!NtfsCopyReadA<\/pre>\n
FastIoWrite                             82881f53    Ntfs!NtfsCopyWriteA<\/pre>\n
FastIoQueryBasicInfo                    82888c3a    Ntfs!NtfsFastQueryBasicInfo<\/pre>\n
FastIoQueryStandardInfo                 82888aa6    Ntfs!NtfsFastQueryStdInfo<\/pre>\n
FastIoLock                              8287bf41    Ntfs!NtfsFastLock<\/pre>\n
FastIoUnlockSingle                      8287bd75    Ntfs!NtfsFastUnlockSingle<\/pre>\n
FastIoUnlockAll                         828cd7b3    Ntfs!NtfsFastUnlockAll<\/pre>\n
FastIoUnlockAllByKey                    828cd958    Ntfs!NtfsFastUnlockAllByKey<\/pre>\n
ReleaseFileForNtCreateSection           8281e904    Ntfs!NtfsReleaseForCreateSection<\/pre>\n
FastIoQueryNetworkOpenInfo              8287ad84    Ntfs!NtfsFastQueryNetworkOpenInfo<\/pre>\n
AcquireForModWrite                      8280c892    Ntfs!NtfsAcquireFileForModWrite<\/pre>\n
MdlRead                                 828cd0d8    Ntfs!NtfsMdlReadA<\/pre>\n
MdlReadComplete                         81650af6    nt!FsRtlMdlReadCompleteDev<\/pre>\n
PrepareMdlWrite                         828cd31f    Ntfs!NtfsPrepareMdlWriteA<\/pre>\n
MdlWriteComplete                        817f5a9a    nt!FsRtlMdlWriteCompleteDev<\/pre>\n
FastIoQueryOpen                         82874d03    Ntfs!NtfsNetworkOpenCreate<\/pre>\n
AcquireForCcFlush                       8281ab35    Ntfs!NtfsAcquireFileForCcFlush<\/pre>\n
ReleaseForCcFlush                       8281aa9c    Ntfs!NtfsReleaseFileForCcFlush<\/pre>\n
 <\/pre>\n<\/div>\n
As you must be imagining, the Ntfs read routine is used very frequently, which would make this breakpoint stop many times without the slightest relation to our test. To limit the breakpoint’s scope, we will make it apply only to the thread that will make the request we are waiting for.<\/p>\n
As I already explained in the previous post<\/a>, when the memory address is obtained, the file has not yet been read. When the application dereferences this pointer looking for the data, a page fault<\/em> will be generated and the Memory Manager will take control over the thread by means of a system trap<\/em>. This is the thread that will be used to perform the read of the file that will supply the memory page at the Memory Manager’s request. This is the reason why our test program waits for a key to be pressed before accessing the buffer. This gives us the opportunity to obtain the identification of the thread that is waiting for that event.<\/p>\n
We use the !process<\/strong> extension to locate our test program, and it will also list its threads, which in our case is a single one.<\/p>\n
\n
kd> !process 0 2 MapFile.exe<\/pre>\n
PROCESS 84bf6d90  SessionId: 1  Cid: 0b60    Peb: 7ffdf000  ParentCid: 0b40<\/pre>\n
    DirBase: 1f09b4c0  ObjectTable: 8e77ccd0  HandleCount:   5.<\/pre>\n
    Image: MapFile.exe<\/pre>\n
 <\/pre>\n
        THREAD 84f6cb50<\/span>  Cid 0b60.0b64  Teb: 7ffde000 Win32Thread: 00000000 WAIT: (WrLpcReply) ...<\/pre>\n
            84f6cd64  Semaphore Limit 0x1<\/pre>\n
 <\/pre>\n
kd> bp \/1 \/t 84f6cb50<\/span> Ntfs!NtfsFsdRead<\/pre>\n
kd> g<\/pre>\n
 <\/pre>\n<\/div>\n
After placing the breakpoint, we can release the execution of the system and type something in the test application. This will make our breakpoint interrupt the system just as we intended. Looking at the call stack we have at the moment, we can evidence the execution of the trap that was generated by the test application. This trap<\/em> is being served by the Memory Manager.<\/p>\n
\n
Breakpoint 0 hit<\/pre>\n
Ntfs!NtfsFsdRead:<\/pre>\n
82818514 6a40<\/pre>\n
 <\/pre>\n
kd> kb<\/pre>\n
ChildEBP RetAddr<\/span>  Args to Child<\/pre>\n
8f395b6c 816f00c3 84438020 84f40290<\/span> 84f40290 Ntfs!NtfsFsdRead<\/pre>\n
8f395b84 821a3ba7 84437730 84f40290 00000000 nt!IofCallDriver+0x63<\/pre>\n
8f395ba8 821a3d64 8f395bc8 84437730 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x251<\/pre>\n
8f395be0 816f00c3 84437730 84f40290 00000000 fltmgr!FltpDispatch+0xc2<\/pre>\n
8f395bf8 8167bf2e 84f6cb50 8443a18c 8443a158 nt!IofCallDriver+0x63<\/pre>\n
8f395c14 816b8d51 00000043 84f6cb50 8443a198 nt!IoPageRead+0x172<\/pre>\n
8f395cd0 816db03f 00020000 90825810 00000000 nt!MiDispatchFault+0xd18<\/pre>\n
8f395d4c 8168ebf4<\/span> 00000000 00020000 00000001 nt!MmAccessFault<\/span>+0x1fb7<\/pre>\n
8f395d4c 0018d972 00000000 00020000 00000001 nt!KiTrap0E<\/span>+0xdc<\/pre>\n
0015fbc0 0018ec36 00000001 00281a28 00281a78 MapFile!wmain+0x72<\/pre>\n
0015fc0c 0018eb0f 0015fc20 77554911 7ffdf000 MapFile!__tmainCRTStartup+0x116<\/pre>\n
0015fc14 77554911 7ffdf000 0015fc60 77ace4b6 MapFile!wmainCRTStartup+0xf<\/pre>\n
0015fc20 77ace4b6 7ffdf000 77a26775 00000000 kernel32!BaseThreadInitThunk+0xe<\/pre>\n
0015fc60 77ace489 0018b532 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x23<\/pre>\n
0015fc78 00000000 0018b532 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b<\/pre>\n
 <\/pre>\n<\/div>\n
As we know the prototype that a dispatch routine must have, we know that the second parameter of the NtfsFsdRead()<\/em> routine is the address of the IRP<\/a> that the driver received. Using the !irp<\/strong> extension we can obtain details about the IRP. This allows us to know the FileObject<\/em> to which this request is destined.<\/p>\n
\n
kd> !irp 84f40290<\/span> <\/pre>\n
Irp is active with 8 stacks 8 is current (= 0x84f403fc)<\/pre>\n
 Mdl=8443a1d8: No System Buffer: Thread 84f6cb50:  Irp stack trace.  <\/pre>\n
     cmd  flg cl Device   File<\/span>     Completion-Context<\/pre>\n
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    <\/pre>\n
 <\/pre>\n
            Args: 00000000 00000000 00000000 00000000<\/pre>\n
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    <\/pre>\n
 <\/pre>\n
            Args: 00000000 00000000 00000000 00000000<\/pre>\n
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    <\/pre>\n
 <\/pre>\n
            Args: 00000000 00000000 00000000 00000000<\/pre>\n
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    <\/pre>\n
 <\/pre>\n
            Args: 00000000 00000000 00000000 00000000<\/pre>\n
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    <\/pre>\n
 <\/pre>\n
            Args: 00000000 00000000 00000000 00000000<\/pre>\n
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    <\/pre>\n
 <\/pre>\n
            Args: 00000000 00000000 00000000 00000000<\/pre>\n
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    <\/pre>\n
 <\/pre>\n
            Args: 00000000 00000000 00000000 00000000<\/pre>\n
>[  3, 0]   0  0 84438020 84bd0028<\/span> 00000000-00000000    <\/pre>\n
           \\FileSystem\\Ntfs<\/pre>\n
            Args: 00001000 00000000 00000000 00000000<\/pre>\n
 <\/pre>\n<\/div>\n
With the FileObject address in hand, the !fileobj<\/strong> extension will show us more details about this object. Thus we can verify that the file to be read is indeed our text file that was mapped.<\/p>\n
\n
kd> !fileobj 84bd0028<\/span> <\/pre>\n
 <\/pre>\n
\\Temp\\Test.txt<\/span><\/pre>\n
 <\/pre>\n
Device Object: 0x84439030   \\Driver\\volmgr<\/pre>\n
Vpb: 0x84436e28<\/pre>\n
Access: Read SharedRead SharedDelete <\/pre>\n
 <\/pre>\n
Flags:  0x44042<\/pre>\n
    Synchronous IO<\/pre>\n
    Cache Supported<\/pre>\n
    Cleanup Complete<\/pre>\n
    Handle Created<\/pre>\n
 <\/pre>\n
FsContext: 0x92a4cd80    FsContext2: 0x92a4ced8<\/pre>\n
CurrentByteOffset: 0<\/pre>\n
Cache Data:<\/pre>\n
  Section Object Pointers: 84d24e74<\/pre>\n
  Shared Cache Map: 00000000<\/pre>\n
 <\/pre>\n<\/div>\n
Knowing that we are in the context of the thread that made the access, we can take a little peek at the accessed address before the page fault<\/em> is served. This address was shown in the test application’s output before the breakpoint interrupted the execution of the system.<\/p>\n
\n
kd> db 0x00020000<\/span><\/pre>\n
00020000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????<\/pre>\n
00020010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????<\/pre>\n
00020020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????<\/pre>\n
00020030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????<\/pre>\n
00020040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????<\/pre>\n
00020050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????<\/pre>\n
00020060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????<\/pre>\n
00020070  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????<\/pre>\n
 <\/pre>\n<\/div>\n
\n
“Fernando, why do question marks appear? It’s fine that the file’s content has not yet been copied to the application’s buffer, but shouldn’t we see garbage or even zeros?”<\/p>\n<\/blockquote>\n
Look, that question of yours was really very good; I don’t think I myself could have thought of a better question. Actually the answer to this question is linked to that crude answer from the previous post<\/a>. What happens is that a range of addresses was reserved to contain the memory pages with the file’s content. Since no access has been made yet, this virtual address does not yet point to any physical memory page. Without this physical page one cannot determine its data. We can verify this using WinDbg’s !vtop<\/strong> extension, which translates virtual addresses to physical addresses.<\/p>\n
\n
kd> !vtop 0 0x00020000<\/span><\/pre>\n
X86VtoP: Virt 00020000, pagedir 1f09b4c0<\/pre>\n
X86VtoP: PAE PDPE 1f09b4c0 - 000000001876d801<\/pre>\n
X86VtoP: PAE PDE 1876d000 - 0000000018908867<\/pre>\n
X86VtoP: PAE PTE 18908100 - ffffffff00000420<\/pre>\n
X86VtoP: Virt ffffffff, pagedir 1f09b4c0<\/pre>\n
X86VtoP: PAE PDPE 1f09b4d8 - 00000000187b0801<\/pre>\n
X86VtoP: PAE PDE 187b0ff8 - 0000000000128063<\/pre>\n
X86VtoP: PAE PTE 128ff8 - 0000000000000000<\/pre>\n
X86VtoP: PAE zero PTE<\/pre>\n
Virtual address 20000 translation fails, error 0x8007001E<\/span>.<\/pre>\n
 <\/pre>\n
kd> !error 0x8007001E<\/span><\/pre>\n
Error code: (HRESULT) 0x8007001e (2147942430) - The system cannot read from the specified device.<\/pre>\n
 <\/pre>\n<\/div>\n
The attempt to translate this virtual address results in an error. Let’s try to do this translation again after the page fault<\/em> is served. Let’s release the execution of the system up to the return address for the MmAccessFault()<\/em> routine. This address was obtained in the thread’s call stack and was highlighted in the results of the kd<\/strong> command already illustrated above.<\/p>\n
\n
kd> ga 8168ebf4<\/span> <\/pre>\n
 <\/pre>\n
nt!KiTrap0E+0xdc:<\/pre>\n
8168ebf4 85c0            test    eax,eax<\/pre>\n
 <\/pre>\n
kd> !vtop 0 0x00020000<\/span><\/pre>\n
X86VtoP: Virt 00020000, pagedir 1f09b4c0<\/pre>\n
X86VtoP: PAE PDPE 1f09b4c0 - 000000001876d801<\/pre>\n
X86VtoP: PAE PDE 1876d000 - 0000000018908867<\/pre>\n
X86VtoP: PAE PTE 18908100 - 8000000018844025<\/pre>\n
X86VtoP: PAE Mapped phys 18844000<\/pre>\n
Virtual address 20000 translates to physical address 18844000.<\/pre>\n
 <\/pre>\n<\/div>\n
Here the page fault has already been served and control will be returned to the application. At this point the Memory Manager performed the necessary tasks so that this virtual address could now be translated to a physical page. Repeating the same translation attempt that failed earlier, we will have the following output.<\/p>\n
\n
kd> db 0x00020000<\/span><\/pre>\n
00020000  54 65 73 74 65 20 64 65-20 6d 61 70 65 61 6d 65  Teste de mapeame<\/pre>\n
00020010  6e 74 6f 20 64 65 20 61-72 71 75 69 76 6f 2e 2e  nto de arquivo..<\/pre>\n
00020020  2e 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................<\/pre>\n
00020030  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................<\/pre>\n
00020040  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................<\/pre>\n
00020050  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................<\/pre>\n
00020060  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................<\/pre>\n
00020070  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................<\/pre>\n<\/div>\n
Releasing the execution of the system, the application will make the access to the buffer and we will have the same output shown earlier. It is worth remembering that to repeat this experiment, it is necessary to restart the system, because the text file’s content is now in the system cache<\/em>. This means that the page fault<\/em> will not occur again until this page is discarded by the Cache Manager. Such an event depends on many factors and may not happen until the machine shuts down.<\/p>\n
Anyway, this post, besides bringing a simple file-mapping function, also brings the same technical blah-blah-blah as always. I hope you liked it.
\n See you! \ud83d\ude09<\/p>\n
MapFile.zip<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
After illustrating some of the Memory Manager‘s characteristics as a service provider to the Cache Manager in the previous post, today I will demonstrate that mere User-Mode applications can also use such services. By mapping files into memory the application gains a range of virtual addresses that contains the file’s content. Access to the file’s […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-467","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=467"}],"version-history":[{"count":1,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/467\/revisions"}],"predecessor-version":[{"id":468,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/467\/revisions\/468"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}