Might be caused by r434855 ( issue 565446 ) that modifies policy path expansion code on Windows among other things:
https://crrev.com/2487783002/diff/500001/chrome/browser/policy/policy_path_parser_win.cc

Try checking snapshots before and after the change:
434838: https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/434838/
434861: https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/434861/

I have added 
[HKEY_CURRENT_USER\Software\Policies\Chromium]
"UserDataDir"="C:\\Temp\\${user_name}\\Browser\\Chromium\\User Data"
to registry and both snapshots work for me. I have checked some other snapshots and it looks like chrome is crashing after 439175.

439175 ok: https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/439175/
439191 not ok: https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/439191/

Confirming and narrowing down #5 via mixed x64/x86 bisect with the provided registry info:

439179 (good) - 439191 (bad), 57.0.2954.0
https://chromium.googlesource.com/chromium/src/+log/3784517e..2776787d?pretty=fuller
Suspecting r439188 "Make Crashpad start asynchronous, and move back to chrome_elf"

[Bulk Edit]
Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M58.

Wasn't able to repro with a debug build at head, so it's likely due to DLL loading order; probably advapi32 I guess. Building release now.

Yeah. :(

This path will cause a LoadLibrary() of advapi32 during DllMain of chrome_elf.

 	chrome_elf.dll!install_static::`anonymous namespace'::GetUserDataDirFromRegistryPolicyIfSet(const install_static::InstallConstants & mode, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * user_data_dir) Line 28	C++
 	chrome_elf.dll!install_static::GetUserDataDirectoryImpl(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & user_data_dir_from_command_line, const install_static::InstallConstants & mode, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * result, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * invalid_supplied_directory) Line 111	C++
 	chrome_elf.dll!install_static::`anonymous namespace'::GetUserDataDirectoryUsingProcessCommandLine(const install_static::InstallConstants & mode, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * result, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * invalid_supplied_directory) Line 65	C++
 	chrome_elf.dll!install_static::GetUserDataDirectory(std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * user_data_dir, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * invalid_user_data_dir) Line 143	C++
 	chrome_elf.dll!install_static::GetCrashDumpLocation() Line 452	C++
 	chrome_elf.dll!ChromeCrashReporterClient::GetCrashDumpLocation(std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * crash_dir) Line 370	C++
>	chrome_elf.dll!crash_reporter::internal::PlatformCrashpadInitialization(bool initial_client, bool browser_process, bool embedded_handler) Line 69	C++
 	chrome_elf.dll!crash_reporter::`anonymous namespace'::InitializeCrashpadImpl(bool initial_client, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & process_type, bool embedded_handler) Line 125	C++
 	chrome_elf.dll!crash_reporter::InitializeCrashpadWithEmbeddedHandler(bool initial_client, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & process_type) Line 203	C++
 	chrome_elf.dll!ChromeCrashReporterClient::InitializeCrashReportingForProcess() Line 261	C++
 	chrome_elf.dll!elf_crash::InitializeCrashReporting() Line 79	C++
 	chrome_elf.dll!DllMain(HINSTANCE__ * module, unsigned long reason, void * reserved) Line 40	C++

I'm not able to repro the crash in a Release build either (at head). Looking at the loaded modules where ${user_name} is expanded, at head I see advapi32.dll is loaded already which doesn't really make sense this early in chrome_elf's DllMain.

So maybe there's something that's Official only in the reordering/dependencies? Or maybe there's been a regression in which dlls are loaded between 57 and 59? So, still trying to repro.

A straight revert of https://crrev.com/439188 is likely the safest fix for merging to stable if it works, but I'd like to repro locally before doing that.

It doesn't repro for me on 57.0.2987.98 (64-bit) after setting HKCU\SOFTWARE\Policies\Google\Chrome\UserDataDir = c:\tmp\${user_name}\zippy.

It does seem like the code is wrong, but it would be really good to have a local repro before attempting a fix.

Thanks to Prudhvi for pointing out 2008R2/7. I can repro with 57.0.2987.98 on Win7.

I'm working on reverting that CL and testing the fix.

I'm also not sure that there's any point to chrome_elf now, since advapi32 is already loaded at this point in chrome_elf main on Windows 10! So we need to look into that as a separate issue.

Revert off branch 2987 here: https://codereview.chromium.org/2736393005/.

Trunk revert here: https://codereview.chromium.org/2743923003

I think it's safer to do a straight revert off the 2987 branch with https://codereview.chromium.org/2736393005/ because merging the trunk back to 57 is more complicated than simply reverting on the branch.

We can defer the merge until https://codereview.chromium.org/2743923003 goes out on Canary though if you'd like.

This bug requires manual review: Only 3 days from stable, we might already have a stable candidate build
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Follow up for side note in #c15 is here: https://bugs.chromium.org/p/chromium/issues/detail?id=700509.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/616b30a936244b12170072859a0ca988459a6a1b

commit 616b30a936244b12170072859a0ca988459a6a1b
Author: scottmg <scottmg@chromium.org>
Date: Fri Mar 10 23:58:08 2017

Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

See bug for details of regression.

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb which was:

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

TBR=mark@chromium.org, thestig@chromium.org, grt@chromium.org
BUG= 700371 

Review-Url: https://codereview.chromium.org/2743923003
Cr-Commit-Position: refs/heads/master@{#456221}

[modify] https://crrev.com/616b30a936244b12170072859a0ca988459a6a1b/chrome/app/chrome_exe_main_win.cc
[modify] https://crrev.com/616b30a936244b12170072859a0ca988459a6a1b/chrome/browser/chrome_browser_main.cc
[modify] https://crrev.com/616b30a936244b12170072859a0ca988459a6a1b/chrome_elf/chrome_elf.def
[modify] https://crrev.com/616b30a936244b12170072859a0ca988459a6a1b/chrome_elf/chrome_elf_main.cc
[modify] https://crrev.com/616b30a936244b12170072859a0ca988459a6a1b/chrome_elf/chrome_elf_main.h
[modify] https://crrev.com/616b30a936244b12170072859a0ca988459a6a1b/components/crash/content/app/crashpad.cc
[modify] https://crrev.com/616b30a936244b12170072859a0ca988459a6a1b/components/crash/content/app/crashpad.h
[modify] https://crrev.com/616b30a936244b12170072859a0ca988459a6a1b/components/crash/content/app/crashpad_win.cc

Please request a merge to M58 as well. Thank you.

Looks like this broke the SyzyASAN build, which won't link for lack of a BlockUntilHandlerStartedImpl.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0bf96470b9eaf061401b4696979694bfc8340eae

commit 0bf96470b9eaf061401b4696979694bfc8340eae
Author: siggi <siggi@chromium.org>
Date: Mon Mar 13 16:52:20 2017

Fix SyzyASAN build now that chrome_elf!BlockUntilHandlerStartedImpl is gone.

TBR=grt@chromium.org
BUG= 700371 

Review-Url: https://codereview.chromium.org/2743383002
Cr-Commit-Position: refs/heads/master@{#456401}

[modify] https://crrev.com/0bf96470b9eaf061401b4696979694bfc8340eae/chrome/app/chrome_exe_main_win.cc

Verified the issue got fixed on latest Chrome canary i.e., 59.0.3040.0 on Windows 7 and 10 with Chrome MSI and regular binary install. 

Steps followed :
1. Set GPO policy "Set user data directory" to "C:\Temp\${user_name}\Browser\Google\Chrome\User Data"
2 Install Chrome 59.0.3040.0(32 or 64 bit)
3. Launch Chrome and make sure User data directory is set through GPO policy.

Observed behavior : 
Able to launch Chrome and browse web.

Thank you Prudvhi.

wfh@, will this be a safe merge to M57 just double checking based on comment #23?

yes I will merge now

Approving merge to M57 branch 2987 based on comment #26 and #28.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/24b232ed824889b3b14b462a389fb42fcaa50b67

commit 24b232ed824889b3b14b462a389fb42fcaa50b67
Author: scottmg <scottmg@chromium.org>
Date: Mon Mar 13 20:49:16 2017

Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb.

See linked bug for details.

R=mark@chromium.org, thestig@chromium.org, grt@chromium.org
BUG= 700371 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2736393005
Cr-Commit-Position: refs/branch-heads/2987@{#816}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/24b232ed824889b3b14b462a389fb42fcaa50b67/chrome/app/chrome_exe_main_win.cc
[modify] https://crrev.com/24b232ed824889b3b14b462a389fb42fcaa50b67/chrome/browser/chrome_browser_main.cc
[modify] https://crrev.com/24b232ed824889b3b14b462a389fb42fcaa50b67/chrome_elf/chrome_elf.def
[modify] https://crrev.com/24b232ed824889b3b14b462a389fb42fcaa50b67/chrome_elf/chrome_elf_main.cc
[modify] https://crrev.com/24b232ed824889b3b14b462a389fb42fcaa50b67/chrome_elf/chrome_elf_main.h
[modify] https://crrev.com/24b232ed824889b3b14b462a389fb42fcaa50b67/components/crash/content/app/crashpad.cc
[modify] https://crrev.com/24b232ed824889b3b14b462a389fb42fcaa50b67/components/crash/content/app/crashpad.h
[modify] https://crrev.com/24b232ed824889b3b14b462a389fb42fcaa50b67/components/crash/content/app/crashpad_win.cc
[modify] https://crrev.com/24b232ed824889b3b14b462a389fb42fcaa50b67/tools/metrics/histograms/histograms.xml

scottmg@, could you please write a postmortem for this. Thank you.

This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M58 branch 3029 based on comment #29. 

govind@, I will make a single postmortem for this and 700615 as the issues are similar.

Re #35: OK,Sounds good. Thank you georgesak@.

Your change is approved for M58. Please merge ASAP so that it will be picked up for M58 Beta promotion RC cut today(Wednesday-03/15) at 5.00 PM PST.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5cd5ecf81546468f888891a354027bd9689ee0f2

commit 5cd5ecf81546468f888891a354027bd9689ee0f2
Author: Will Harris <wfh@chromium.org>
Date: Wed Mar 15 18:53:07 2017

Merge M58: Revert "Make Crashpad start asynchronous, and move back to chrome_elf"

This reverts commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb.

See linked bug for details.

R=mark@chromium.org, grt@chromium.org, thestig@chromium.org
BUG= 700371 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2736393005
Cr-Commit-Position: refs/branch-heads/2987@{#816}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}
(cherry picked from commit 24b232ed824889b3b14b462a389fb42fcaa50b67)

Review-Url: https://codereview.chromium.org/2751883004 .
Cr-Commit-Position: refs/branch-heads/3029@{#211}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/5cd5ecf81546468f888891a354027bd9689ee0f2/chrome/app/chrome_exe_main_win.cc
[modify] https://crrev.com/5cd5ecf81546468f888891a354027bd9689ee0f2/chrome/browser/chrome_browser_main.cc
[modify] https://crrev.com/5cd5ecf81546468f888891a354027bd9689ee0f2/chrome_elf/chrome_elf.def
[modify] https://crrev.com/5cd5ecf81546468f888891a354027bd9689ee0f2/chrome_elf/chrome_elf_main.cc
[modify] https://crrev.com/5cd5ecf81546468f888891a354027bd9689ee0f2/chrome_elf/chrome_elf_main.h
[modify] https://crrev.com/5cd5ecf81546468f888891a354027bd9689ee0f2/components/crash/content/app/crashpad.cc
[modify] https://crrev.com/5cd5ecf81546468f888891a354027bd9689ee0f2/components/crash/content/app/crashpad.h
[modify] https://crrev.com/5cd5ecf81546468f888891a354027bd9689ee0f2/components/crash/content/app/crashpad_win.cc
[modify] https://crrev.com/5cd5ecf81546468f888891a354027bd9689ee0f2/tools/metrics/histograms/histograms.xml

re #35: (please see go/chrome-postmortems for the process to follow). Thank you.

 Issue 701705  has been merged into this issue.

We are encountering the same problem (same environment Windows Server 2008 R2/Citrix 6.5) when using variable ${client_name}.

Chrome crashes when "Set user data directory" is set to "${local_app_data}\Google\Chrome\UserData${client_name}"

Chrome starts without setting ${client_name}, e.g. "${local_app_data}\Google\Chrome\UserData"

Verified the issue got fixed on latest Chrome canary i.e., 57.0.2987.110 on Windows 7 and 10 with Chrome MSI and regular binary install. 

Steps followed :
1. Set GPO policy "Set user data directory" to "C:\Temp\${user_name}\Browser\Google\Chrome\User Data"
2 Install Chrome 59.0.3040.0(32 or 64 bit)
3. Launch Chrome and make sure User data directory is set through GPO policy.

Observed behavior : 
Able to launch Chrome and browse web.

Can this be marked as fixed now?

I think so.

Tested the issue on Latest Beta# 58.0.3029.33 on Windows and found the issue has been fixed.

Was able to launch chrome and made sure User data directory is set through GPO policy and was able to launch Chrome and surf through the browser without any abnormal behavior.
Hence adding TE-Verified labels.
Thank You.

Requesting a postmortem for this (please see go/chrome-postmortems for the process to follow). Thank you.

re #c47, see #c35, I was going to leave it at that. I can create a separate one if we feel it's necessary though.

re #c48: sorry I missed #c35. No need to create separate one.