Coding is hard, you can make it easy!

前言

这是 N 年前遇到的一个问题了。最近跟 DEBUG 宏对着干上了，正好翻到这篇总结 —— 记录了使用 pragma message 排查 同一个工程不同 CPP 中 DEBUG 宏的值不同的过程。现对之前的总结做了更新整理，分享给各位小伙伴儿。

缘起

在上一篇文章 《调试实战 | dll 加载失败之Debug Release争锋篇》中，由于两个工程中的 _ITERATOR_DEBUG_LEVEL 不同，导致了对同一个 map 的解析不同，从而导致了崩溃。在示例代码中，我是手动更改的该宏的值，在实际工程中，却另有玄机。在上文中故意省略了这部分内容的介绍。现把实际工程的问题在本文中做个相对详细的梳理总结。

先剧透一下：实际工程中的问题是因为一个工程中定义了 _DEBUG 宏，另外一个工程里没定义。但是我已经核对过，两个工程都没定义 _DEBUG 宏。其中一个工程的 _DEBUG 宏是从哪儿来的呢？

缘起

最近，项目里遇到一个 dll 加载不上的问题。实际项目比较复杂，但是解决后，又是这么的简单，合情合理。本文是我使用示例工程模拟的，实际项目中另有玄机，但问题的本质是一样的。本文从行文上与 《调试实战 | dll 加载失败之全局变量初始化篇》 非常相似，示例代码也非常相似（原谅我比较懒），感兴趣的小伙伴儿可以对比来读。

缘起

我在上一篇文章——《调试实战 | dll 加载失败之全局变量初始化篇》中，跟大家分享了一个由于全局变量初始化顺序导致的 dll 加载失败的例子。感兴趣的小伙伴儿可以点击阅读。

虽然我们知道了是由于全局变量初始化顺序导致的问题，也给出了解决方案。但是有一点却没有刨根问底——为什么改变文件在工程文件中的顺序就可以改变全局变量初始化顺序？是怎么影响的呢？本篇文章力求解决这个问题。

前言

最近项目里总是遇到 dll 加载不上的问题，原因各种各样。今天先总结一个虽然不是项目中实际遇到的问题，但是却非常经典的问题。其它几种问题，后续慢慢总结。

示例代码包含一个 exe 工程，两个 dll 工程。 exe 会加载两个 dll 并调用它们的导出函数（GetCallCount），结果只有一个 dll 的导出函数被成功调用。会是什么原因呢？

前言

相信，很多小伙伴儿都在命令提示符中执行过 ipconfig 查看 ip 信息。我们还可以执行 ping ip 来 ping 对应的 ip 地址，执行 notepad 启动记事本，执行 explorer 启动文件管理器……

但是，你好奇过背后的运作机制吗？为什么输入几个简单的几个字母就能启动外部程序，本文试图通过一系列实验来挖掘其背后的运作机制。

如果你对下面的问题有很明确的答案，本文不是为你准备的。如果有模糊，拿不准的地方，请耐心读完。如果觉得有用，请帮忙点个在看，拜谢。

缘起

前一段时间，有网友遇到一个奇怪的问题，说他机器上的 vs2019 编译 C++ 工程报错。我当时一听就有两个怀疑：

1. 工程设置不对。
2. vs2019 没装好。

因为新建一个最简单的工程，编译也报一样的错误，所以可以排除工程设置的问题了。那只有可能是 vs2019 的问题了。但是具体是哪里的问题呢？

前言

在上一篇文章中，我们主要使用了三个命令 !address，s，.writemem 把丢失的代码成功的保存到了文件中。本文简单介绍一下上文用到的这三个命令。

前言

前一阵子，使用小乌龟（TortoiseGit）提交代码的时候，错误的 Revert 了部分代码，本文记录了找回这部分代码的过程。文章标题致敬张银奎老师《格蠹汇编》的第一章 —— 从堆里抢救丢失的博客。

说明： 本文的截图都是我用新建的示例工程截取的。

前言

本来只想发布一篇使用 livekd 抓取系统转储文件的总结，没想到一下子扩展出了这么多篇。转储系列文章终于告一段落了。今天对转储系列文章做个总结。

说明：本文很早就发布在我的博客上了，当时总结的有些问题，本次重新整理完善后再次发布。

前言

有时候我们非常想知道当前系统内核的一些状态，比如查看当前系统加载了哪些驱动，查看某个进程外 COM 调用卡在哪里了，等等。如果我们可以调试系统内核，或者抓取一个系统转储来做事后调试，该多好啊。我们可以通过如下方法得到系统转储：

2. 双机内核调试（需要另外一台机器来做双机调试）
3. 让系统崩溃（可以使用 sysinternals中的 notmyfault 或者 使用快捷键让系统崩溃，并设置 系统崩溃的时候自动保存转储文件）（有点小题大作了:joy:）。
4. 使用 sysinternals 中的 livekd，不需要特殊设置，绿色环保。

以上几种方案中，使用 livekd 最方便快捷。如果有哪位小伙伴儿对其它几种方法感兴趣，可以查看之前的转储系列文章。为了能顺利使用 livekd，我们需要解决几个问题。

缘起

最近，项目里出现了一个奇怪的编译错误。乍看错误提示，真有丈二的和尚，摸不着头脑的感觉。解决之后，又是这么的合情合理。具体是什么样的问题呢？一起来看看吧。

前言

相信，绝大多数小伙伴儿编译 C++ 或者其它语言的程序都遇到过编译错误。今天简单总结一下如何使用错误列表（Error List）和输出窗口（Output）排查编译 C++ 代码产生的编译错误。简单的错误，通过错误列表就可以搞定，但是一些复杂的错误，只通过错误列表很可能是无法解决的，需要借助输出窗口的帮助。

我在前面的文章——《使用 VMware + win10 + VirtualKD + windbg 从零搭建双机内核调试环境》分享了使用 windbg 进行双机内核调试的环境搭建的步骤。

有小伙伴儿留言说：在使用 vs 进行双机内核调试的时候，总是连不上。希望能发一篇使用vs进行双机内核调试的文章。今天，以视频形式分享下搭建过程。几本上是从零开始。

缘起

今天，被某些开机自动运行的程序“惹毛”了。打算使用 Autoruns 查看这个进程为什么会开机启动。没想到打开 Autoruns 后，只能在任务栏看到图标，怎么点都点出不来。Autoruns 已经启动了，不然任务栏不会看到图标，到底是什么原因导致的呢？继续阅读前，请回忆下是否遇到过类似的情况，有什么思路吗？

前言

当我们没有两台物理机时，又想做双机内核调试怎么办？当然是装虚拟机啦！本文总结了使用 VMware15.5 + win10 + virtualkd + windbg 搭建双机内核调试环境。

标题中的 101 请参阅 wikipedia 101。

前言

我们在上一篇文章——本地内核调试环境搭建，就这么简单！中总结了本地内核调试的开启方法。本地内核调试有很多限制（比如，不能执行 .crash 来让系统蓝屏，不能执行 .dump 保存转储，不能下断点 ……），双机内核调试完全没有这方面的限制，可以说是真正意义上的内核调试。

双机内核调试主要分两种情况：

1. 被调试系统运行在虚拟机中。
2. 被调试系统运行在另外一台真实的物理机中。

不论被调试系统运行在虚拟机中，还是运行在另外一台物理机中，系统设置都是一样的。本文简单梳理了常用的内核调试设置方法及连接方法。

前言

内核调试默认是关闭的，需要手动开启。本文将简单介绍如何在 Vista 及后续版本的系统中开启本地内核调试，并简要介绍使用 windbg 连接内核的方法。在 xp 系统中，对应的设置保存在 boot.ini 中，感兴趣的小伙伴儿请自行搜索设置方法。

前言

在 蓝屏（BSOD）转储设置，看本文就够了！ 这篇文章里比较详细的介绍了蓝屏转储设置。做好设置后，我们就可以在需要的时候使系统蓝屏了。这样我们就可以拿到一份系统转储，供我们分析问题了。本文介绍几种可以使系统蓝屏的办法。当然肯定还有其它办法，如果哪位小伙伴儿知道比较实用的方法，欢迎留言分享。

前言

我们在 内核转储，开抓啦！ 这篇文章里介绍了一个关键的系统设置。设置好后可以让系统在蓝屏（Blue Screen of Death，简称 BSOD）的时候自动保存转储文件。那篇文章只是简单的介绍了设置步骤，本文力求详细的介绍相关内容。