windbg

Advanced .Net Debugging 11：完结篇一、介绍　　　　这是我的《Advanced .Net Debugging》这个系列的第十一篇文章，也是这个系列的最后一篇了。我已经把原书的前八章内容全部写完了，本来打算继续写第九章和第十章的内容，后来我放弃逐章逐节的编写，选择了将两章的内容进行过滤后，合为一篇，只把重要的内容包含进来的做法。原因是，我看了原书的后两章内容后，发现很多章节都是一带而过的介绍工具如何使用，讲解的并不是很详细。还有一点更重要的原因就是【高级调试所涉及的知识点】已经全部包含在前面所写的章节中了。如果大家想了解更详细的内容，可以直

记一次公司.NET项目部署在Linux环境压测时内存暴涨分析一：背景二：WinDbg 分析卦中的内存段分类用处不大，也没有多大的参考价值，那怎么办呢？其实 coreclr 团队也考虑到了这个情况，它提供了一个 maddress 命令来实现跨平台的 !address，更改后输出如下：

Advanced .Net Debugging 10：事后调试一、介绍　　　　这是我的《Advanced .Net Debugging》这个系列的第十篇文章。这篇文章的内容是原书的第三部分的【高级主题】的第八章【事后调试】。前面几篇文章，我们介绍了很多工具，可以帮助大家找出问题的所在。但是，有一类问题我们是没办法使用这些工具来解决的，那就是已经发布的程序。在程序发布后，总是会出现一些问题，并且这些问题出现的时机是不确定的，大多数出现在用户在使用软件的过程中。想要解决这样的问题，我们当然会想到远程调试，有时候可以，有时候是不可以的，当然，不可以的理由会有很多，比如：

通过windbg查看dump文件中静态变量的值可以使用 WinDbg 和 SOS 扩展来查看它们。下面是如何使用 WinDbg 和 SOS 的步骤：

堆溢出bug定位调试修复最近代码出了bug，堆溢出。 debug下一切正常， release时随机崩溃到某几个地方，报错是: Critical error detected c0000374

windbg托管内存泄漏排查1、!address -summary 查看内存占用主要查看以下两项Heap：NT 堆（同 !heap -s)，Size过大，可能有非托管内存泄露

Advanced .Net Debugging 6：程序集加载器EntityUtil 类的代码Program 类的代码在 GAC 中的程序集必须是强命名的，并且拥有唯一的版本号。在共享程序集加载的过程中（在默认的加载上下文中），CLR 加载器会首先检查 GAC 来确定这个程序集是否存在，然后再查看私有的加载路径。　　　　　　　　　　　　我们可以使用【Windbg Preview】工具，使用【lm f】命令查看目标进程中所有已加载的模块以及它们相应的加载路径。这个很简单，直接贴结果。这个里面，我使用【lm】和【lm f】两个命令，大家可以自己体会区别。