After a very tedious process, I got a log of the PeakPagedMemorySize64 of every TU (provided it lived long enough to do a query).
Everything that reported over a billion has been added to the list.
One file was removed because it didn't actually use that much.
This wasn't entirely foolproof - I can run it again single-threaded so cooperation over codegen threads won't throw the numbers off if this turns out not to fully solve the problem.
Apparently we'd never bothered opting in, despite nearly everything in all out apps being entirely compatible and designed with long paths in mind.
GetModuleFileNameW is a bit awkward as it's just about the only Win32 function that returns the minimum of the buffer size and the string size - nearly everything else returns the full size even if it won't fit, so you can pass it a null pointer and a size of zero, and it'll tell you how much space you need to allocate.
I pretty much just copied the mostly-working long-path-friendly call site in the crash catcher to windowspath.cpp, but I also noticed that if the function failed and returned zero, the original implementation would loop forever, so I fixed that.
There was some code that could be ditched from the catch monitor as \\?\ is a prefix you can use to opt into long paths for a single API call instead of using the manifest to set it everywhere.
