This page needs updating (set CHROME_ALLOCATOR=winheap has been obsolete for several years) and will need further updating once the sandbox issues are fixed:

https://sites.google.com/a/chromium.org/dev/developers/testing/page-heap-for-chrome?pli=1

When running chrome with the default App Verifier settings and --no-sandbox this failure is hit - the GdiInitializeLanguagePack failure mentioned above. The first call stack is when the critical section is initialized the first time, and the second time is when it is initialized the second time:

=======================================
VERIFIER STOP 00000211: pid 0xD72C: Critical section is already initialized. 

	76549620 : Critical section address. Run !cs -s <address> to get more information.
	FA3B4FE0 : Critical section debug info address.
	FE490D2C : First initialization stack trace. Use dps to dump it if non-NULL.
	00000000 : Not used.


4:056:x86> dps FE490D2C
fe490d2c  fe486604
fe490d30  0000c001
fe490d34  00190064
fe490d38  697d9603 vfbasics!AVrfpInitializeCriticalSectionCommon+0xf6
fe490d3c  697d9732 vfbasics!AVrfpRtlInitializeCriticalSectionAndSpinCount+0x12
fe490d40  75e24351 KERNELBASE!InitializeCriticalSectionAndSpinCount+0x11
fe490d44  764caa8d gdi32full!LpkInitialize+0xd
fe490d48  764ca7aa gdi32full!GdiProcessSetup+0x18a
fe490d4c  762abce5 USER32!__ClientThreadSetup+0x5
fe490d50  762abaef USER32!_UserClientDllInitialize+0x2b7
fe490d54  762ab834 USER32!UserClientDllInitialize+0x24
fe490d58  69858fd4 verifier_69840000!AVrfpStandardDllEntryPointRoutine+0xa4
fe490d5c  70df96da vrfcore!VfCoreStandardDllEntryPointRoutine+0x12a
fe490d60  697daa94 vfbasics!AVrfpStandardDllEntryPointRoutine+0xa4
fe490d64  774be746 ntdll_77450000!LdrxCallInitRoutine+0x16
fe490d68  7748cbef ntdll_77450000!LdrpCallInitRoutine+0x7f
fe490d6c  77487baa ntdll_77450000!LdrpInitializeNode+0x10e
fe490d70  77487a44 ntdll_77450000!LdrpInitializeGraphRecurse+0x5d
fe490d74  77487a63 ntdll_77450000!LdrpInitializeGraphRecurse+0x7c
fe490d78  77487a63 ntdll_77450000!LdrpInitializeGraphRecurse+0x7c
fe490d7c  77487a63 ntdll_77450000!LdrpInitializeGraphRecurse+0x7c
fe490d80  77487a63 ntdll_77450000!LdrpInitializeGraphRecurse+0x7c
fe490d84  77487a63 ntdll_77450000!LdrpInitializeGraphRecurse+0x7c
fe490d88  77487a63 ntdll_77450000!LdrpInitializeGraphRecurse+0x7c
fe490d8c  774f8d3a ntdll_77450000!LdrpInitializeProcess+0x1c66
fe490d90  774b3807 ntdll_77450000!_LdrpInitialize+0xec
fe490d94  774b370e ntdll_77450000!LdrpInitialize+0x34
fe490d98  774b36bc ntdll_77450000!LdrInitializeThunk+0x1c
fe490d9c  00000000
fe490da0  0000f001
fe490da4  001e0000
fe490da8  6984a8d0 verifier_69840000!AVrfDebugPageHeapAllocate+0x240

4:056:x86> kc
00 vrfcore!VerifierStopMessageEx
01 vfbasics!AVrfpInitializeCriticalSectionCommon
02 vfbasics!AVrfpRtlInitializeCriticalSectionAndSpinCount
03 KERNELBASE!InitializeCriticalSectionAndSpinCount
04 gdi32full!LpkInitialize
05 gdi32full!GdiInitializeLanguagePack
06 content!content::RenderProcessImpl::RenderProcessImpl
07 content!content::RenderProcessImpl::Create
08 content!content::RendererMain
09 content!content::RunNamedProcessTypeMain
0a content!content::ContentMainRunnerImpl::Run
0b content!content::ContentServiceManagerMainDelegate::RunEmbedderProcess
0c embedder!service_manager::Main
0d content!content::ContentMain
0e chrome!ChromeMain
0f chrome_exe!MainDllLoader::Launch
10 chrome_exe!wWinMain
11 chrome_exe!invoke_main
12 chrome_exe!__scrt_common_main_seh
13 chrome_exe!__scrt_common_main
14 chrome_exe!wWinMainCRTStartup
15 KERNEL32!BaseThreadInitThunk
16 ntdll_77450000!__RtlUserThreadStart
17 ntdll_77450000!_RtlUserThreadStart

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

commit a738a72356cd4b277f95049cae233b5c6059f8d3
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Wed Mar 07 04:38:28 2018

Remove GDI hack from Chrome's early days

In one of the early versions of Chrome it was found that it was
necessary to call the undocumented GdiInitializeLanguagePack function in
order to get printing to work. This now causes failures when running
under Application Verifier with --no-sandbox (a critical section gets
initialized twice) on Windows 10.

Bug:  807500 
Change-Id: Iff5d812a5a083b8ee94989bc74a3b22fff6d2c0f
Reviewed-on: https://chromium-review.googlesource.com/935982
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541328}
[modify] https://crrev.com/a738a72356cd4b277f95049cae233b5c6059f8d3/content/renderer/render_process_impl.cc

With  bug 752344  fixed and with  bug 836315  apparently by-design/unavoidable App Verifier is now usable with Chrome, with some restrictions. The following steps should probably be added to the developer documentation as the final step in resolving this bug, or maybe some remaining issues should be investigated more first:

In order to run Chrome with App Verifier enabled you have to (after installing App Verifier as part of the Platform SDK):
- Test with 64-bit versions of Chrome to avoid address-space exhaustion
- Run Application Verifier (be sure to shut down any non-compatible versions of Chrome before doing this)
- Add chrome.exe with File-> Add Application
- Disable Basics-> Leaks (we don't try to be leak-free at process shutdown)
- Disable Basics-> Handles (see 836315 for details - the sandbox queries some invalid handles by design)
For some machines/configurations this will be enough.

- For some builds (debug and release component-x86 builds in my testing) it is necessary to disable Basics-> TLS. The debug component build failures are obvious (aggressive v8 range checking) and I suspect the release-component-x86 failures (access violation) are just address-space exhaustion (works in 64-bit)
- For some machines you may need to disable Basics-> Locks due to video driver bugs (Intel's drivers, I will report this)
- On one run I saw an SRWLock failure but the stacks were ambiguous so I'm not sure where the problem lies, and it only happened once

App Verifier will create a log file for every non-sandboxed chrome process that is launched, doing a linear scan through existing log files, which means that process creation will gradually get slower. If you don't need the log files you can stop them from being created with "appverif -logtofile disable", or you can occasionally clear out the .dat files from C:\Users\brucedawson\AppVerifierLogs.

I've attached the windbg output from running 64-bit Chrome canary on my laptop with the Leaks and Handles checks disabled but the Locks check still enabled. It sure looks like an Intel driver bug.

Reported through email and here:
https://twitter.com/BruceDawson0xB/status/989154165854220288

Deleted: IntelLockViolation.txt 6.6 KB

IntelLockViolation.txt 6.6 KB View Download

This is fixed. You have to disable Leaks checks always, and Locks checks on some machines (Intel driver bug, see previous comment) but the Handles checks can now be enabled.

Note: on one test run I hit a failure when Chrome tried converting an invalid handle into a PID. I'm not sure what happened and I can't make it happen again. So, further testing with App Verifier is worthwhile, but this bug is fixed.

I've started testing Chrome with Handles and Locks checking enabled (now that I've got my video driver updated). This revealed  crbug.com/865805  (using closed process handles) and this webrtc abuse of critical sections: https://bugs.chromium.org/p/webrtc/issues/detail?id=9553