01 vs2017 调试chromium 频繁崩溃
在调试chromium代码的时候，vs2017有时会频繁出现崩溃。
优先尝试：
工具==>选项==>调试==>常规
[一个进程中断时则中断所有进程] 的勾选去掉。
还可以尝试如下操作：
1 尝试删除项目文件夹下面的.vs文件夹
2 %LocalAppData%\Microsoft\VisualStudio\15.0_xxx
3 尝试安全模式启动vs2017
在相关路径下（C:\Program Files (x86)\Microsoft Visual Studio\2017\versioname\Common7\IDE ）运行devenv /safemode
另外：编译chromium 最好不要安装windows 驱动开发的sdk。
4 不要加载太多符号文件
工具==>选项==>调试==>符号==>只加载指定项
02 其他尝试
不知为何，更新了vs2017以后，又把chromium代码更新到 71，编译debug/Release都正常。调试debug版本，vs2017会自动无提示重启。看vs2017异常日志。提示内存不足。实际上是32GB的内存。应该不存在内存不足的问题。升级后，无法退回到15.7版本。也没找到可以仅仅安装15.7，不带15.9的安装方法。
尝试了一下各种方法。都没有解决调试崩溃的问题。
直接换装 15.9.2/15.9.1/15.8,调试chromium 71.0.3538.xxx依然崩溃(运行正常)。
卸载重新安装15.9.2，调试依然崩溃。
安装15.7.x(14.14 toolset),需要手工删除 Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26405。这里面是arm相关的头文件。不知道为啥win10 安装会带上。不过，调试 chromium的时候依然崩溃。
依次卸载vs2017以安装插件测试，调试chromium依然崩溃。
做如下操作也无效果
devenv /resetuserdata
devenv /resetsettings
管理员权限：
cd D:\install\Microsoft Visual Studio\2017\Community\Common7\IDE\PublicAssemblies
gacutil -i Microsoft.VisualStudio.Shell.Interop.11.0.dll
清理vs2017的所有临时缓存，无效果
03 问题缓解
调试chromium的x64位版本。问题得到缓解，崩溃概率稍微降低。
vs2017虽然还是32位程序，但是调试x64的chromium，不崩溃了。
整个过程，vs2017占用内存不超过4GB，chromium总内存调试时，最大不到1GB。
如果调试chromium x86版本，设置断点后，就会频繁崩溃。调试chromium x64没这个问题。
附chromium(zdx) 32位程序崩溃时内存使用情况图，如下:chrome大约占用500MB, vs2017占用 2.9GB。处于调试状态后，一般就会崩溃。
应该是VS+被调试程序的共内存数大约32位程序限制，就会崩溃。这个时候，vs2017崩溃，不会有提示。查看vs2017的运行日志(%temp%\MSBuild_pid-*)，错误报告如下:
vs2017错误日志:%temp%\MSBuild_pid-2392_bbee76ab853743a28f0b6f96d8e6378e.failure.txt
UNHANDLED EXCEPTIONS FROM PROCESS 2392:
=====================
2018-11-23 10:24:23
System.OutOfMemoryException: 没有足够的内存继续执行程序。
在 System.Windows.Media.Composition.DUCE.Channel.BeginCommand(Byte* pbCommandData, Int32 cbSize, Int32 cbExtra)
在 System.Windows.Media.GlyphRun.CreateOnChannel(Channel channel)
在 System.Windows.Media.GlyphRun.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel channel)
在 System.Windows.Media.RenderData.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel channel)
在 System.Windows.UIElement.RenderContent(RenderContext ctx, Boolean isOnChannel)
在 System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
在 System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle)
在 System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
在 System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle)
在 System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
在 System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle)
在 System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
在 System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle)
在 System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
在 System.Windows.Media.Visual.UpdateChildren(RenderContext ctx, ResourceHandle handle)
在 System.Windows.Media.Visual.RenderRecursive(RenderContext ctx)
在 System.Windows.Media.Visual.Render(RenderContext ctx, UInt32 childIndex)
在 System.Windows.Media.CompositionTarget.Compile(Channel channel)
在 System.Windows.Media.CompositionTarget.System.Windows.Media.ICompositionTarget.Render(Boolean inResize, Channel channel)
在 System.Windows.Media.MediaContext.Render(ICompositionTarget resizedCompositionTarget)
在 System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget)
在 System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget)
在 System.Windows.Media.MediaContext.Resize(ICompositionTarget resizedCompositionTarget)
在 System.Windows.Interop.HwndTarget.OnResize()
在 System.Windows.Interop.HwndTarget.HandleMessage(WindowMessage msg, IntPtr wparam, IntPtr lparam)
在 System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
在 MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
在 MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
在 System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
在 System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
在 System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
在 MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
在 MS.Win32.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
在 MS.Win32.HwndSubclass.DefWndProcWrapper(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
在 MS.Win32.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
在 MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
===================
04 停用vs2017的 ClangFormat
工具==>文本编辑器==>C/C++==>格式设置==>不勾选[启用ClangFormat支持]
尝试用vs自带的clang2调试，效果一样。(默认使用clang编译)
05 崩溃概率极大的一处断点
chromium 71.0.3578.65
vs2017 15.9.2
src\google_apis\gaia\gaia_auth_fetcher.cc
void GaiaAuthFetcher::OnURLLoadComplete(
单进程调试也崩溃 --single-process
单进程禁用插件调试也崩溃 --single-process --disable-plugins
06 更新vs2017 企业版测试，问题依旧
按照vs2017企业版本，带15.9.2，15.7 toolset，问题依然存在。
工具 ==> 选项 ==> IntelliTrace ⇒ 高级 ⇒ [每个记录所占用的最大磁盘空间(A)]，选择100MB
工具 ==> 选项 ==> 调试 ⇒ 符号 ⇒ [仅加载指定的模块]
诊断空间 ⇒ 属性 ⇒ 常规 ⇒ [去掉 “启用资源使用限制”]
07 在微软官网社区找到一个提问。没解决
Crash when debugging chromium
你已就此问题进行表决
报告人 alson，报告时间 2018/8/30 下午8:54:52
正在考虑Visual Studio 2017 version 15.8Windows 10.0Debuggercrash
Crash when debugging chromium
set up some break points and crashes all the time.
Did a crash dump
2018/9/11 上的 Cagri (Charlie) Aslan [MSFT]
Thanks for the feedback. Looking at the dump, Visual Studio is running out of memory. We are working on improving our memory usage during debugging for the future releases of VS. In the meantime, you can try selecting ‘load symbols only for specified modules’ option in the symbol settings dialog to help with the memory usage in the IDE.
2018/11/23 上的 wstcwps
这个问题应该是 vs2017+被调试程序的总内存>3.2GB引起的。vs2017的运行日志，在崩溃时显示如下。UNHANDLED EXCEPTIONS FROM PROCESS 3520:=====================2018-11-23 10:47:20System.OutOfMemoryException: 没有足够的内存继续执行程序。 在 System.Windows.Media.Composition.DUCE.Channel.BeginCommand(Byte* pbCommandData, Int32 cbSize, Int32 cbExtra) 在 System.Windows.Media.GlyphRun.CreateOnChannel(Channel channel) 在 System.Windows.Media.GlyphRun.System.Windows.Media.Composition.DUCE.IResource.AddRefOnChannel(Channel channel)被调试的程序采用x86的时候，设置断点调试，崩溃率极高。无法工作。把被调试程序改为x64位编译时，崩溃频率有所降低。观察下来，主要时被调试程序，总体占用内存在调试时比x86编译少。我本机调试发生崩溃时， vs2017的总内存占用大约 2.9GB。x86 chromium 内存占用大约0.5GB；x64 chromium内存占用大约0.3GB左右。还没想出解决思路。少设断点，在调试到断点处稍微等待后，在进行下一步操作。崩溃率会降低。
08 另外一例情况
vs2017 15.6.6 chromium67，也出现过调试到断点崩溃情况，不过频率不是特别高（大约10%吧），基本是电脑运行久了会出现，vs重启后就好了，x86/x64情况差不多，影响倒不大就没分析原因，重启电脑效果更好，应该还是内存相关问题。
这一列中，编译关闭了clang选项。is_clang=false
09 终极解决办法
1 vs2017工程中仅加载自己调试的模块
2 仅加载自己调试需要的符号文件
工具 ==> 选项 ==> 调试 ⇒ 符号 ⇒ [仅加载指定的模块]
10 不知道如何[只安装vs2017的老版本]?
很遗憾，vs2017升级到15.9.0/.1/.2版本后，没找到怎么仅仅按照老版本15.7.x。可以按照15.7.x 的toolset。但是默认一定会被按照19.2。vs也越来越体贴了。
11 英文版本和中文版本没有区别
安装英文语言包，切换到英文版本调试，出现该问题的频率基本不变。
工具 ⇒ 选项 ⇒ 环境 ⇒ 区域设置 ⇒ 语言(切换到English，重启vs2017)
12 期待vs2019
根据微软官方宣传，vs2019中将解决特大工程内存不足类问题。
期待vs2019 update2， 如果真能解决内存异常问题，调试tensorflow代码能方便些。期待中…
https://docs.microsoft.com/zh-cn/visualstudio/releases/2019/release-notes-preview#debugging
微软官方宣传语:对于在 Windows 上运行的 C++ 应用程序，PDB 现可在单独的 64 位进程中加载。 此更改解决了在调试包含大量模块和 PDB 的应用程序时，由调试程序耗尽内存导致的一系列故障。
