当前位置: 代码网 > it编程>前端脚本>Python > Visual Studio调试C/C++指南

Visual Studio调试C/C++指南

2024年08月06日 Python 我要评论
前言Visual Studio(VS)是微软开发的一款集成开发环境(IDE)软件,支持C/C++、C#、VB、Python等开发语言,开发桌面、Web等应用程序。VS功能极其强大,使用极其便利,用户数量最多,被誉为"宇宙第一IDE"。熟悉地掌握基于VS的C/C++调试技术,可以大幅提升调试性能。随着VS版本的更新,其功能越来越强大,本文的内容是基于VS2019进行验证测试的,之前版本VS可能有少量特性不支持。基础。

1. 前言

visual studio(vs)是微软开发的一款集成开发环境(ide)软件,支持c/c++、c#、vb、python等开发语言,开发桌面、web等应用程序。vs功能极其强大,使用极其便利,用户数量最多,被誉为"宇宙第一ide"。

熟悉地掌握基于vs的c/c++调试技术,可以大幅提升调试性能。随着vs版本的更新,其功能越来越强大,本文的内容是基于vs2019进行验证测试的,之前版本vs可能有少量特性不支持。

2. 基础

 

2.1. 调试

代码调试主要指使用调试工具来检查和修复代码中的错误和问题。代码调试主要有运行调试、打印调试、内存分析、静态分析、性能分析等。

2.2. 符号文件

符号文件(symbol file)是指在编译程序时生成的包含调试信息的文件。它们通常与可执行文件或动态链接库(dll)配对存在,用于提供程序的调试信息。vc生成的符号文件为pdb(program database)文件。其中存储变量名、函数名、代码行号、类型信息和栈信息等。exe/dll与pdb文件是一一对应的。每次重新编译代码,都会生成新的pdb。

2.3. 调试器

microsoft visual c/c++的调试器名称叫做"visual studio debugger"。在调试exe时,其会读取exe文件中记录的pdb路径信息(这个路径是开发电脑编译时生成的pdb路径),如果这个pdb路径不存在,那么调试器会在exe目录去找pdb,如果依然找不到pdb,则启用无pdb调试。无pdb调试只能查看汇编信息和寄存器信息。

调试方式

3.1. 本地调试

vs工程默认即为本地调试(local windows debugger)。选定启动工程,按f5或通过菜单debug->start debugging。

  • 命令行参数(command arguments),给exe配置命令行参数。

  • 附加(attach),默认no。yes表示附加当前路径的进程进行调试。

3.2. 远程调试

  1. 将开发电脑上的remote debugger目录拷贝到生产电脑。

  1. 根据程序的类型x64/x86打开相应的目录,并打开生产电脑目录下的msvsmon.exe。

  2. 首次调用时,会弹出远程调试配置窗口,勾选所有的允许远程调试器与这些网络通信。

  3. 配置msvsmon.exe的tools->options。4015是默认的端口号,一般不建议修改。

  1. 获取生产电脑的ip,局域网网络通信,可以使用计算机名:端口号的方式,也可以使用ip:端口号的方法。但是在访问跨网关的局域网电脑时,计算机名可能无法解析出对应的ip地址,导致访问失败,所以更推荐ip:端口号的访问方式。

  2. 依据下图配置相关信息。

  3. 按f5启动调试,调试远程exe和调试本地exe后续操作完全一致。

3.3.  附加调试

  1. 打开exe。

  2. 从菜单启动debug->attach to process,选择需要调试的进程进行附加。如果是远程进程,配置下图信息。

3.4. 外网调试

远程调试一般是针对局域网进行调试。但是有些时候,问题进程在外地,出差不方便或成本太高,非常需要一种能够穿透广域网进行调试的方法。最简单的方法是使用vpn将目标电脑远程连接到开发电脑,这样目标电脑和开发电脑就相当于处在同一个局域网,就可以使用普通的远程调试来进行外网目标电脑调试。

3.5. dll调试

在dll工程的属性中debugging的command中选择要执行的exe,然后在dll中设置相关断点。再按f5调试,即会中断在dll工程的断点处。

4. 断点调试

int 3是x86-64架构cpu上的中断指令,用于在程序执行过程中触发软件中断。vs在给代码添加断点时,就是将指定行对应的代码修改为int 3指令,并且调试器接管代码。继续单步执行时,会还原int 3覆盖的代码。

4.1. 断点类型

4.1.1. 普通断点

在代码指定行按f9或右键菜单breakpoint->insert breakpoint设置普通断点。

4.1.2. 条件断点

在断点上右键选择conditions。

设置 i == 5, 然后点击close。按f5执行,代码会停止在断点处,此时i==5。

指定当前断点触发指定次数时中断下来。

当前断点运行在指定线程时才中断下来。

4.1.3. 行为断点

行为断点(actions breakpoint),也称tracepoint,因为断点触发时会在output窗口打印信息。continue code execution勾选表示不停止在断点处,如果选空表示停止在断点处。

output窗口显示:the value of z is 0x0000001e. 0x2c74

$pid,是伪指令。可用的伪指令如下:

4.1.4. 数据断点

数据断点(data breakpoint),当然变量地址的内容发生改变时,即中断下来。如下图,address编辑框可以直接填写变量的地址,也可以使用取地址符来获取变量的地址。数据断点只能针对有效数据设置断点,并且只能在已经开始调试之后,在breakpoint窗口的菜单new->data breakpoint来设置。

4.1.5. 系统函数断点

例如想在createfile函数中下断点。可以使用dhb.exe在相应的

dbh.exe -s:srv*c:\symbols*symbol information -d c:\windows\syswow64\kernel32.dll enum *createfile*

然后breakpoints->new->function breakpoint:

运行就会断在系统api函数处,通过调用栈查找到调用的函数。

4.1.6. 软件断点

除了通过vs来添加断点外,我们也可以在代码中主动添加软件断点__debugbreak()/debugbreak函数,或是断言assert(0)。

__debugbreak()/debugbreak是代码到此处立即中断,而断言则是根据参数逻辑值来决定是否中断。软件断点主要用来在代码潜在的异常出现时产生中断提示开发者。

4.2. 调试行为

4.2.1. 基本行为

工具栏或debug菜单或鼠标右键都有调试行为的选项。

  1. break all,中断当前所有正在执行的代码。当代码进入死循环时,点击break all,代码即会中断下来,此时遍历线程查看函数调用栈,即能发现死循环代码位置。

  2. stop debugging,停止当前调试。

  3. restart,重新开始调试。

  4. show next statement,光标跳到下一次要执行的代码处。

  5. step into,快捷键f11,进入当前语句所调用的函数内部,并停在函数的第一行。如果当前行没有函数调用,则直接运行至下一行。

  6. step over,快捷键f10,执行当前语句,但不进入函数内部。

  7. step out, 快捷键shift+f11,执行完当前函数,暂停在函数调用处。

  8. step backward,即退回到上一次代码暂停的位置,恢复上次调试的信息。step forward,前行到退回前的代码暂停的位置。这是基于栈快照进行的调试,vs会在几次中断时,保存对应栈信息,尤其是当我们想反复调试一个算法时,使用step backward会非常方便。

4.2.2. 高级行为

  1. run to cursor,运行到光标处中断,可以通过鼠标右键来执行,也可在光标处的代码行的图标上点击。

  1. force run to cursor,强制运行到光标处,会跳过中间设置的断点。

  2. 自定义,鼠标放在箭头上,可以将下一个可执行代码的位置拖动到任意位置。拖动需要依赖先前的代码,否则可能产生异常。

5. 调试窗口

5.1. output 

output debug窗口主要输出调试过程的信息,主要包括:

  • exception messages

  • step filtering messages

  • module load messages

  • module unload messages

  • process exit messages

  • thread exit messages

  • program qutput

其中program output是代码运行时输出的信息,主要通过trace函数或outputdebugstring函数来将信息输出到output窗口。如果是非调试状态下,outputdebugstring的输出信息则需要dbgview工具来接收并显示。

5.2. locals

locals窗口显示调试时当前执行代码所在函数所在的栈的局部变量的值和类型。

5.3. autos

autos窗口显示调试时当前执行代码所在函数所在的栈的上下文栈变量值和类型。

5.4. watch

watch窗口总共有4个,可以在菜单debug->windows->wartch中选择。watch窗口可以显示当前栈内存的局部变量,全局变量等,支持16进制形式显示,并支持实时修改变量值。

支持简单的表达式显示,如x+y, sizeof(x)等。

支持格式化显示,如(int*)(szbuff),4将buff转换为int*,再格式化为4个元素显示。

watch窗口还支持显示伪变量,如:

  • $tid – 当前线程的的线程 id

  • $pid – 进程 id

  • $cmdline – 附加进程的命令行字符串

  • $user – 运行在程序中的账户信息

  • $registername – 显示指定寄存器的寄存器内容

  • $err – 显示最近错误的错误码

  • $err, hr – 显示最近错误的消息

5.5. memory

memory窗口是用来显示地址对应的内容,memory窗口有4个从菜单debug->windows->memory中选择。

adress编辑框填写变量地址,columns选择每行显示的内容数量。

5.6. quickwatch

quickwatch窗口是快捷观察、修改变量的窗口。

5.7. disassembly

参数传递、函数返回等一些复杂的语法形式,要想理解其深层执行逻辑,就需要单步执行汇编代码来观察其隐藏逻辑细节。

5.8. registers

寄存器窗口,显示当线程的寄存器信息。

5.9. call stack

函数调用栈窗口,显示当前线程的函数栈调用情况。可以通过threads窗口选定当前线程。

5.10. immediate window

debug->windows->immediate窗口。立即窗口主要用来查看、修改变量,执行函数,表达式等。

6. 多线程

6.1. threads

threads是显示当前进程的所有运行的线程信息的窗口。双击线程所在行,即将当前代码窗口、调用栈窗口等相关窗口的内容更新为选定线程。

当进程有多个工作者线程时,且只想调试其中一个线程时,可以将不关心的线程使用freeze冰冻起来。冰冻的线程在按f5运行时,依然冰冻着不运行。使用thaw解冻线程,线程将恢复为正常可以调试的状态。

6.2. 条件断点

在多线程中,根据线程信息来设置相应的断点来观察期望的变量信息。

6.3. parallel watch

debug->window->parallel watch可以显示几个线程同时调用的函数变量的情况,更方便地调试多线程。

6.4. 线程结构图

打开debug->windows->parallel stack窗口,会显示所有线程的栈,并显示当前线程栈。相比threads窗口更直观。

7. 参数配置

7.1. 增量链接

增量链接在debug下默认打开,在release下默认关闭。通过linker->general->enable incremental linking来开启和关闭。增量链接还需要配置c/c++->general->debug information format->program database for edit and continue (/zi)。

增量链接的用处是在断点单步调试代码的时候,编辑代码,然后继续单步执行时,vs会自动增量链接,不用重新编译源代码,然后继续单步执行代码进行调试。

增量链接是调试时使用,增量编译则是编译时只编译修改的源文件,两者不相同。

7.2. 优化级别

debug版本下,默认关闭代码优化,此时代码的调试信息与代码源文件是一一对应,调试更方便。release版本下,默认使用o2优化,此时代码优化程度非常大,调试信息与代码源文件无法一一对应。如果想调试release版本,则需要关闭优化。

7.3 宏展开

一些复杂的宏,非常难以调试。如何查看宏预处理之后展开形成的代码呢?c/c++->preporcessor->preprocess to a file配置默认是关闭的,打开此配置为yes(/p)表示将生成预处理后的文件,文件与源文件同名,后缀为.i。在.i文件中可以查看所有宏展开的结果,以及其他预处理的结果。

7.4. 显示链接细节

vs 链接器默认只显示一些关键的链接信息。可以通过linker->general->show progress配置display all progress messages(/verbose)来显示详细的链接信息,可以更方便地分析一些链接异常的错误。

7.5. 警告

7.5.1. 编译警告

为了提升代码的可靠性,警告也需要认真对等。

  • c/c++->all options->warning level,选择合适的警告级别,初期可以选择w3级别。

  • c/c++->all options->treat warning as errors,初期可以不设置。

  • c/c++->all options->treat specific warnings as errors,可以将一些关键警告设置为错误。

7.5.2. 链接警告

linker->all options->treat linker warning as errors,根据需要将警告作为错误对待。

dump调试

8.1. 概念

dump文件(dump file),也叫转储文件,以.dmp为文件后缀。dump文件是进程在内存中的镜像文件,通过转换然后存储成以.dmp后缀的文件。dump文件根据存储时的选项不同,会生成不同大小的文件,其中记录信息也自然有所不同。

8.2. 转储文件生成

  1. 通过windows进程管理器,选择指定的进程,右键生成转储文件。

  2. 通过函数minidumpwritedump生成转储文件。

8.3. 调试转储文件

  • 选择与生成dump文件相同版本的vs。

  • 启动vs并打开dump文件。

  • 必须保证生成dump文件的程序的pdb文件和源代码相一致。

  • vs2005打开dump文件时,直接按f5调试,代码会停在出错的地方,通过call stack窗口查看。

  • vs2010打开dump文件时,

需要通过set symbol paths设置符号文件路径,也即pdb文件路径。然后点击debug with native only,代码即会中断在出错的地方,通过call stack窗口查看相关信息。

变量溢出

变量内存溢出分为上溢(overflow)和下溢(underflow)。内存溢出导致的异常是c++代码最为难以调试的bug之一,因为内存溢出导致的异常往往不会立即出现,而是展现在后面的函数中。因为内存溢出可能覆盖了后面的代码,导致后面的代码执行异常。

addresssanitizer (asan) 是一种编译器和运行时技术,它通过和编译器配合,通过插桩技术,向内存的前后添加标识,来识别运行时产生的上溢和下溢异常。其对代码执行性能影响较大,vs中默认是关闭的,需要手动打开。

asan可以识别栈内存、堆内存、静态内存的溢出,另外也能检测重复释放,释放后使用内存。

通过c/c++->general->enable address sanitizer使能,此配置与编辑并继续、增量链接和/rtc不兼容。

更多信息:addresssanitizer | microsoft learn

资源泄露

电脑上的内核资源是有限的,申请使用完了,就要释放,否则资源可能不够用,导致后续申请失败而运行异常。所以资源泄露也是比较严重的问题,需要解决。

10.1. 内存泄露

在调试运行进程时,退出调试后,可能会在vs的output窗口中显示如下信息:

这就是内存泄露的提示信息。上面的信息有时会指出内存泄露的位置,有的时候指出的位置却不准确。第三方工具 visual leak detector,可以用来检测内存泄露,其主要是通过重载内存申请和释放函数,然后记录内存申请的地址和详细源文件行号,最后退出时检测所有申请的地址是否释放,如果没有释放,则打印出内存申请的信息。

visual leak detector的使用非常简单,下载安装,然后在工程的启动接口文件中添加#include <vld.h>即可。

详细信息见:home · kinddragon/vld wiki · github

10.2. 句柄泄露

除了内存泄露外,句柄也是容易泄露的资源。

  • 可以使用windbg的句柄快照对比功能找出未正常释放的句柄。

  • 可以使用第三方工具deleaker,可以注册试用版本使用14天。deleaker会检测出代码申请未释放的行号。

11. 静态调试

相比于动态调试(在代码运行时调试),静态调试是在代码编译时来调试,其效率更高。

11.1. 静态断言

静态断言static_assert是c++11中引入的新语法,可以在编译时进行一些判断,并打印相应信息。

static_assert(sizeof(int) == 4, "int must be 4 bytes"); // 检查 int 类型是否为 4 字节

template <typename t>
void process(t value) {
    static_assert(std::is_integral<t>::value, "t must be an integral type"); // 检查模板类型是否为整数类型
}

11.2. 静态分析

vs自带的静态分析,功能非常强大,能够发现很多隐藏的问题。开启静态分析之后,会在编译期间进行静态分析代码,所以会加大编译时间。建议定期开启静态分析检查代码,并修复相关问题。

另外还可以选择相应的静态分析规则:

12. 性能调试

vs提供了性能度量工具(performance profiler),帮助开发者优化代码和提高应用程序性能。profiler的主要功能是诊断内存、cpu 使用率。debug下的性能分析,因为有很多调试及优化的影响,所以很不准确,建议是在release版本下进行性能调试分析。

通过debug->performance profiler。c/c++更多用来分析cpu和memory。

点击start之后,目标程序开始执行,并开始监控性能,并通过take snapshot给当前进程拍摄快照。

12.1. 内存分析

通过stop collection或等进程结束,会显示如下信息。每个快照会保存详细的进程堆栈信息。

点击上面的内存分配次数、分配次数增量等数据,可以获取详细信息:

双击相应对象分配行,可以得到详细的对象信息包括调用堆栈信息,通过调用栈可以查看相应的代码:

12.2. cpu分析

内存分类统计:

内存分线程统计:

双击函数名,可以详细函数占比分析:

12.3. 性能提示

调试器在断点或单步执行操作中停止执行时,中断与上一个断点之间经过的时间会显示为在编辑器窗口中的提示。

更多信息见:在 visual studio 中度量性能 - visual studio (windows) | microsoft learn

协同调试

vs提供了多人协作进行调试的功能,使用非常简单。

  1. 登录vs帐号。

  2. 点击如下图中红圈的图标,启用协作会话。

  1. 协作会话启动完成后,会显示如下信息。默认已经将协作邀请链接进行了拷贝。如果协作方只需要查看代码,不需要调试,可以点击make read-only。

  1. 将协作邀请链接发给协作方并打开,弹出如下窗口。

  1. 打开vs code,主持人开始调试,协作方也可以通过vs code查看调试信息。

  1. 通过vs的file->join live share session来加入协作调试。

  2. 还可以进行协作的管理,以及协作时聊天。

14. 调试技巧

14.1. 小技巧

  • 使用快捷键,另外还可以自定义快捷键。

  • 固定数据提示信息

  • 格式化内存

调试器也能在 watch 窗口中显示格式化的内存值,高达 64 个字节。你能用下面的说明符在表达式(变量或内存地址)后来格式化数据。

  • mb / m - byte

  • mw - word

  • md - dword

  • mq – 8byte

  • ma – 16byte

14.2. 管理员权限调试

通过linker->manifest file->uac execution level->requireadministrator,启用管理员权限,然后启用调试,则被调试的进程也将获取管理员权限。

14.3. 生成调用栈信息

void printstacktrace() 
{
    handle process = getcurrentprocess();
    syminitialize(process, nullptr, true);

    void* stack[100];
    word frames = capturestackbacktrace(0, 100, stack, nullptr);

    symbol_info* symbol = (symbol_info*)malloc(sizeof(symbol_info) + 256 * sizeof(char));
    symbol->maxnamelen = 255;
    symbol->sizeofstruct = sizeof(symbol_info);

    for (word i = 0; i < frames; ++i) {
        symfromaddr(process, (dword64)(stack[i]), 0, symbol);

        printf("[%d] %s\n", i, symbol->name);
    }

    free(symbol);
}

14.4. 内存耗尽

windows下的32位应用程序,只能申请2gb内存。所以在申请过的总内存过大时,可能超过2gb,导致程序异常。可以使用下面代码提示总内存过大的提示。

void nomorememory()
{
    lpvoid lpmsgbuf;
    if (!formatmessage( 
    format_message_allocate_buffer | format_message_from_system | format_message_ignore_inserts,
    null,
    0x00000008, // memory error	
     makelangid(lang_neutral, sublang_default), // default language
    (lptstr) &lpmsgbuf,
    0,
    null ))
    {
    return;
    }
    
    // display the string.
    messagebox( null, (lpctstr)lpmsgbuf, _t("error"), mb_ok | mb_iconinformation );
    abort();
}

// add to this function to the entry of exe/dll.
set_new_handler(nomorememory);

14.5. 未初始化异常

14.5.1. debug

vs在debug下为了方便用户调试,编译器会强制将未初始化的变量强制赋值指定值做标记。

栈变量强制赋值0xcccccccc,堆内存强制赋值为0xcdcdcdcd。

14.5.2. release

在vs下,c/c++中的变量编译器不会对变量进行初始化。栈变量和堆内存都是随机的。养成变量初始化的习惯是提升代码质量的好习惯。

14.6. 调试运行时库代码

vs运行时库,有一些提供了代码,有一些没有提供。如cstring的getlength()函数。vs2012及之前的版本默认不会进入库函数,vs2015及之后版本默认在使用step into时会进入库函数。如果无法进入库函数,可以进入汇编调试,然后再step into就可以进入库函数了。

14.7. debug和release的差异

  1. 编译优化:

    • debug 模式下,编译器不会进行任何优化,以便于调试和错误定位。

    • release 模式下,编译器会进行各种优化,以提高程序的性能和执行效率。

  2. 调试信息:

    • debug 模式下,编译器会生成完整的调试信息,包括变量名、行号等,方便进行调试。

    • release 模式下,编译器会尽量减少调试信息的生成,以减小程序的体积。

  3. 运行时检查:

    • debug 模式下,编译器会添加额外的运行时检查,如数组越界检查、内存泄漏检查等,以帮助发现程序中的错误。

    • release 模式下,这些运行时检查通常会被禁用,以提高程序的执行速度。

  4. 断言和异常处理:

    • debug 模式下,程序会更加严格地检查各种断言和异常,以帮助开发者发现问题。

    • release 模式下,这些检查通常会被禁用或简化,以提高程序的稳定性和性能。

  5. 编译器定义宏:

    • debug 模式下,编译器会定义 _debug 宏,用于在代码中进行条件编译。

    • release 模式下,编译器会定义 ndebug 宏,用于在代码中进行条件编译。

  6. 编译器优化标志:

    • debug 模式下,编译器通常会使用 /od 标志禁用优化。

    • release 模式下,编译器通常会使用 /o2 标志启用最高级别的优化。

  7. 链接器优化:

    • debug 模式下,链接器通常不会进行任何优化。

    • release 模式下,链接器会进行各种优化,如去除未使用的函数和数据等。

  8. 运行时库:

    • debug 模式下,程序会链接到 debug 版本的运行时库,提供更多的错误检查和调试支持。

    • release 模式下,程序会链接到 release 版本的运行时库,以提高性能和减小程序体积。

14.8. 构建事件

有时需要在编译前后附加一些操作来简单调试,就可以使用编译事件配置,选择相应的构建事件然后配置命令行来执行需要附加的操作。

14.9. 日志

日志是调试工具的重要手段,除了使用trace和outputdebugstring之外,还可以使用自定义的日志函数。

14.10. 调试窗口

vs自带的spy++可以用来查看窗口信息,还可以用来监控窗口消息。

14.11. 查看dll接口

dumpbin是vs自带的命令行工具,可以用来查看dll的接口函数。通过tools->command line来使用。

这是一个命令行工具,可以用于查看 dll 文件的结构和内容。常用命令:

  • dumpbin /exports <dll_file_path>: 查看 dll 的导出函数

  • dumpbin /dependents <dll_file_path>: 查看 dll 的依赖项

  • dumpbin /headers <dll_file_path>: 查看 dll 的头部信息

15. 总结

调试是手段,不是目的,不能为了调试而调试。目的是更高效地开发,为此,减少问题,减少调试才是最重要的。

(0)

相关文章:

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。

发表评论

验证码:
Copyright © 2017-2025  代码网 保留所有权利. 粤ICP备2024248653号
站长QQ:2386932994 | 联系邮箱:2386932994@qq.com