[Continue] loading Windows PE and. net assembly

There are many views in the comments written by firelong about the recent C # debate. Some topics were not clearly understood at the time. Later I took the time to read it. There are too many opinions in those comments, and there is no way to verify them one by one. I only talk about my findings.

 

1. Impact of SizeOfImage on Windows PE Memory loading

 

I started to build up the concept that Windows PE will all be loaded into the memory for execution. When someone mentioned RAR self-extracting EXE in that comment. At that time, I assumed that the RAR self-decompressed EXE would also be loaded into the memory. later, it was pointed out by others that there were still experiments to confirm that even if the physical memory was not large enough and there were no page files, a large file could be decompressed. I cannot figure out why. At that time, a netizen gussing mentioned the SizeOfImage parameter, which gave me some inspiration. Later, after further viewing, we learned that RAR self-extracting EXE is a special case of Windows PE. This is especially true for the SizeOfImage parameter. Use Windbg to load a 35 m RAR self-decompressed EXE, and then use RAMMap to view its physical memory usage. it is found that the memory usage is about 0x00020000. use CFF explorer VII to view its PE file. The SizeOfImage field is 0x00020000.

Other Windows PE files, such as ntdll. dll. Its SizeOfImage is 0x00127000, its file size is 1,202,168, and its hexadecimal value is 0x1257F8. it seems that SizeOfImage exactly matches the file size, just enough to install this ntdll. dll itself. Look at many other EXE/DLL files in the Windows folder. Many of them are SizeOfImage files with exactly the same size.

In conclusion, SizeOfImage determines the size of the PE loaded into the memory.

 

2. The Windoes PE is loaded using File mapping.

 

Ivony has always said this. It is now confirmed. The problem is illustrated in the previous figure:

Figure 1

Figure 2 helps you understand how File mapping works.

Figure 2

 

3. Many Windows PES are fully loaded into the memory.

 

Figure 1 above tells us the physical address of MSPAINT. EXE in the memory, and scroll up and down, you will find that every physical memory page is Active, that is, all in the memory. Of course, not all Windows PES are loaded into the memory. Because this is affected by the SizeOfImage parameter.

 

4.. net assembly (that is,. net PE) is also loaded into the memory.

 

First, the SizeOfImage of. net PE also matches the file size. This is the premise. Next, let's look at the actual evidence:

The size of my. net PE file is about 27 MB:

Figure 3

After running, use RAMMap to view the status of the physical memory page:

Figure 4

Figure 5

This file is large. There are many memory pages. I looked up and down. Apart from some Standby, most of them are Active, that is, most of them are in the memory. But why is there Standby? I still don't quite understand it at the beginning. Until I see the figure shown in VMMap:

Figure 6

Figure 7

These sections of. net PE do not exist: header,. text,. rsrc,. reloc, and the sections marked as Reserved. Compared with the unmanaged Windows PE and. net PE, the memory image is different. In an unmanaged Windows PE, the memory is basically loaded into the memory, and the memory image of the. net PE is always empty. The header and. text must be empty, and the. rsrc and. reloc must be empty.

 

5. Another question: Why is the Working set only 7-8 m large?

Most of this. net PE is actually in the memory. But why is the Working set of this process only 7-8 m large?

Think of The definition of Working set: The working set of a program is a collection of those pages in its virtual address space that have been recently referenced.
Then I remembered figure 2. I understand what it is. That is, the File view created by each process is different. This File View affects the size of the Working set.

 

It is better to systematically read <Windows Internals>.

 

Here, and what we see may not be the truth. Please give me some advice.