A customer sent in an ETW trace after complaining that Chrome hangs for ~15 s on startup. Analysis shows that the browser process starts the crashpad process and then chrome_elf waits on an ack on this stack:

  |    ntdll.dll!__RtlUserThreadStart
  |    kernel32.dll!BaseThreadInitThunk
  |    chrome.exe!__scrt_common_main_seh
  |    |- chrome_elf.dll!SignalInitializeCrashReporting
  |    |    |- chrome_elf.dll!ChromeCrashReporterClient::InitializeCrashReportingForProcess
  |    |    |    chrome_elf.dll!crash_reporter::`anonymous namespace'::InitializeCrashpadImpl
  |    |    |    |- chrome_elf.dll!crash_reporter::internal::PlatformCrashpadInitialization
  |    |    |    |    chrome_elf.dll!crashpad::CrashpadClient::StartHandler
  |    |    |    |    chrome_elf.dll!crashpad::`anonymous namespace'::StartHandlerProcess
  |    |    |    |    |- chrome_elf.dll!crashpad::SendToCrashHandlerServer
  |    |    |    |    |    KernelBase.dll!TransactNamedPipe

In the trace it blocks here for 11.216 s. Meanwhile the crash pad process gets blocked early on in its initialization in this call stack:

  |    chrome.exe!wWinMain
  |    chrome.exe!crash_reporter::RunAsCrashpadHandler
  |    |- chrome.exe!crashpad::HandlerMain
  |    |    |- chrome.exe!base::GlobalHistogramAllocator::CreateWithActiveFileInDir
  |    |    |    chrome.exe!base::GlobalHistogramAllocator::CreateWithActiveFile
  |    |    |    |- kernel32.dll!MoveFileW

It is quite possible that the root cause is just anti-virus but it still makes me nervous to have a file rename as part of Chrome's critical startup path - especially in such a non-obvious way. File renaming was a persistent problem with jumplist performance.

I'm waiting for a cleaner trace to try to determine the real cause.

The rename dance was added over a year ago in https://codereview.chromium.org/2308763002