Coding is hard, you can make it easy!

缘起

在上一篇文章 《调试实战 | 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，我们需要解决几个问题。