Activeverifier has always been this way. Looking back in time there's always a fraction of ActiveVerifier::OnHandleBeingClosed living in the DLL and a fraction living in EXE.

the data backing this up is here -> https://plx.corp.google.com/script/#a=qo%7Ci=google%253A%253Ascript_3a._c63478_4f9f_40c4_a46f_d0188f58a2b0

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

commit 1f9673dbd1b71cfa5a0dc5ab06509368153bcb20
Author: wfh <wfh@chromium.org>
Date: Wed Mar 09 00:33:02 2016

Add creation tracking for ActiveVerifier.

Sometimes the ActiveVerifier gets instantiated inside chrome_child's
copy of base and sometimes inside chrome.exe's copy of base.

The ActiveVerifier should only be running from chrome.exe's copy of base,
but before enforcing this, am adding a check to determine what is causing
this unpredictability.

See bug for the gory details.

BUG=592753

Review URL: https://codereview.chromium.org/1767293005

Cr-Commit-Position: refs/heads/master@{#379996}

[modify] https://crrev.com/1f9673dbd1b71cfa5a0dc5ab06509368153bcb20/base/win/scoped_handle.cc

The reason for this is that currently handle verifier is instantiated in the module that first uses the code i.e. first creates a scoped handle.

The reason for the variation is because there is currently a fieldtrial to sometimes do preread of the chrome.dll.

This code means that where the first scoped handle is created varies.

Sometimes it's in 

chrome!`anonymous namespace'::PreReadFileUsingReadFile
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/app/file_pre_reader_win.cc&sq=package:chromium&l=20

otherwise it's in

chrome_child!base::i18n::`anonymous namespace'::LazyInitIcuDataFile
https://code.google.com/p/chromium/codesearch#chromium/src/base/i18n/icu_util.cc&sq=package:chromium&l=142

this is fine so this is mostly FYI... but what I'll probably do is change this to be more deterministic by instantiating the handle verifier earlier in startup, always in chrome.exe

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

commit 678736a103c3e64acdce5e76910ff077b17cc6c3
Author: wfh <wfh@chromium.org>
Date: Fri Mar 11 08:41:04 2016

Two HandleVerifier thread safety fixes.

Two changes in this CL:

1. Before setting the g_active_verifier, check that another thread hasn't
already set this. This is to cater for the situation where multiple
threads attempt to create the handle verifier in the same module at the
same time. The g_lock was not protecting the check to see if the handle
verifier had already been instantiated by another thread before setting
it. This could result in a handle verifier leaking and some handles
being tracked in the leaked verifier.

2. Always instantiate the handle verifier inside the main module, unless
the main module does not link with base. This means that there should be
always one instance that lives in the main module.

BUG=592753
TEST=base_unittests

Review URL: https://codereview.chromium.org/1772343007

Cr-Commit-Position: refs/heads/master@{#380581}

[modify] https://crrev.com/678736a103c3e64acdce5e76910ff077b17cc6c3/base/win/scoped_handle.cc

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

commit 8f20e83de53c12033403e198b903f81112625d0b
Author: wfh <wfh@chromium.org>
Date: Sat Mar 12 02:09:59 2016

Add test for multithreaded ActiveVerifier behavior.

Previous to crrev.com/678736a there was a race in the setting of the
g_active_verifier global that could have caused multiple instantiations.

This adds a test to verify the new behavior and detect any future
regressions. The test failing with the old code can be seen here:

http://pastebin.com/raw/iXz8j21C

BUG=592753
TEST=base_unittests --gtest_filter=ScopedHandleTest.MultiProcess

Review URL: https://codereview.chromium.org/1779333003

Cr-Commit-Position: refs/heads/master@{#380835}

[modify] https://crrev.com/8f20e83de53c12033403e198b903f81112625d0b/base/BUILD.gn
[modify] https://crrev.com/8f20e83de53c12033403e198b903f81112625d0b/base/base.gyp
[modify] https://crrev.com/8f20e83de53c12033403e198b903f81112625d0b/base/base_switches.cc
[modify] https://crrev.com/8f20e83de53c12033403e198b903f81112625d0b/base/base_switches.h
[modify] https://crrev.com/8f20e83de53c12033403e198b903f81112625d0b/base/test/test_suite.cc
[modify] https://crrev.com/8f20e83de53c12033403e198b903f81112625d0b/base/win/scoped_handle.cc
[modify] https://crrev.com/8f20e83de53c12033403e198b903f81112625d0b/base/win/scoped_handle.h
[add] https://crrev.com/8f20e83de53c12033403e198b903f81112625d0b/base/win/scoped_handle_test_dll.cc
[modify] https://crrev.com/8f20e83de53c12033403e198b903f81112625d0b/base/win/scoped_handle_unittest.cc

ScopedHandleTest.MultiProcess is flaky on DrMemory bot. wfh@ can you take a look?

[ RUN      ] ScopedHandleTest.MultiProcess
~~Dr.M~~ SYMCACHE ERROR: api-ms-win-crt-heap-l1-1-0.dll file has too-large entry 0xfa8b5ec0 for _msize
c:\b\build\slave\drm-cr\build\src\base\win\scoped_handle_unittest.cc(114): error: Value of: test_child_process.WaitForExitWithTimeout( TestTimeouts::action_timeout(), &rv)
  Actual: false
Expected: true

https://build.chromium.org/p/chromium.memory.fyi/builders/Windows%20Unit%20%28DrMemory%20full%29%20%282%29/builds/10275
https://build.chromium.org/p/chromium.memory.fyi/builders/Windows%20Unit%20%28DrMemory%20full%29%20%282%29/builds/10273
https://build.chromium.org/p/chromium.memory.fyi/builders/Windows%20Unit%20%28DrMemory%20full%29%20%282%29/builds/10263

This test starts a new process then starts 200 threads inside this child process. would there be an issue with drmemory keeping track of this?

I can try and repro when I get back into the office next week.

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

commit 730968b08daed211500b2e0828af15302125d9f7
Author: tommycli <tommycli@chromium.org>
Date: Mon Mar 21 22:35:21 2016

Memory Sheriff: Exclude ScopedHandleTest.MultiProcess from Dr. Memory

Test times out.

wfh@ to investigate either fixing test or making exclusion permanent.

BUG=592753
TBR=wfh@chromium.org

Review URL: https://codereview.chromium.org/1820083002

Cr-Commit-Position: refs/heads/master@{#382420}

[modify] https://crrev.com/730968b08daed211500b2e0828af15302125d9f7/tools/valgrind/gtest_exclude/base_unittests.gtest-drmemory_win32.txt