This link

https://crash.corp.google.com/browse?q=product_name%3D%27Chrome%27+AND+expanded_custom_data.ChromeCrashProto.ptype%3D%27browser%27+AND+expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BShutdown+hang%5D+base%3A%3Ainternal%3A%3APriorityQueue%3A%3ABeginTransaction%27+AND+EXISTS+%28SELECT+1+FROM+UNNEST%28thread%29+CROSS+JOIN+UNNEST%28StackTrace.StackFrame%29+WHERE+FunctionName%3D%27base%3A%3AHistogram%3A%3AFactory%3A%3ABuild%28%29%27%29+AND+EXISTS+%28SELECT+1+FROM+UNNEST%28thread%29+CROSS+JOIN+UNNEST%28StackTrace.StackFrame%29+WHERE+FunctionName%3D%27base%3A%3AStatisticsRecorder%3A%3ARegisterOrDeleteDuplicate%28base%3A%3AHistogramBase+*%29%27%29&stbtiq=&reportid=&index=0#3

contains 1025 reports for which the crash server shows a thread stuck on:

(chrome.dll -new_scalar.cpp:35 )          operator new(unsigned __int64)
(chrome.dll -xstring:3876 )               std::basic_string<...>
(chrome.dll -statistics_recorder.cc:115 ) base::StatisticsRecorder::RegisterOrDeleteDuplicate(base::HistogramBase *)
(chrome.dll -histogram.cc:247 )           base::Histogram::Factory::Build()
(USER32.dll + 0x0000297f )	          TranslateMessageEx

However, when I open a few of these reports in Windbg, I don't see a thread with this stack. In some reports, I instead see a thread with this stack (which doesn't appear in crash):

ntdll!NtWaitForSingleObject+0xa
KERNELBASE!CreateProcessInternalW+0x2e5e
KERNELBASE!CreateProcessAsUserW+0x63
ADVAPI32!CreateProcessAsUserWStub+0x5f
chrome_exe!sandbox::TargetProcess::Create+0xd9 [sandbox\win\src\target_process.cc @ 165] 
chrome_exe!sandbox::BrokerServicesBase::SpawnTarget+0x611 [sandbox\win\src\broker_services.cc @ 461] 
service_manager::SandboxWin::StartSandboxedProcess+0xb2e [services\service_manager\sandbox\win\sandbox_win.cc @ 999] 
content::StartSandboxedProcess+0x1b7 [content\common\sandbox_init_win.cc @ 52] 
content::internal::ChildProcessLauncherHelper::LaunchProcessOnLauncherThread+0xf0 [content\browser\child_process_launcher_helper_win.cc @ 76] 
content::internal::ChildProcessLauncherHelper::LaunchOnLauncherThread+0xc1 [content\browser\child_process_launcher_helper.cc @ 114] 
base::debug::TaskAnnotator::RunTask+0x120 [base\debug\task_annotator.cc @ 99] 
base::internal::TaskTracker::RunOrSkipTask+0x23e [base\task\task_scheduler\task_tracker.cc @ 654] 
base::internal::TaskTracker::RunAndPopNextTask+0xf0 [base\task\task_scheduler\task_tracker.cc @ 509] 
base::internal::SchedulerWorker::RunWorker+0x402 [base\task\task_scheduler\scheduler_worker.cc @ 331] 
base::internal::SchedulerWorker::RunDedicatedWorker+0x20 [base\task\task_scheduler\scheduler_worker.cc @ 248] 
base::`anonymous namespace'::ThreadFunc+0xbd [base\threading\platform_thread_win.cc @ 103] 
KERNEL32!BaseThreadInitThunk+0x22
ntdll!RtlUserThreadStart+0x34

e.g. http://crash/0273a4b029890929

Not getting the right stack from the crash server makes the analysis of the problem much more complicated.