In the process of investigating https://bugs.chromium.org/p/chromium/issues/detail?id=655788 it was discovered that crashpad_handler.exe is launched from within DllMain() via CreateProcess(). (Or rather, chrome.exe --type=crashpad-handler in this case.)
This is specifically documented as being disallowed here: https://msdn.microsoft.com/en-us/library/windows/desktop/dn633971(v=vs.85).aspx.
DllMain() has the loader lock, so if CreateProcess() loads a dll, it's likely going to deadlock. It's surprising that it worked at all, but unfortunately only deadlocked when:
"""
Open gpedit.msc, navigate to Computer Configuration -> Windows Settings -> Security Settings -> Software Restriction Policies
On the Software Restriction Policies node right click and select to "New Software Restriction Policies".
Under Software Restriction Policies open the Enforcement entry, and enable "Enforce certificate rules".
"""
was in effect.
As a temporary solution for M54, https://codereview.chromium.org/2428703002/ deferred crashpad_handler.exe launch until later (to WinMain()) but this defeats the purpose of early crash handling, going back to a normal register-in-main() style handler.
It isn't sufficient to just CreateThread() the main initialization in chrome_elf because chrome.dll in the browser process thunks back in to chrome_elf to set those darn crash keys. If the initialization is deferred, then the dictionary isn't initialized so we're racing that thread.
We should meet and figure out the best way to solve this for M55.
Comment 1 by scottmg@chromium.org, Oct 18 2016