Coding is hard, you can make it easy!

如果你还不清楚什么是转储文件，不知道什么时候需要转储文件，请参考转储文件系列文章的第一篇 —— 转储文件知多少。

前言

前面几篇文章主要介绍了用户态转储文件（User-Mode Dump File）相关的内容。相信通过前面几篇文章的介绍，大家对用户态转储文件的抓取方法有了进一步的了解。接下来的几篇文章将介绍如何保存内核态转储文件（Kernel-Model Dump File）。

如果你还不清楚什么是转储文件，不知道什么时候需要转储文件，请参考转储文件系列文章的第一篇 —— 转储文件知多少。

前言

不知道各位小伙伴有没有遇到过 微信 或者 QQ 崩溃的情况。它们在崩溃的时候都会自动弹出一个对话框，提示用户上传相关文件，供开发人员分析问题的原因。有的小伙伴儿可能不太清楚我在说什么。没关系，下图就是微信崩溃后自动弹出的界面。

前言

在上一篇介绍 JIT Debugging 的文章 —— 你需要了解的JIT Debugging 中，我们了解到 procdump 设置为 JIT调试器的时候，在设置的参数中，有一个叫 %p 的参数（需要和 -j 一起使用），指向了 JIT_DEBUG_INFO。今天简单介绍一下 JIT_DEBUG_INFO。

如果你还不清楚什么是转储文件，不知道什么时候需要转储文件，请参考转储文件系列文章的第一篇 —— 转储文件知多少。

前言

细心的小伙伴可能注意到了，我在上一篇介绍抓取转储文件的工具的文章 —— 你需要知道的 N 种抓取 dump 的工具 中提到了：

如果用 64 位的 windbg 附加到 32 位目标进程后，直接执行.dump 命令生成的转储文件会 “有问题”。

经常抓 dump 的小伙伴很可能遇到过这个问题。具体是什么问题呢？我们一起看看吧。

如果你还不清楚什么是转储文件，不知道什么时候需要转储文件，请参考转储文件系列文章的第一篇 —— 转储文件知多少。

前言

我在 你需要知道的 N 种抓取 dump 的工具 这篇文章里，向大家介绍了几款可以抓取转储文件的工具及其简单用法。不知道大家是否还记得，以管理员权限运行 procdump -i 可以注册 procdump 为事后调试器。大家是否了解其实现原理？今天让我们一起揭开其神秘面纱。

前言

今天，向大家介绍几种可以抓取应用程序转储文件的工具及基本使用方法。更详细的用法，请参考每个工具对应的帮助文档。如果你还不清楚什么是转储文件，不知道什么时候需要转储文件，请参考转储文件系列文章的第一篇 —— 转储文件知多少。

9102 年即将结束，2020 年马上就要来到。借此机会，想跟大家说几件事儿。

前言

之前分享过几篇调试的文章，在那几篇文章里，我主要是在分析转储文件（也叫 dump 文件，或简称 dump），而不是实时调试。通常，程序发布后，我们很难有机会做实时调试。我们做的最多的是事后调试。能否抓到有效的转储文件对我们分析问题至关重要。

• 你知道什么是转储文件吗？

• 你知道什么时候应该抓取转储文件吗？

• 你抓取过转储文件吗？

• 你知道怎么抓取转储文件吗？

• 你知道几种抓取转储的方法呢？

如果你对以上问题感兴趣，那么请继续阅读吧。

前言

如果我们自己的程序的CPU Usage（CPU占用率）飙升，并且居高不下，很有可能陷入了死循环。你知道怎么快速定位并解决吗？今天跟大家分享几种定位方法，希望对你有所帮助。

简介

DebugView是sysinternals工具集中的一款用来查看调试信息的工具。不管你是内核开发人员还是应用程序开发人员，都会用到这款神器。先简单看看DebugView可以干什么吧。

• 可以查看应用程序输出的调试信息。
• 可以查看驱动程序输出的调试信息。
• 可以查看本地机器的调试信息。
• 可以查看远程机器的调试信息。
• 可以根据规则高亮显示。
• 可以根据关键字过滤。
• 可以根据关键字搜索。
• 可以自动显示最新一条记录。
• ……

功能太多太全了，有木有？！心动了吗？ 快跟我一起来了解下这个神器吧。

前言

第一次参加微软技术大会。之前对微软技术大会有太多遐想，今天终于亲身参与其中了。现在，终于有时间回顾下今天的 Ignite之旅了（全称是 Microsoft Ignite The Tour）。特记流水账一篇，以纪念我的第一次。

前言

不知道大家有没有留意过，我们在拖动窗体的时候，有时候显示的是虚框，有时候显示的是窗体内容。可能有的朋友不是太明白，没关系，一图胜千言。请看图：

前言

最近程序会不定期崩溃，很是头疼！今晚终于忍无可忍，下决心要干掉它！从之前的几个相关的dump可以猜到是有接口未释放导致的问题，但没有确认到底是哪个接口。本篇总结记录了找到这个接口的过程。

缘起

vs有一个功能 —— 在起始页会显示最近打开的工程列表，方便用户快速打开之前打开过的工程文件。但是打开的工程文件多了，想要找到自己需要的工程文件也不是那么容易的，要是能把之前打开的记录都清理干净该有多好啊。本文记录了我在查找vs2019相关设置存储位置的调查过程 。对于vs2017以前的版本，对应的设置是保存在注册表中的，从vs2017开始，不再保存在注册表，而是存储在本地配置文件中。到底存储在哪里了呢？我们一起来看看吧！

前言

这是几年前在项目中遇到的一个崩溃问题，崩溃在了ComFriendlyWaitMtaThreadProc()里，没有源码。耗费了我很大精力，最终通过反汇编并结合原代码才最终搞清楚了事情的来龙去脉。本文的分析还是基于真实项目进行的，中间略去了很多反汇编的分析工作。文末有我整理的测试代码，大家可以实际体验一把TerminateThread()的杀伤力。

缘起

最近，我们程序的某个功能在一台机器上不正常，但是在另外一台机器上却是正常的。代码是同一份，vs版本也一样（打的补丁也一样）。编译出来的程序在两台电脑上运行的结果就是不一样。惊不惊喜，意不意外？如果是你遇到了这种情况，你会怎么调查呢？:upside_down_face:

缘起

最近同事使用.tsep安装Tekla插件的时候，Tekla提示该插件已经存在了，需要卸载后再安装。同事找了半天，没找到怎么卸载，我也没找到。于是决定弄清楚Tekla是 如何判断一个插件安装与否的。 想必看过我其它排错文章的小伙伴已经猜到了，我们今天文章中的主角依然是process monitor。好了，话不多说，好戏马上开始。

缘起

最近想借助IDA逆向一个函数。在windows下，调试器（比如vs, windbg）可以通过调试符号（PDB）把地址与符号名对应起来，为我们提供更可读的信息。IDA应该也支持加载PDB，通过查看IDA安装目录下的idahelp.chm（打开后搜索PDB即可找到相关说明）发现还真支持。但是当我加载符号的时候，却失败了。本文记录了整个调查过程。

前言

最近我们的程序在退出时会卡住，调查发现是在卸载dll时死锁了。大概流程是这样的：我们的dll在加载的时候会创建一个工作线程，在卸载的时候，会设置退出标志并等待之前开启的工作线程结束。为了研究这个经典的死锁问题，写了一个模拟程序，用到的dump文件及示例代码参考附件。

前言

项目里的一个升级程序偶尔会死锁，查看dump后发现是死在了ShellExecuteExW里。经验少，不知道为什么，于是在高端调试论坛里发帖求助，链接如下http://advdbg.org/forums/6520/ShowPost.aspx

根据张银奎老师的描述可知，应该是拥有关键段的线程意外结束了。仔细检查项目中的代码，发现程序中有使用TerminateThread()来强制杀线程的代码。很可疑，于是写了一个测试程序，还原了这个问题。