安徽网站建设推荐,怎样用wordpress,有内涵的公司名字,asp网站后台失效目录
1、引发C软件异常的常见原因有哪些#xff1f;
2、排查C软件异常的常用方法有哪些#xff1f;
3、为什么要熟悉常见的异常内存地址#xff1f;
4、调试时遇到调用IsBadReadPtr或者IsBadWritePtr引发的异常#xff0c;该如何处理#xff1f;
5、如何排查GDI对象泄…目录
1、引发C软件异常的常见原因有哪些
2、排查C软件异常的常用方法有哪些
3、为什么要熟悉常见的异常内存地址
4、调试时遇到调用IsBadReadPtr或者IsBadWritePtr引发的异常该如何处理
5、如何排查GDI对象泄露问题
6、如何排查内存泄露问题
7、如何排查死循环高CPU占用问题
8、如何排查数据格式化时的崩溃问题
9、如何排查堆内存被破坏问题
10、如何排查线程堵塞或卡死问题
11、如何排查程序中的资源泄露问题
12、如何排查第三方库注入引发的异常问题
13、如何排查库与库之间不匹配问题
14、如何排查程序启动异常启动报错、崩溃、卡死问题
15、使用Windbg分析软件异常有哪些方式
16、为什么有的异常捕获不到
17、常用的开源异常捕获库有哪些
18、异常捕获库捕获不到异常时该怎么办
19、生成dump文件的方式有哪些
20、为什么要加载pdb文件为什么要加载系统库的pdb文件 C软件异常排查从入门到精通系列教程专栏文章列表欢迎订阅持续更新...https://blog.csdn.net/chenlycly/article/details/125529931C/C基础与进阶专栏文章持续更新中...https://blog.csdn.net/chenlycly/category_11931267.htmlVC常用功能开发汇总专栏文章列表欢迎订阅持续更新...https://blog.csdn.net/chenlycly/article/details/124272585C软件分析工具从入门到精通案例集锦专栏文章持续更新中...https://blog.csdn.net/chenlycly/article/details/131405795开源组件及数据库技术专栏文章持续更新中...https://blog.csdn.net/chenlycly/category_12458859.html网络编程与网络问题分享专栏文章持续更新中...https://blog.csdn.net/chenlycly/category_2276111.html 最近在C软件调试交流群中很多人问了开发维护过程中遇到的多个调试问题这两天正好有时间对这些常见的问题进行一个梳理和解答。本文以问答的方式进行展开罗列了C软件日常开发和维护中遇到的多个软件调试问题及有代表性的场景给出详细的处置思路和处理办法以供大家借鉴和参考希望大家在了解这些内容以后能从容地应对开发维护过程中遇到的各种问题。 考察一个开发人员的水平一是要看其编码与设计能力而是要看其软件调试能力排查软件异常 为什么要学习C软件调试技术学习调试技术有哪些好处可以参看我之前的写的文章 为什么要学习C软件调试技术掌握调试技术都有哪些好处https://blog.csdn.net/chenlycly/article/details/130856385学习C软件调试技术的学习路线路线可以参见我的文章 C软件调试与异常排查技术从入门到精通学习路线分享https://blog.csdn.net/chenlycly/article/details/135048954 1、引发C软件异常的常见原因有哪些 引发C软件异常的常见原因有访问空指针与野指针、内存越界栈内存越界、堆内存越界和全局内存越界、内存访问违例、线程栈溢出、堆内存被破坏、内存泄露、死循环、多线程死锁、待格式化参数与格式化符号不匹配、库与库之间的不匹配等。 我之前根据多年的C软件异常排查实践对这些引发C软件异常的常见原因进行了详细总结可查看文章
引发C软件异常的常见原因分析与总结实战经验分享https://blog.csdn.net/chenlycly/article/details/124996473了解这些常见原因之后我们在排查问题时可能会快速找到可疑点和排查方向能有限地提高我们排查问题的效率
2、排查C软件异常的常用方法有哪些 了解引发C软件异常的常见原因之后我们还要掌握排查C软件异常的常用手段与方法。 排查问题的常用方法有使用常用工具去辅助分析比如程序启动失败、启动报错、库加载失败、死循环与高CPU占用问题等、使用IDE开发工具调试Debug调试、Release调试和附加到进程调试、添加打印日志、分块注释代码、数据断点监测内存、历史版本比对法、Windbg分析静态分析dump文件、动态调试目标进程、使用反汇编工具IDA查看汇编代码辅助分析等。 我之前根据多年的C软件异常排查实践对这些排查手段和方法进行了详细的总结可查看文章
排查C软件异常的常见思路与方法实战经验总结https://blog.csdn.net/chenlycly/article/details/120629327掌握这些排查软件异常的常用手段与方法之后在遇到新的问题时我们的排查思路会更开阔、更高效必要时需要将多种排查方法结合起来使用。 在这里给大家重点推荐一下我的几个热门畅销专栏
专栏1该专栏订阅量已达到420多个有很强的实战参考价值广受好评专栏文章持续更新中预计更新到200篇以上
C软件调试与异常排查从入门到精通系列文章汇总https://blog.csdn.net/chenlycly/article/details/125529931 本专栏根据近几年C软件异常排查的项目实践系统地总结了引发C软件异常的常见原因以及排查C软件异常的常用思路与方法详细讲述了C软件的调试方法与手段以图文并茂的方式给出具体的实战问题分析实例带领大家逐步掌握C软件调试与异常排查的相关技术适合基础进阶和想做技术提升的相关C开发人员 专栏中的文章均是通过项目实战总结出来的通过项目实战积累了大量的异常排查素材和案例有很强的实战参考价值专栏文章还在持续更新中预计文章篇数能更新到200篇以上 专栏2
C/C基础与进阶专栏文章持续更新中...https://blog.csdn.net/chenlycly/category_11931267.html 以多年的开发实战为基础总结并讲解一些的C/C基础与进阶内容以图文并茂的方式对相关知识点进行详细地展开与阐述专栏涉及了C/C领域的多个方面的内容同时给出C/C及网络方面的常见笔试面试题并详细讲述Visual Studio常用调试手段与技巧 专栏3
开源组件及数据库技术https://blog.csdn.net/chenlycly/category_12458859.html 以多年的开发实战为基础分享一些开源组件及数据库技术 3、为什么要熟悉常见的异常内存地址 一般我们只需要了解0xcccccccc、0xcdcdcdcd、0xfeeefeee和0xdddddddd这4个内存地址异常值 当我们调试代码时遇到这些内存地址异常值后可以大概知道是什么原因引起的以这个为线索就可以迅速地分析并定位问题。 对于0xcccccccc和0xcdcdcdcd在 debug 模式下Visual Studio会把未初始化的栈内存全部填充成0xcccccccc当成字符串看就是“烫烫烫烫……”Visual Studio会把未初始化的堆内存全部填充成 0xcdcdcdcd当成字符串看就是 “屯屯屯屯……”。这两类特殊的字符串很多人应该都见到过。所以在debug调试时遇到有变量的值为0xcccccccc 或0xcdcdcdcd一般是变量没有初始化引起的。 对于0xfeeefeee是Debug下用来标记堆上已经释放掉的内存即已经释放的堆内存中会被填充成0xfeeefeee。注意如果指针指向的内存被释放了指针变量本身的地址是没做改变的还是其之前指向的内存的地址只是其指向的堆内存中被填充成0xfeeefeee。 对于0xdddddddd是Debug下用来标记堆上已经释放掉的内存即已经释放的堆内存会被填充成0xdddddddd。0xfeeefeee也是Debug下用来填充已经释放的堆内存但0xdddddddd和0xfeeefeee的使用场景应该是有区别的具体区别我也不太清楚。 之前在项目问题中看到的基本都是0xfeeefeee没见到过0xdddddddd但前段时间在Debug下调试代码时遇到了代码中访问了已经释放的内存内存中都被置为0xdddddddd这还是第一次遇到0xdddddddd异常值正是通过0xdddddddd的说明得知这个0xdddddddd是用来填充已经释放的堆内存以这个为线索快速地定位了问题 关于上述异常地址的详细说明可以参见文章
C 中常见异常内存地址的说明0xcccccccc、0xcdcdcdcd、0xfeeefeee 和 0xdddddddd 等https://blog.csdn.net/chenlycly/article/details/128285918
4、调试时遇到调用IsBadReadPtr或者IsBadWritePtr引发的异常该如何处理 IsBadReadPtr和IsBadWritePtr最开始是为了判断内存地址是否是可读可写的但这两个API函数已经被官方废弃了已经不再具有最开始那种判断作用了强烈建议大家不要再使用这两个API函数 一些老的代码中可能还会调用IsBadReadPtr和IsBadWritePtr比如我们项目中调用了一个第三方的dll库这个库是好几年前的版本。我是怎么知道第三方库中调用了IsBadReadPtr和IsBadWritePtr函数的呢看了我接下来说的内容就知道了 当代码执行到IsBadReadPtr和IsBadWritePtr函数调用的地方会产生一个异常如果当前正在调试代码则会让调试器中断下来。比如我们在用Visual Studio调试代码或者正在使用Windbg动态调试程序会让调试器Visual Studio或Windbg中断下来。 程序产生异常如果在调试状态下都会让调试器中断下来怎么知道是调用IsBadReadPtr和IsBadWritePtr的呢其实很简单调试器中断下来后直接查看此时的函数调用堆栈就知道了堆栈中能看到这两个函数的调用。 当我们使用Visual Studio或者Windbg调试时代码执行到IsBadReadPtr和IsBadWritePtr调用处会抛出一个异常调试器中断下来没有经验的人以为程序产生崩溃了其实不然这个异常是非致命性的可以跳过去程序还可以继续运行。 异常根据严重程度可分为致命性异常和非致命性异常。致命性异常是不可恢复的会导致程序发生崩溃闪退。非致命性的异常则是可以跳过去的程序可以继续运行不会导致程序的崩溃和闪退。 如果在用Visual Studio调试代码遇到这个异常中断按下F5可以将异常中断跳过去。如果是在用Windbg调试目标进程则输入命令g就可以将异常中断跳过去。注意如果代码中多次调用了IsBadReadPtr和IsBadWritePtr则需要多次跳过去。 之前我写过关于IsBadReadPtr和IsBadWritePtr相关案例的文章需要的话可以去查看
使用Windbg排查C程序调用IsBadReadPtr或IsBadWritePtr引发内存访问违例问题https://blog.csdn.net/chenlycly/article/details/129892952
5、如何排查GDI对象泄露问题 所谓的GDI对象泄露就是GDI对象使用完成后没有释放导致泄露。在Windows系统中一个进程的GDI对象总数为1万个当进程的GDI对象总数接近或达到这个上限则会导致GDI绘图失败甚至引发程序崩溃。 GDI对象泄露在UI程序编程中经常遇到如果存在GDI对象泄露在Windows任务管理器中可以看到GDI对象总数在持续的上涨。但任务管理器中看不到具体是哪一种GDI对象在不断增长。可以使用GDIView工具可以看到给类GDI对象的数目这样就能看到具体是哪个对象在增长这样结合代码的修改记录就能很快定位泄露的地方了。 之前写过使用GDIView排查GDI对象泄露的分析实例可以去查看文章
使用GDIView工具排查GDI对象泄漏导致程序UI界面绘制异常的问题https://blog.csdn.net/chenlycly/article/details/128625868
6、如何排查内存泄露问题 所谓的内存泄露就是动态申请的内存在使用完后没有去释放导致泄露。内存泄露在C程序中比较常见。 对于大型项目代码量比较大业务复杂内存泄露排查起来会比较费劲有多个工具和方法去排查比如可以使用Windbg中的umdh. exe工具、使用Windbg中的堆内存信息查看命令、使用Visual Leak Detector工具、甚至使用Visual Studio 2019开始集成的google出品的专用内存分析工具AddressSanitizer。此外像BounderCheck这种老的工具若干年前就已经停止维护了已经不支持新版本的Visual Studio了也就没法使用了。 有时有的内存泄露问题很难排查用一个工具和方法分析不出来可以多尝试几个工具和方法直到分析出来为止 使用Visual Leak Detector简称VLD排查内存泄露的案例文章
使用Visual Leak Detector排查内存泄漏 https://blog.csdn.net/chenlycly/article/details/135472681%20%20%E2%80%8B 使用其他工具分析内存泄露的案例可以查看内存泄露专栏中的文章 C内存泄漏排查专题https://blog.csdn.net/chenlycly/category_12370029.html%20%20%E2%80%8B
7、如何排查死循环高CPU占用问题 代码中发生了死循环一直在执行循环体中的代码会有一个典型的现象进程的CPU占用会比较高。 为什么死循环会导致CPU占用高的问题呢其实很好理解因为代码一直在不停歇地执行循环体中代码一直在占用CPU时间片所以导致CPU占用高。其实是表现为进程中的某个线程占用的CPU高因为死循环的代码是执行在某个线程中的所以这个线程占用的CPU高。 这种死循环问题排查起来很简单先用Process Explorer查看哪个线程占用CPU高。然后将Windbg附加到进程上然后通过占用CPU高的那个线程的id在windbg中切换到该线程中输入kn命令查看该线程当前的函数调用堆栈然后对照着代码就能确定发生死循环的代码位置了。在Process Explorer中也可以查看函数调用堆栈但看的不准确并且有时要看相关变量的值去确定为什么发生死循环这些只能在Windbg中查看在Process Explorer中是查看不到的。 我之前写过使用Process Explorer和Windbg排查死循环的案例可以查看文章
使用Process Explorer/Process Hacker和Windbg高效排查软件高CPU占用问题https://blog.csdn.net/chenlycly/article/details/135822428
8、如何排查数据格式化时的崩溃问题 一般我们在打印日志时需要将相关变量的值格式化到字符串中然后将字符串打印出来。在格式化时时常会用到遇到异常崩溃问题。 一种最简单的场景是待格式化参数与对应的格式化符不匹配导致了异常。比如一个int类型的参数却使用了%s的格式化符比如
int i 1;
char szBuf[256] { 0 };
sprintf( szBuf, %s, i );
格式化函数内部会去解析出设置的格式化符然后到栈上传过来的对应位置的待格式化参数。格式化函数解析到%s到栈上拿到对应的参数然后把参数值与%s对应即把参数值当成字符串首地址来处理在此示例代码中把参数i的值1当成字符串首地址即到 0x00000001地址的内存中把字符串读出来去格式化而这个0x00000001地址值很小属于64KB的小地址内存区空指针地址内存区这个区域的内存是禁止访问的所以产生了内存违例引发崩溃。 这种场景下问题排查很简单只要看看格式化符与待格式化参数是否匹配即可发现问题。一般这类问题可能是写代码时手误讲格式化符号用错了。 还有一类场景隐藏的比较深本质上也是格式化符与待格式化参数类型不匹配的问题。比如一个int64的参数却使用了32位整型对应的%d导致格式化函数内部再从栈上取对应位置的数据传入被调用函数的参数是压到栈上传递过来的时取的数据长度有问题导致格式化符取数据错位问题可能会引发崩溃。这类问题一般很难一眼看出来之前我就帮同事排查过一个类似的问题详细分析排查过程可以见文章
UINT64整型数据在格式化时使用了不匹配的格式化符%d导致其他参数无法打印的问题排查https://blog.csdn.net/chenlycly/article/details/132549186
9、如何排查堆内存被破坏问题 堆内存被越界破坏是最难查的一类内存问题。当堆内存被破坏时程序会到处“乱崩溃”一会崩溃在这里一会崩溃在那里有时崩溃在new一个对象或一段内存地方有时崩溃在delete对象或内存地方。 为啥会出现胡乱崩溃的问题呢因为越界将堆内存头部或尾部区域给篡改了而系统管理堆内存就是通过头部和尾部的信息来管理的一旦被篡改导致堆内存管理出问题导致后续申请或释放堆内存产生异常。 堆内存被破坏排查起来比较困难Windows平台上没有专用的内存检测工具只能通过注释代码逐步缩小排查范围去查。而Linux平台上则有专用的内存检测工具Valgrind和AddressSanitizer。好在Visual Studio 2019 19.6以后的版本引入了google的AddressSanitizer大家后面遇到问题可以试用一下。因为我们项目组从上到下统一使用的是Visual Studio 2017所以不能使用。 以前项目中遇到一个内存越界篡改堆内存头信息导致delete去释放堆内存时产生了异常相关文章如下
C堆内存错误C运行时库检测到向堆内存头部写入了内容https://blog.csdn.net/chenlycly/article/details/121800292
10、如何排查线程堵塞或卡死问题 一般线程堵塞或卡死可能是两个原因导致的一个是多线程之间发生了死锁一个是线程中发生了死循环。一旦线程发生堵塞线程相关的业务没法顺利执行导致软件业务出现异常。 对于死循环问题的排查上面已经讲过了。对于多线程死锁如果是临界区死锁也可以在Windbg中查看发生死锁的临界区锁信息可以快速地定位。如果是非临界区锁排查起来比较麻烦可以将所有线程的函数调用堆栈都打印出来然后结合代码判断出哪个线程发生了死锁。一般添加打印日志也能辅助定位死锁发生的位置。 对于使用Windbg分析临界区死锁问题可以查看我以前写的文章
使用Windbg分析多线程临界区死锁问题分享https://blog.csdn.net/chenlycly/article/details/128532743
11、如何排查程序中的资源泄露问题 程序中的GDI对象泄露、内存泄露和句柄泄露都属于资源泄露。GDI对象泄露和内存泄露比较常见我上面已经详细的讲解了。对于句柄泄露我们在项目中遇到过代码中频繁创建线程任务很快执行完线程退出但没有关闭线程句柄导致后续创建线程失败业务出现异常。 对于资源泄露之前写了专题文章可以查看
深入探究 C 程序中的资源泄漏问题https://blog.csdn.net/chenlycly/article/details/133631728
12、如何排查第三方库注入引发的异常问题 有些第三方程序比如输入法和安全软件会有模块注入到我们的程序进程中可能会导致我们的程序出现异常。我们在项目中遇到过几次。 对于输入法注入输入法之所以能支持在所有程序中输入文字是因为他有专门的注入模块会注入到所有的进程中。到这种注入可能会引发异常比如会导致软件时不时的卡顿导致软件发生死锁我们在项目中遇到过。对于死锁我们在Windbg显示的发生死锁的那个线程的函数调用堆栈中看到了输入法的模块正因为输入法接口调用触发的 对于第三方安全软件注入第三方安全软件就是通过注入到进程中对进程进行监控的。如果注入模块发生内存泄露或者崩溃会直接影响到我们的软件进程因为它位于我们的进程空间中这个我们在项目中都遇到过相关文章可以查看
第三方模块远程注入到软件中引发软件异常的若干实战案例分享https://blog.csdn.net/chenlycly/article/details/134545223
13、如何排查库与库之间不匹配问题 库与库之间的不匹配一般是两个库的版本不一致。可以从头文件的角度去看底层发布库到我们的软件中比如只更新了API头文件但库没更新库文件再比如只更新了库文件却没有更新API头文件。API头文件中可能有相关结构体的定义比如新版本中修改了结构体成员删除或新增了成员库的版本不匹配也可能会出问题。 比如A库依赖B库A库中调用了B库的接口A库编译时用到B库的API头文件b. h。编译A库时因为调用 B库的接口所以要依赖B库的API头文件b. h。而B库本身编译时一会依赖其API头文件b. h。如果A库使用的B库与B库的头文件b. h版本不一致也可能会出问题编译可能没问题但运行时可能会出问题。 当软件出现崩溃时分析函数调用堆栈时也看不出问题这时可能是库与库不匹配导致的。根据函数调用堆栈中模块查看这些模块及头文件在svn上的发布记录假设库是底层模块开发组打不过来的并与模块的维护人员确认是否是库的版本问题。
14、如何排查程序启动异常启动报错、崩溃、卡死问题 程序启动时系统会先把exe程序依赖的所有dll库加载到程序的进程空间中最后才会进入exe主程序的main函数程序才能运行起来。 如果依赖的库在电脑系统中找不到则程序启动时会报缺少库的提示一般是因为程序打包生成安装包忘记把缺少的库打包进安装包导致的。把缺少的库打包进去即可。 如果程序调用的接口在对应的库找不到程序启动时会报在某个库找不到接口可能接口名称边了也可能是接口参数变了此时可以用Dependency Walker打开exe主程序文件看看具体是哪个模块调用了这个接口确认一下是主调模块有问题还是被调模块有问题。 如果是启动过程中发生崩溃可能是加载某个库时库的初始化代码有问题引发的程序发生崩溃闪退。这时没有机会将Windbg附加到进程上去分析因为程序已经崩溃闪退了。此时可以使用Windbg将程序启动起来一旦程序发生崩溃Windbg就会感知到就会中断下来就可以去分析了。 《C软件调试与异常排查从入门到精通》专栏中有专门的章节讲述程序启动异常排查的专题感兴趣的朋友可以去查看
C软件调试与异常排查从入门到精通系列文章汇总https://blog.csdn.net/chenlycly/article/details/125529931
15、使用Windbg分析软件异常有哪些方式 Windbg排查软件异常主要有两种方式即静态分析dump和动态调试目标进程。当我们有dump文件时则使用静态分析dump文件的方式。如果没有生成dump文件可能没捕获到异常或者从现有的dump文件中分析不出问题时可以将Windbg附加到目标进程上进行动态调试。 使用Windbg静态分析dump文件的一般步骤见文章
使用Windbg静态分析dump文件的一般步骤详解https://blog.csdn.net/chenlycly/article/details/135484682 使用Windbg动态调试目标进程的一般步骤见文章
使用Windbg动态调试目标进程的一般步骤详解https://blog.csdn.net/chenlycly/article/details/135484906
16、为什么有的异常捕获不到 应该是程序中只是简单使用API函数SetUnhandleExceptFilter设置异常回调函数去捕获异常但这种做法是与线程关联的需要每个线程都设置回调。只在上层模块中调用设置只作用所在的线程中的一般无法捕获其他线程中的异常。而进程中包含了多个模块多个线程所以其他线程中的异常捕获不到。所以会遇到很多时候捕获不到异常的问题。 只是简单地调用SetUnhandleExceptFilter设置异常回调去捕获异常是远远不够的一般我们使用开源的异常捕获库去捕获异常比如CrashRpt、BreadPad和CrashPad。
17、常用的开源异常捕获库有哪些 常见的开源捕获库CrashRpt、BreadPad和CrashPad。其中CrashRpt是Google早期开源的但通过项目实战发现该库有些时捕获不到发生的异常才看代码研究其实现机制发现她是通过将加载模块导入表中创建线程的CreateThread函数hook成自定义的函数在该函数中给当前线程设置异常回调函数去实现该线程的异常捕获。但只对在异常捕获模块之前加载的模块进行hook后加载到进程空间中的模块没有hook所以后加载模块如果发生异常是捕获不到的。 后来我们使用了微软开源的detours项目对CrashRpt进行改进有效地提高了捕获异常的几率。BreadPad是Google开源的Chrome浏览器中的异常捕获模块最新版本浏览器中已经改为CrashPad。CrashPad默认是支持Windows的如果用在linux中则需要使用Linux版本。
18、异常捕获库捕获不到异常时该怎么办 大家在实际项目中会发现即使使用了开源的异常捕获库或者经过升级改造的捕获库有少部分异常还是捕获不到的。 对于捕获不到的异常则只能将Windbg附加到目标进程上和目标进程一起跑一单进程发生异常会投递给正在附加调试的WindbgWindbg就会感知到异常并中断下来就可以直接在Windbg中分析了。如果一时半会看不出来可以使用. dump命令将异常上下文导出到dump文件中事后再去静态分析。 在正在调试的Windbg中使用命令导出的dump文件属于全dump文件文件大小接近进程的虚拟内存的大小。Windbg动态调试相对于静态分析可以多次go多次动态查看函数调用堆栈还可以添加断点进行断点调试。
19、生成dump文件的方式有哪些 生成dump文件的方式主要有三种。 最常用的方式是通过异常捕获库去自动生成即异常捕获库捕获到了软件中发生的异常自动调用系统API函数MiniDumpWriteDump将异常上下文信息保存到dump文件中。 也可以从Windows任务管理器中导出进程的dump文件。它用在什么场合下呢比如程序发生异常弹出保存提示框此时进程还在的可以导出dump文件。再比如程序发生死循环或死锁时进程还在的也可以从任务管理器中导出dump文件。 还可以从正在调试的Windbg中使用. dump命令导出dump文件。比如我们在使用Windbg动态调试目标进程时如果一时半会分析不出问题或者出问题的电脑别人还要用我们不能长时间占用别人的电脑去分析问题可以导出dump文件然后事后去分析dump文件即可。 关于生成dump文件方式的详细说明可以参见文章
dump文件类型与dump文件生成方法详解https://blog.csdn.net/chenlycly/article/details/127991002
20、为什么要加载pdb文件为什么要加载系统库的pdb文件 pdb文件中包含函数及变量的符号信息加载pdb后在函数调用堆栈中才能看到具体的函数名和代码行号。有时我们需要在Windbg中查看函数中相关变量的值变量的值可能是关键线索有pdb中的变量符号才能识别变量才能看到变量的值。 pdb文件分软件业务模块的pdb文件和Windows系统库pdb文件。业务模块的pdb需要加载有时为了搞清楚问题也要加载系统库pdb的加载后可以看到系统库中具体调用了哪些接口可能能找到更为直接的线索。加载pdb后可能能看到更多行的函数调用更便于分析问题。 对于Windows系统库的pdb文件不需要下载微软提供了一个在线pdb符号服务器只需要将这个在线地址设置给WindbgWindbg在需要时会自动去下载。 此外不仅仅Windbg会用到pdb文件有些分析工具也会用到。比如Process Explorer/Process Hacker、Process Monitor使用这些工具分析问题时有时需要看函数调用堆栈需要pdb中的函数符号。再比如使用反汇编工具IDA查看二进制文件的汇编代码也需要使用到二进制文件的pdb文件中的函数与变量符号。 关于pdb符号文件的详细说明可以参见文章
pdb符号文件详解https://blog.csdn.net/chenlycly/article/details/125508858
