1250687 - Consider MiniDumpWithPrivateWriteCopyMemory for Windows minidumps

Status: RESOLVED INVALID

(Toolkit :: Crash Reporting, defect, P3)

Description

[(No longer employed by Mozilla) Aaron Klotz]

I think we should investigate the MiniDumpWithPrivateWriteCopyMemory flag for generating minidumps, and use it if at all possible.

The MSDN documentation on the flag is a bit... terse:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680519%28v=vs.85%29.aspx

But my hope is that, given the name of the flag, it doesn't include COW memory unless the private copy has actually been made. For the most part, this means that the memory will be ignored. OTOH, it could give us very valuable information about API hooking in our process.

Of course, we also would want to ensure that this doesn't greatly increase minidump size. I'm starting to think that it would be worth it.

Comment 1

[(not currently active) Ted Mielczarek]

Easy enough to test! You could do a local build and see if anything winds up in the minidump for an intentional crash. If the normal case overhead is low or zero then it might be fine. Obviously we could hit some bad edge cases where third-party software does awful things and we try to include a lot of memory in the minidump.

Comment 2

[Carl Corcoran [:ccorcoran]]

Looks like this adds too much to the minidump size unfortunately. Just for kicks, here is a list of minidump flags and their effect on the minidump file size. For this I modified our minidump writer to output many minidumps using various flags. I navigated to Youtube and induced a crash. Here are the minidumps that were produced:

FLAG                           DUMP SIZE     SIZE % OF ORIGINAL
----------------------------   -----------   ------------------
WithTokenInformation               614,890               100%
WithUnloadedModules                614,948               100%
WithThreadInfo                     619,114               100%
FilterTriage                       622,996               101%
WithAvxXStateContext               657,007               106%
WithHandleData                     735,446               119%
WithProcessThreadData            1,365,150               221%
WithIndirectlyReferencedMemory   1,651,322               268%
WithDataSegs                     2,798,908               454%
WithModuleHeaders               36,184,571             5,864%
WithCodeSegs                   124,219,063            20,132%
WithPrivateWriteCopyMemory     158,481,994            25,685%
WithPrivateReadWriteMemory     158,482,266            25,685%
WithFullMemory                 436,759,670            70,785%

I haven't thought too much about the need / safety considerations of these flags, but maybe there's something in here we can include. Very happy to generate these results under different test scenario if anyone's curious.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

Just as an FYI, we have a 20mb limit on incoming crash reports where 20mb covers the entire HTTP POST payload--not just a single minidump. Anything above 20mb gets rejected by the crash ingestion pipeline collector.

Comment 4

[Carl Corcoran [:ccorcoran]]

I checked on Win8.1 and the results are similar (~180mb); this flag unfortunately isn't viable.

Comment 5

[(not currently active) Ted Mielczarek]

If there are specific heap regions we think could be useful we could compromise and include them with custom code in the minidump callback like we did with bug 1286802.