I'm looking at PE files. Sections' Raw size(disk) values are different that their virtual size(memory) values. Sometimes bigger sometimes smaller.
What is the reason of that?
Posted on 2009-10-08 08:36:45 by sawer

Well, the Raw Size is exactly the size of the filesection's data in the file.
The Virtual Size is how big it will be when its loaded into memory.
Usually, the Virtual Size is SMALLER than the Raw Size.
The reason is that the filesection is padded out to the next 'boundary' - your executable contains unnecessary data !!
But it can work the other way too.
For example, if we define a .DATA? segment, containing some array of UNINITIALIZED data.
In this case, since its uninitialized, it will have a Raw size of ZERO - the Virtual size is larger!

Hope those examples help you to understand.


Posted on 2009-10-08 09:00:58 by Homer

Usually, the Virtual Size is SMALLER than the Raw Size.
The reason is that the filesection is padded out to the next 'boundary'

Thank you Homer,
As you know, memory alignment is 4kb but file alignment is 512 byte...

Before I asked that, I had thought that virtual size usually must be "bigger" than the raw size because memory alignment is bigger than file alignment.

But you said opposite of that. And also you said as a reason: "padded out to the next 'boundary'".
I don't understand that part.

What do you mean with "padded out to the next 'boundary'". If it is related with file-memory alignment sizes, why is raw size  usually bigger than the the virtual size?
Posted on 2009-10-08 09:36:52 by sawer
Before I asked that, I had thought that virtual size usually must be "bigger" than the raw size because memory alignment is bigger than file alignment.

But you said opposite of that. And also you said as a reason: "padded out to the next 'boundary'".
I don't understand that part.

What do you mean with "padded out to the next 'boundary'". If it is related with file-memory alignment sizes, why is raw size  usually bigger than the the virtual size?


It's by design.


5.1. Section Data

The data for each section is located at the file offset that was given by the PointerToRawData field in the section header. The size of this data in the file is indicated by the SizeOfRawData field. If SizeOfRawData is less than VirtualSize, the remainder is padded with zeros.

In an image file, the section data must be aligned on a boundary as specified by the FileAlignment field in the optional header. Section data must appear in order of the RVA values for the corresponding sections (as do the individual section headers in the section table).

There are additional restrictions on image files if the SectionAlignment value in the optional header is less than the page size of the architecture. For such files, the location of section data in the file must match its location in memory when the image is loaded, so that the physical offset for section data is the same as the RVA.


VirtualSize tells the loader minimum size in bytes to allocate for the section (imagine 1-byte page granularity architecture ;-), SizeOfRawData indicates how many bytes (rounded up to a nearest FileAlignment multiple) are stored in the image file to initialize the section. Due to the alignment requirement underlined by me above, SizeOfRawData>VirtualSize in most cases (unless there are a lot of zero/uninitialized bytes at the end of raw data).

Also, there was speed-hack for Win98 (/OPT:WIN98 linker option), which aligns sections to 4KiB multiples in the image file (thus improving memory-mapping and load time, but making file bigger).
Posted on 2009-10-10 08:23:31 by baldr
Also, there was speed-hack for Win98 (/OPT:WIN98 linker option), which aligns sections to 4KiB multiples in the image file (thus improving memory-mapping and load time, but making file bigger).
Actually that used to be the default, requiring the (now removed) /OPT:NOWIN98, or to use the (undocumented) /FILEALIGN switch.
Posted on 2009-10-10 08:31:07 by f0dder
Thank you very much, baldr.
Very helpful post.
Posted on 2009-10-10 15:47:39 by sawer