VS2022实用调试技巧超详解

---

本文章以VS2022为例讲解调试功能，不同的编译器可能会有所差异，但殊途同归，对其他编译器的使用也有一定的借鉴价值。

1. 什么是 bug

bug本意是“昆虫”或“虫子”，现在一般是指在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题，简称程序漏洞。

“Bug”的创始人格蕾丝·赫柏(GraceMurrayHopper)，她是一位为美国海军工作的电脑专家,1947年9月9日，格蕾丝·赫柏对HarvardMarkl设置好17000个继电器进行编程后，技术人员正在进行整机运行时，它突然停止了工作。于是他们爬上去找原因，发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾，这显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。所以在报告中，赫柏用胶条贴上飞蛾，并把“bug”来表示“一个在电脑程序里的错误，“Bug”这个说法一直沿用到今天。
（来自网络）

历史上第一个“Bug”。

2. 什么是调试(debug)

当我们发现程序中存在的问题的时候，那下一步就是找到问题，并修复问题。

这个找问题的过程叫称为调试，英文叫debug(消灭bug)的意思。
调试一个程序，首先是承认出现了问题，然后通过各种手段去定位问题的位置，可能是逐过程的调试，也可能是隔离和屏蔽代码的方式，找到问题所的位置，然后确定错误产生的原因，再修复代码重新测试。

3. Debug和 Release

在VS上编写代码的时候，就能看到有 debug 和 release 两个选项，分别是什么意思呢？

Debug 通常称为调试版本，它包含调试信息，并且不作任何优化，便于程序员调试程序。
程序员在写代码的时候，需要经常性的调试代码，就将这里设置为 debug ，这样编译产生的是debug 版本的可执行程序，其中包含调试信息，是可以直接调试的。

Release 称为发布版本，它往往是进行了各种优化，使得程序在代码大小和运行速度上都是最优的，以便用户很好地使用。当程序员写完代码，测试再对程序进行测试，直到程序的质量符合交付给用户使用的标准，这个时候就会设置为 release ，编译产生的就是 release 版本的可执行程序，这个版本是用户使用的，无需包含调试信息等。

对比可以看到从同一段代码，编译生成的可执行文件的大小，release版本明显要小，而debug版本明显大。

4.VS调试快捷键

那程序员怎么调试代码呢?

4.1 环境准备

首先是环境的准备，需要一个支持调试的开发环境，我们一般使用VS，应该把VS上设置为Debug。

4.2 调试快捷键

调试最常使用的几个快捷键:

1. F9：创建断点和取消断点
   断点的作用是可以在程序的任意位置设置断点，打上断点就可以使得程序执行到想要的位置暂停执行，接下来我们就可以使用F10，F11这些快捷键，观察代码的执行细节。

断点也可以点击VS编辑取最左侧创建或取消。

条件断点：满足这个条件，才触发断点。

条件断点创建方法：

右键断点就可以创建条件断点，条件断点一般用于循环中，可以观察特定的某一次循环时代码的运行情况，节省时间。

2. F5：启动调试，经常用来直接跳到下一个断点处，一般和F9配合使用。
   F10：逐过程，通常用来处理一个过程，一个过程可以是一次函数调用，或者是一条语句。
   F11：逐语句，就是每次都执行一条语句，但是这个快捷键可以使我们的执行逻辑进入函数内部。在函数调用的地方，想进入函数观察细节，必须使用F11，如果使用F10，直接完成函数调用。
   （实际上F10和F11的区别只有是否能进入函数内部）
   CTRL+F5：开始执行不调试，如果你想让程序直接运行起来而不调试就可以直接使用。

5. 监视和内存观察

在调试的过程中我们，如果要观察代码执行过程中，上下文环境中的变量的值，有哪些方法呢?
这些观察的前提条件一定是开始调试后观察，比如：

#include <stdio.h>
int main()
{
	int arr[10] = { 0 };
	int num = 100;
	char c = 'w';
	int i = 0;
	for (i = 0; i < 10; i++)
		arr[i] = i;

	return 0;
}

5.1 监视

开始调试后，在菜单栏中【调试】->【窗口】->【监视】，打开任意一个监视窗口，输入想要观察的对象就行。
打开监视窗口：

（注意这里选择哪一个调试窗口都是一样的）

另外，如果你发现监视窗口中的文字特别小，可以按照这个步骤进行修改：

1. 【工具】->【选项】
   
2. 【环境】->【字体和颜色】->【显示其设置】->【监视窗口】->【调整大小】->【重启VS生效】
   
   在监视窗口中观察：
   
   提示：如果想要观察一个数组，如果此时数组名还可以指整个数组的话，可以直接输入数组名进行观察，如果不能（比如函数传参的数组或是动态开辟的数组），可以使用例如 arr,10 的形式来观察arr及它之后10个相同元素的值。
   另外，监视窗口还可以用来计算，例如 5 + 7 或是 i * j，十分灵活。
   此外，监视窗口可以显示数据的类型，不仅可以观察变量的，也可以观察函数的，例如：

int add(int a, int b)
{
	return a + b;
}

#include <stdio.h>
int main()
{
	int a = 10;
	int b = 12;
	int c = add(a, b);
	printf("%d ", c);

	return 0;
}

我们想知道 add 函数指针的类型（如果你不知道什么是函数指针，欢迎阅读我的C语言指针系列），就可以使用监视窗口直接观察：

5.2 内存

如果监视窗口看的不够仔细，也是可以观察变量在内存中的存储情况，调试起来后，在【调试】->【窗口】->【内存】打开内存窗口。
打开内存窗口：

在内存窗口中，观察数据：

在打开内存窗口后，在地址栏输入：arr，&num，&c，这类地址，就能观察到该地址处的数据。

除此之外，在调试的窗口中还有:自动窗口，局部变量，反汇编、寄存器等窗口，可以自行使用一下，这里只介绍最常用的两个。

6. 调试举例1

求 1!+2!+3!+4!+...10!的和，请看下面的代码：

//求出每个数的阶乘，再求和就好了
#include<stdio.h>
int main()
{
	int sum = 0;
	int ret = 1;
	for (int n = 1; n <= 10; n++)
	{
		for (int i = 1; i <= n; i++)
			ret *= i;
		sum += ret;
	}
	printf("%d\n", sum);
	return 0;
}

这个代码正确吗？我们运行一下看看结果：

就算你不知道正确答案是多少，也一定能一眼看出这个答案肯定是错的，那错在哪里了呢？干瞪眼很难找出bug所在，我们不妨调试起来看一看。

当n=2并结束循环时，sum中存储的是1!+2!，结果是3，截至目前还是正确的，所以我们要继续调试。

这里就开始有问题了，可以看到，此时是n=3也就是在求3!，i=2，所以现在ret中存储的就是2!，可以发现结果是错误的，所以说就是上一步出现了问题，我们重新开始调试，在这一步之前观察各个变量的值。

可能有些人会发现这个箭头指向了正在执行的语句，并且这个箭头可以拖动，但是请注意：拖动箭头只会改变下一步执行的语句，但代码的运行并不会执行或退回到箭头所指向的位置，所以，最好的办法是打一个（条件）断点，然后重新开始调试。
另外补充一点，箭头指向的语句是还没有执行的。

此时就是刚才我们发现ret的错误的上一步，也就是在求3!中即将求1!的这一步，可以看到，按照我们的预想，ret应该从1开始，但是现在竟然是2，问题出在哪里？

有了这个明确的方向，我们再来看代码，可以发现ret=1这一步是写在了循环的外面，这就导致了每次循环开始时，ret都是上一次阶乘求出的值，这也就是监视中ret=2的由来，那么就可以进行debug了：

#include<stdio.h>
int main()
{
	int sum = 0;
	int ret = 1;
	for (int n = 1; n <= 10; n++)
	{
		ret = 1;
		for (int i = 1; i <= n; i++)
			ret *= i;
		sum += ret;
	}
	printf("%d\n", sum);
	return 0;
}

这样修改之后，得到的答案就是正确的了：


这样就完成了一次完整的debug过程，当然，这个bug是在一个非常简单的代码中的一个简单的bug，所以可能你不需要经过这些步骤就能很快地定位到问题所在，但如果是一个很庞大的项目中出现的bug，标准的debug流程就显得十分重要了！

7. 调试举例2

在VS2022、X86、Debug 的环境下，编译器不做任何优化的话，下面代码执行的结果是什么？

#include <stdio.h>
int main()
{
	int i = 0;
	int arr[10] = { 1,2,3,4,5,6,7,8,9,10 };
	for (i = 0; i <= 12; i++)
	{
		arr[i] = 0;
		printf("hehe\n");
	}
	return 0;
}

很容易发现这个代码数组遍历越界了，正常情况下应该是程序崩溃，但结果真的如此吗？
我们运行起来看一看：

通过右边的很小的滑动条你应该就能发现：这个代码死循环了。
可是，为什么呢？

我们调试起来看一看：

调试到这一步，不知道你注意没有，此时i和arr[i]，也就是arr[12]的地址竟然是一样的，那死循环就很好理解了，arr[12] = 0，这一步将i也赋值为0，循环无法达到结束条件，也就无法停止了。

可是，为什么i会和arr[12]重合呢？

我们知道局部变量是存储在栈区的，

1. 栈区内存的使用习惯是从高地址向低地址使用的，所以变量i的地址是较大的。arr数组的地址整体小于i的地址。
2. 数组在内存中的存放是：随着下标的增长，地址是由低到高变化的。

如图：

所以根据代码，就能理解为什么是上图的代码布局了。
如果是上图的内存布局，那随着数组下标i的增长，往后越界就有可能覆盖到i，这样就可能造成死循环的。

这里你可能还有疑问：为什么i和arr数组之间恰好空出来2个整型的空间呢？

这里确实是巧合，在不同的编译器下可能中间的空出的空间大小是不一样的，代码中这些变量内存的分配和地址分配是编译器指定的，所以的不同的编译器之间就有差异了。所以这个题目是和环境相关的，如果换一个环境，可能代码就不会死循环而是报错了。

从这个理解我们能够体会到调试的重要性，只有调试才能观察到程序内部执行的细节，就像医生给病人做B超，CT一样。

注意:栈区的默认的使用习惯是先使用高地址，再使用低地址的空间，但是这个具体还是要编译器的实现，
比如：在VS上切换到X64，这个使用的顺序就是相反的，在Release版本的程序中，这个使用的顺序也是相反的。

调试过程中，要做到心中有数，也就是程序员自己心里要清晰的知道希望代码怎么执行，然后再去看代码有没有按照我们预定的路线在执行。
调试是需要反复去动手练习的，调试是可以增加程序员对代码的理解和掌控的，掌握了调试的能力，就能看到本质，就像能给程序做B超一样，对程序内部一览无余。

9. 编程常见错误归类

9. 1 编译型错误

编译型错误一般都是语法错误，这类错误一般看错误信息就能找到一些蛛丝马迹的，双击错误信息也能初步的跳转到代码错误的地方或者附近。编译错误随着语言的熟练掌握，会越来越少，也容易解决。

9.2 链接型错误

看错误提示信息，主要在代码中找到错误信息中的标识符，然后定位问题所在。一般是因为：

标识符名不存在
拼写错误
头文件没包含
引用的库不存在

9. 3 运行时错误

也就是逻辑错误。
运行时错误，是千变万化的，需要借助调试，逐步定位问题，调试解决的是运行时错误。

谢谢你的阅读，喜欢的话来个点赞收藏评论关注吧！
我会持续更新更多优质文章