Chrome Version: Version 62.0.3181.0 (Official Build) canary (64-bit)
OS: Windows 10 14393 (Anniversary Edition) on Google work station

What steps will reproduce the problem?
(1) Set a symbol server path in _NT_SYMBOL_PATH, such as set _NT_SYMBOL_PATH=SRV*C:\symbols*https://msdl.microsoft.com/download/symbols;SRV*C:\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com and make sure c:\symbols is populated with lots of directories
(2) Use procmon or ETW to monitor access to c:\symbols
(3) Launch canary

Canary was launched with this command line, from a command prompt with _NT_SYMBOL_PATH set.

"C:\Users\brucedawson\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --user-data-dir=c:\src\temp\profile_03 https://www.dailymotion.com/video/x489k7d_street-performer-shows-off-slinky-skills_fun?autoplay=false

What is the expected result?

No access to c:\symbols

What happens instead?

Most of the files in c:\symbols are enumerated with a total of more than 6,000 4 KiB read operations.

The call stack for the read operations is:

  ntdll.dll!RtlUserThreadStart
  kernel32.dll!BaseThreadInitThunk
  chrome.dll!base::`anonymous namespace'::ThreadFunc
  chrome.dll!base::internal::SchedulerWorker::Thread::ThreadMain
  chrome.dll!base::internal::TaskTracker::RunNextTask
  chrome.dll!base::internal::TaskTracker::PerformRunTask
  chrome.dll!base::debug::TaskAnnotator::RunTask
  chrome.dll!base::`anonymous namespace'::PostTaskAndReplyRelay::RunTaskAndPostReply
  chrome.dll!base::internal::Invoker<base::internal::BindState<void (*)(base::Callback<void (bool), base::internal::CopyMode::MoveOnly, base::internal::RepeatMode::Once>, bool *), base::Callback<void (bool), base::internal::CopyMode::MoveOnly, base::internal::RepeatMode::Once>, base::internal::OwnedWrapper<bool> >, void ()>::RunOnce
  chrome.dll!base::internal::ReturnAsParamAdapter<std::unique_ptr<InstalledPrograms::ProgramsData,std::default_delete<InstalledPrograms::ProgramsData> > >
  chrome.dll!base::internal::Invoker<base::internal::BindState<std::unique_ptr<InstalledPrograms::ProgramsData, std::default_delete<InstalledPrograms::ProgramsData> > (*)(std::unique_ptr<MsiUtil, std::default_delete<MsiUtil> >), std::unique_ptr<MsiUtil, std::default_delete<MsiUtil> > >, std::unique_ptr<InstalledPrograms::ProgramsData, std::default_delete<InstalledPrograms::ProgramsData> > ()>::RunOnce
  chrome.dll!`anonymous namespace'::GetProgramsData
  chrome.dll!MsiUtil::GetMsiComponentPaths
  msi.dll!MsiGetComponentPathW
  msi.dll!GetComponentPathInternal
  msi.dll!_GetComponentPath
  msi.dll!MsiGetFileAttributesEx
  KernelBase.dll!GetFileAttributesExW

Note that some of the crucial functions are inlined and are therefore not visible in the call stack.

The access to c:\symbols could be triggered partially by this code:

https://cs.chromium.org/chromium/src/base/debug/stack_trace_win.cc?rcl=5d0ea383e300bdbd091e262c573f4de49cb3c603&l=49

but ultimately GetProgramsData() seems to be more expensive than expected on some machines, with its execution spanning several seconds (???) on my machine.

ETW traces, such as "2017-08-10_15-42-20 chrome disk IO test third run.etl", available by request.