It seems specifying /FIXED isn't sufficient to get it to work, therefore it might make more sense to just leave executables as dynamic base but only disable it for DLLs. The alternative is to only disable dynamic base for chrome.dll which seems to be the entire purpose of the endeavor. 

Adding robliao@ is case he's got any objections from a WinDBG user perspective. Reference https://chromium.googlesource.com/chromium/src/+/3f073d71053f12f66f67e94ed8b397ca34652ada/build/config/win/BUILD.gn#267.

After further investigation and discussion with Bruce it would make some sense to remove the use of /DYNAMICBASE:NO entirely for debug builds and always build with the flag base flag. This is for two main reasons:

1) Currently chrome_elf.dll is loaded before chrome.dll. As we don't specify separate load addresses for each then they get the default. This results in chrome_elf.dll taking the default load_address with chrome.dll having to be force relocated making the removal of dynamic base moot. We could potentially fix this by specifying a separate address for chrome.dll or chrome_elf.dll but that feels like we're piling on the hacks to support a niche use case.

2) Recent versions of the Window debug engine (used by WinDBG), tested on version 10.0.16299.15, have changed the module naming behavior. When chrome is first debugged chrome.exe is mapped to the module name 'chrome', however when chrome.dll is loaded the engine renames the exe module to 'chrome_exe' and adds chrome.dll as 'chrome'. This completely breaks any hope of setting delayed breakpoints as if you set a breakpoint using 'bu' on 'chrome' if that symbol doesn't exist in the main executable the debugger will stop with an invalid breakpoint error. If it does exist then it will breakpoint on the function in chrome.exe (common issue for base code) but that breakpoint will never migrate once chrome.dll is loaded and takes the 'chrome' module name. 

Ultimately for reasons of debugging perhaps we should investigate whether there's any continuing reason for keep the name chrome.dll and not changing it to say chrome_main.dll. Perhaps we could leave a chrome.dll present temporarily which forwards all its exports to the real chrome dll until we're sure there's nothing relying on this behavior? Perhaps it's primarily an issue of crash reporting?

The result of this discussion is that in its present form removing DYNAMICBASE from debug builds isn't providing much in the way of direct value for the debugger but is blocking debugging of AppContainer so it'll be removed.

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

commit 74b3d06052ba093cf7ca45afb4a5ede5d7b10e73
Author: James Forshaw <forshaw@chromium.org>
Date: Thu Feb 01 22:20:20 2018

Enable /DYNAMICBASE for debug builds on Windows.

This CL changes the build behavior for debug builds to always pass the
/DYNAMICBASE flag which enables ASLR relocation of executables. The
removal of /DYNAMICBASE from debug builds interacts badly with the
sandbox and a new feature to add AppContainer support as the OS
enables an option to force ASLR regardless of whether an executable has
been built with /DYNAMICBASE or not. The rationale for disabling ASLR
was to simplify debugging in the WinDBG debugger due to the name
conflict between chrome.exe and chrome.dll. However due to changes
in the underlying debug engine as well as chrome_elf.dll loading
before chrome.dll this no longer makes it useful.

Bug:  807267 
Change-Id: I651d2b1aa2eb970cc02e7063b5467144c69d23be
Reviewed-on: https://chromium-review.googlesource.com/897623
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: James Forshaw <forshaw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533836}
[modify] https://crrev.com/74b3d06052ba093cf7ca45afb4a5ede5d7b10e73/build/config/win/BUILD.gn