The operating system allocates memory in pages (typically 4 kb) and it'll only be possible to exclude a whole page. A variable might start in the middle of a page and end in the middle of a page. Other variables may be allocated before and after it. So you can't exclude memory on variable basis.
If a variable is larger than a page and it spans over a complete page, it might be possible to exclude the full pages. However, this will be some work for your callback routine:
Let me assume that it's quite unlikely to have a struct of that large size. So the only possible variable with such a size would be arrays. You could write a method that allocates arrays and keeps track of arrays that span over a complete page. During the callback you could determine the start and end of a page using GetSystemInfo() and then exclude the pages.
Despite the effort implementing this, consider:
- disk space is cheap nowadays. A few MB more or less do not matter. Buying a disk is cheaper than implementing such a behavior.
- crash dumps compress quite well (at least the ones I receive). If you need to send it, ZIP it first.
- if that's still not small enough, you can convert the large dump into a minidump (e.g. open the dump in WinDbg and
.dump again) and analyze that one first. Only if required, the customer needs to send you the larger file.
- remote debugging. The customer can e.g. open the dump in WinDbg, start a debugging server and you can connect to it.
- For very large allocations, the C++ heap manager will directly call VirtualAlloc() anyway. If the memory region is larger than 512 MB, tools like ProcDump are already capable of removing the largest allocation (
-mp switch). (But note that ProcDump will not come into play if you have your own unhandled exception handler)
