I am using CreateFileMapping and MapViewOfFile to try and map an almost 1 GB file. I was having some problems with extending the file so I thought that I would try using CreateFileMapping with a 1 GB size. That is larger than the actual file, but it works well on smaller files.
It seems that I can get almost to a 1 GB mapping, but not all the way. It is about 16 MB short of 1 GB.
I am using SysInternals VMMap program to view the layout of the pieces in my test program. It is very strange to me. VMMap shows me that there is free virtual memory space right after my map!
Why can I not use it?
It looks a bit like this:
0x3F6E0000 <- this piece is allocated to my test program
0x406E0000 <- this piece is free and almost 800 MB in size! Give it to me!
Is there magic about that area of memory over 0x40000000? If so, then why did it let me use up 0x6E0000 of it?
By the way, the test program is using MapViewOfFile in 64 individual segments which is why that 0x3F6E0000 piece is not that big.
This is a long shot, but it could be that something small is mapped near 0x40000000 (maybe a DLL?), and since the kernel cannot find a contiguous VA space that is the size you want (i.e. you’ve got enough, but it’s split up), it fails. If you want to map in gigantic files, it’s much easier on a modern architecture – as you only get maybe 1.5GB guaranteed VA space for user-mode processes on Windows once you subtract all the DLLs and heap.