|
您还未登录！|登录|注册|帮助
CSDN首页 资讯 论坛 博客 下载 搜索 更多CTO俱乐部
学生大本营
培训充电
移动开发
软件研发
云计算
程序员
TUP
bairny的专栏
条新通知 登录 注册 欢迎 退出 我的博客 配置 写文章 文章管理 博客首页 全站 当前博客 空间 博客 好友 相册 留言 用户操作
[留言] [发消息] [加为好友]
byID：bairny
共16105次访问，排名11515，好友0人，关注者1人。
by的文章
原创 10 篇
翻译 0 篇
转载 11 篇
评论 5 篇
订阅我的博客
[编辑]bairny的公告
[编辑]文章分类
PE文件格式
WTL
存档
2007年08月(4)
2007年07月(3)
2007年05月(11)
2007年03月(3)
公告： 第三届中国云计算大会 六折票价抢购中！ [意见反馈][官方博客] VC++ 6.0 中如何使用 CRT 调试功能来检测内存泄漏（转） 收藏
VC++ 6.0 中如何使用 CRT 调试功能来检测内存泄漏
作者：JerryZ
下载例子源代码
最近看了周星星 Blog 中的一篇文章：“VC++6.0中内存泄漏检测”，受益匪浅，便运行其例子代码想看看 Output 窗口中的输出结果，可惜怎么弄其输出都不是预期的东西，郁闷了半天，便到水坛里找到周星星，请求他指点一、二，然而未果。没有办法，最后我一头栽进 MSDN 库狂搜了一把，功夫不负有心人，我搜出很多有关这方面的资料，没过多久我便基本上就找到了答案......
首先，检测内存泄漏的基本工具是调试器和 CRT 调试堆函数。为了使用调试堆函数，必须在要检测内存泄漏和调试的程序中添加下面的语句：
#define _CRTDBG_MAP_ALLOC
#include<stdlib.h>
#include<crtdbg.h>
#include "debug_new.h" MSDN 如是说：“必须保证上面声明的顺序，如果改变了顺序，可能不能正常工作。”至于这是为什么，我们不得而知。MS 的老大们经常这样故弄玄虚。
针对非 MFC 程序，再加上周星星的头文件：debug_new.h，当然如果不加这一句，也能检测出内存泄漏，但是你无法确定在哪个源程序文件中发生泄漏。Output 输出只告诉你在 crtsdb.h 中的某个地方有内存泄漏。我测试时 REG_DEBUG_NEW 没有起作用。加不加这个宏都可以检测出发生内存分配泄漏的文件。
其次，一旦添加了上面的声明，你就可以通过在程序中加入下面的代码来报告内存泄漏信息了：
_CrtDumpMemoryLeaks(); 这就这么简单。我在周星星的例子代码中加入这些机关后，在 VC++ 调试会话（按 F5 调试运行） Output 窗口的 Debug 页便看到了预期的内存泄漏 dump。该 dump 形式如下：
Detected memory leaks!
Dumping objects ->
c:\Program Files\...\include\crtdbg.h(552) : {45} normal block at 0x00441BA0, 2 bytes long.
Data: <AB> 41 42
c:\Program Files\...\include\crtdbg.h(552) : {44} normal block at 0x00441BD0, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
c:\Program Files\...\include\crtdbg.h(552) : {43} normal block at 0x00441C20, 40 bytes long.
Data: < C > E8 01 43 00 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete. 更具体的细节请参考本文附带的源代码文件。
下面是我看过 MSDN 资料后，针对“如何使用 CRT 调试功能来检测内存泄漏？”的问题进行了一番编译和整理，希望对大家有用。如果你的英文很棒，那就不用往下看了，建议直接去读 MSDN 库中的技术原文。
C/C++ 编程语言的最强大功能之一便是其动态分配和释放内存，但是中国有句古话：“最大的长处也可能成为最大的弱点”，那么 C/C++ 应用程序正好印证了这句话。在 C/C++ 应用程序开发过程中，动态分配的内存处理不当是最常见的问题。其中，最难捉摸也最难检测的错误之一就是内存泄漏，即未能正确释放以前分配的内存的错误。偶尔发生的少量内存泄漏可能不会引起我们的注意，但泄漏大量内存的程序或泄漏日益增多的程序可能会表现出各种 各样的征兆：从性能不良（并且逐渐降低）到内存完全耗尽。更糟的是，泄漏的程序可能会用掉太多内存，导致另外一个程序垮掉，而使用户无从查找问题的真正根源。此外，即使无害的内存泄漏也可能殃及池鱼。
幸运的是，Visual Studio 调试器和 C 运行时 (CRT) 库为我们提供了检测和识别内存泄漏的有效方法。下面请和我一起分享收获——如何使用 CRT 调试功能来检测内存泄漏？
如何启用内存泄漏检测机制？
使用 _CrtSetDbgFlag
设置 CRT 报告模式
解释内存块类型
如何在内存分配序号处设置断点？
如何比较内存状态？
结论
如何启用内存泄漏检测机制？
VC++ IDE 的默认状态是没有启用内存泄漏检测机制的，也就是说即使某段代码有内存泄漏，调试会话的 Output 窗口的 Debug 页不会输出有关内存泄漏信息。你必须设定两个最基本的机关来启用内存泄漏检测机制。
一是使用调试堆函数：
#define _CRTDBG_MAP_ALLOC
#include<stdlib.h>
#include<crtdbg.h> 注意：#include 语句的顺序。如果更改此顺序，所使用的函数可能无法正确工作。
通过包含 crtdbg.h 头文件，可以将 malloc 和 free 函数映射到其“调试”版本 _malloc_dbg 和 _free_dbg，这些函数会跟踪内存分配和释放。此映射只在调试（Debug）版本（也就是要定义 _DEBUG）中有效。发行版本（Release）使用普通的 malloc 和 free 函数。
#define 语句将 CRT 堆函数的基础版本映射到对应的“调试”版本。该语句不是必须的，但如果没有该语句，那么有关内存泄漏的信息会不全。
二是在需要检测内存泄漏的地方添加下面这条语句来输出内存泄漏信息：
_CrtDumpMemoryLeaks(); 当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在 Output 窗口的 Debug 页中显示内存泄漏信息。比如：
Detected memory leaks!
Dumping objects ->
C:\Temp\memleak\memleak.cpp(15) : {45} normal block at 0x00441BA0, 2 bytes long.
Data: <AB> 41 42
c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {44} normal block at 0x00441BD0, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
c:\program files\microsoft visual studio\vc98\include\crtdbg.h(552) : {43} normal block at 0x00441C20, 40 bytes long.
Data: < C > 08 02 43 00 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏的输出是这样的：
Detected memory leaks!
Dumping objects ->
{45} normal block at 0x00441BA0, 2 bytes long.
Data: <AB> 41 42
{44} normal block at 0x00441BD0, 33 bytes long.
Data: < C > 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{43} normal block at 0x00441C20, 40 bytes long.
Data: < C > C0 01 43 00 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete. 根据这段输出信息，你无法知道在哪个源程序文件里发生了内存泄漏。下面我们来研究一下输出信息的格式。第一行和第二行没有什么可说的，从第三行开始：
xx}：花括弧内的数字是内存分配序号，本文例子中是 {45}，{44}，{43}；
block：内存块的类型，常用的有三种：normal（普通）、client（客户端）或 CRT（运行时）；本文例子中是：normal block；
用十六进制格式表示的内存位置，如：at 0x00441BA0 等；
以字节为单位表示的内存块的大小，如：32 bytes long；
前 16 字节的内容（也是用十六进制格式表示），如：Data: <AB> 41 42 等； 仔细观察不难发现，如果定义了 _CRTDBG_MAP_ALLOC ，那么在内存分配序号前面还会显示在其中分配泄漏内存的文件名，以及文件名后括号中的数字表示发生泄漏的代码行号，比如：
C:\Temp\memleak\memleak.cpp(15) 双击 Output 窗口中此文件名所在的输出行，便可跳到源程序文件分配该内存的代码行（也可以选中该行，然后按 F4，效果一样） ，这样一来我们就很容易定位内存泄漏是在哪里发生的了，因此，_CRTDBG_MAP_ALLOC 的作用显而易见。
使用 _CrtSetDbgFlag
如果程序只有一个出口，那么调用 _CrtDumpMemoryLeaks 的位置是很容易选择的。但是，如果程序可能会在多个地方退出该怎么办呢？在每一个可能的出口处调用 _CrtDumpMemoryLeaks 肯定是不可取的，那么这时可以在程序开始处包含下面的调用：
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); 这条语句无论程序在什么地方退出都会自动调用 _CrtDumpMemoryLeaks。注意：这里必须同时设置两个位域标志：_CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF。
设置 CRT 报告模式
默认情况下，_CrtDumpMemoryLeaks 将内存泄漏信息 dump 到 Output 窗口的 Debug 页， 如果你想将这个输出定向到别的地方，可以使用 _CrtSetReportMode 进行重置。如果你使用某个库，它可能将输出定向到另一位置。此时，只要使用以下语句将输出位置设回 Output 窗口即可：
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );有关使用 _CrtSetReportMode 的详细信息，请参考 MSDN 库关于 _CrtSetReportMode 的描述。
解释内存块类型
前面已经说过，内存泄漏报告中把每一块泄漏的内存分为 normal（普通块）、client（客户端块）和 CRT 块。事实上，需要留心和注意的也就是 normal 和 client，即普通块和客户端块。
normal block（普通块）：这是由你的程序分配的内存。
client block（客户块）：这是一种特殊类型的内存块，专门用于 MFC 程序中需要析构函数的对象。MFC new 操作符视具体情况既可以为所创建的对象建立普通块，也可以为之建立客户块。
CRT block（CRT 块）：是由 C RunTime Library 供自己使用而分配的内存块。由 CRT 库自己来管理这些内存的分配与释放，我们一般不会在内存泄漏报告中发现 CRT 内存泄漏，除非程序发生了严重的错误（例如 CRT 库崩溃）。
除了上述的类型外，还有下面这两种类型的内存块，它们不会出现在内存泄漏报告中：
free block（空闲块）：已经被释放(free)的内存块。
Ignore block（忽略块）：这是程序员显式声明过不要在内存泄漏报告中出现的内存块。
如何在内存分配序号处设置断点？
在内存泄漏报告中，的文件名和行号可告诉分配泄漏的内存的代码位置，但仅仅依赖这些信息来了解完整的泄漏原因是不够的。因为一个程序在运行时，一段分配内存的代码可能会被调用很多次，只要有一次调用后没有释放内存就会导致内存泄漏。为了确定是哪些内存没有被释放，不仅要知道泄漏的内存是在哪里分配的，还要知道泄漏产生的条件。这时内存分配序号就显得特别有用——这个序号就是文件名和行号之后的花括弧里的那个数字。
例如，在本文例子代码的输出信息中，“45”是内存分配序号，意思是泄漏的内存是你程序中分配的第四十五个内存块：
Detected memory leaks!
Dumping objects ->
C:\Temp\memleak\memleak.cpp(15) : {45} normal block at 0x00441BA0, 2 bytes long.
Data: <AB> 41 42
......
Object dump complete. CRT 库对程序运行期间分配的所有内存块进行计数，包括由 CRT 库自己分配的内存和其它库（如 MFC）分配的内存。因此，分配序号为 N 的对象即为程序中分配的第 N 个对象，但不一定是代码分配的第 N 个对象。（大多数情况下并非如此。）
这样的话，你便可以利用分配序号在分配内存的位置设置一个断点。方法是在程序起始附近设置一个位置断点。当程序在该点中断时，可以从 QuickWatch（快速监视）对话框或 Watch（监视）窗口设置一个内存分配断点：
例如，在 Watch 窗口中，在 Name 栏键入下面的表达式：
_crtBreakAlloc如果要使用 CRT 库的多线程 DLL 版本（/MD 选项），那么必须包含上下文操作符，像这样：
{,,msvcrtd.dll}_crtBreakAlloc 现在按下回车键，调试器将计算该值并把结果放入 Value 栏。如果没有在内存分配点设置任何断点，该值将为 –1。
用你想要在其位置中断的内存分配的分配序号替换 Value 栏中的值。例如输入 45。这样就会在分配序号为 45 的地方中断。
在所感兴趣的内存分配处设置断点后，可以继续调试。这时，运行程序时一定要小心，要保证内存块分配的顺序不会改变。当程序在指定的内存分配处中断时，可以查看 Call Stack（调用堆栈）窗口和其它调试器信息以确定分配内存时的情况。如果必要，可以从该点继续执行程序，以查看对象发生了什么情况，或许可以确定未正确释放对象的原因。
尽管通常在调试器中设置内存分配断点更方便，但如果愿意，也可在代码中设置这些断点。为了在代码中设置一个内存分配断点，可以增加这样一行（对于第四十五个内存分配）：
_crtBreakAlloc = 45;你还可以使用有相同效果的 _CrtSetBreakAlloc 函数：
_CrtSetBreakAlloc(45);如何比较内存状态？
定位内存泄漏的另一个方法就是在关键点获取应用程序内存状态的快照。CRT 库提供了一个结构类型 _CrtMemState。你可以用它来存储内存状态的快照：
_CrtMemState s1, s2, s3; 若要获取给定点的内存状态快照，可以向 _CrtMemCheckpoint 函数传递一个 _CrtMemState 结构。该函数用当前内存状态的快照填充此结构：
_CrtMemCheckpoint( &s1 ); 通过向 _CrtMemDumpStatistics 函数传递 _CrtMemState 结构，可以在任意地方 dump 该结构的内容：
_CrtMemDumpStatistics( &s1 );该函数输出如下格式的 dump 内存分配信息：
0 bytes in 0 Free Blocks.
75 bytes in 3 Normal Blocks.
5037 bytes in 41 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 5308 bytes.
Total allocations: 7559 bytes. 若要确定某段代码中是否发生了内存泄漏，可以通过获取该段代码之前和之后的内存状态快照，然后使用 _CrtMemDifference 比较这两个状态：
_CrtMemCheckpoint( &s1 );// 获取第一个内存状态快照
// 在这里进行内存分配
_CrtMemCheckpoint( &s2 );// 获取第二个内存状态快照
// 比较两个内存快照的差异
if ( _CrtMemDifference( &s3, &s1, &s2) )
_CrtMemDumpStatistics( &s3 );// dump 差异结果 顾名思义，_CrtMemDifference 比较两个内存状态（前两个参数），生成这两个状态之间差异的结果（第三个参数）。在程序的开始和结尾放置 _CrtMemCheckpoint 调用，并使用 _CrtMemDifference 比较结果，是检查内存泄漏的另一种方法。如果检测到泄漏，则可以使用 _CrtMemCheckpoint 调用通过二进制搜索技术来分割程序和定位泄漏。
结论
尽管 VC ++ 具有一套专门调试 MFC 应用程序的机制，但本文上述讨论的内存分配很简单，没有涉及到 MFC 对象，所以这些内容同样也适用于 MFC 程序。在 MSDN 库中可以找到很多有关 VC++ 调试方面的资料，如果你能善用 MSDN 库，相信用不了多少时间你就有可能成为调试高手。
本人水平不高，谬误在所难免，请大家拍砖，不要客气。顺祝大家圣诞快乐！
JerryZ 于 2004 年平安夜，
调试方法和技巧
作者：非凡
便于调试的代码风格：
不用全局变量
所有变量都要初始化，成员变量在构造函数中初始化
尽量使用const
详尽的注释
VC++编译选项：
总是使用/W4警告级别
在调试版本里总是使用/GZ编译选项，用来发现在Release版本中才有的错误
没有警告的编译：保证在编译后没有任何警告，但是在消除警告前要进行仔细检查
调试方法：
1、使用 Assert（原则：尽量简单）
assert只在debug下生效，release下不会被编译。
例子：
char* strcpy(char* dest,char* source)
{
assert(source!=0);
assert(dest!=0);
char* returnstring = dest;
while((*dest++ = *source++)!= ‘\0’)
{
;
}
return returnstring;
} 2、防御性的编程
例子：
char* strcpy(char* dest,char* source)
{
if(source == 0)
{
assert(false);
reutrn 0;
}
if(dest == 0)
{
assert(false);
return 0;
}
char* returnstring = dest;
while((*dest++ = *source++)!= ‘\0’)
{
;
}
return returnstring;
} 3、使用Trace
以下的例子只能在debug中显示，
例子：
a)、TRACE
CString csTest ＝ “test”；
TRACE（“CString is ％s\n”，csTest）；b)、ATLTRACE
c)、afxDump
CTime time = CTime::GetCurrentTime();
#ifdef _DEBUG
afxDump << time << “\n”;
#endif4、用GetLastError来检测返回值，通过得到错误代码来分析错误原因
5、把错误信息记录到文件中
异常处理
程序设计时一定要考虑到异常如何处理，当错误发生后，不应简单的报告错误并退出程序，应当尽可能的想办法恢复到出错前的状态或者让程序从头开始运行，并且对于某些错误，应该能够容错，即允许错误的存在，但是程序还是能够正常完成任务。
调试技巧
1、VC++中F5进行调试运行
a)、在output Debug窗口中可以看到用TRACE打印的信息
b)、 Call Stack窗口中能看到程序的调用堆栈
2、当Debug版本运行时发生崩溃，选择retry进行调试，通过看Call Stack分析出错的位置及原因
3、使用映射文件调试
a)、创建映射文件：Project settings中link项，选中Generate mapfile，输出程序代码地址：/MAPINFO: LINES，得到引出序号：/MAPINFO: EXPORTS。
b)、程序发布时，应该把所有模块的映射文件都存档。
c)、查看映射文件：见” 通过崩溃地址找出源代码的出错行”文件。
4、可以调试的Release版本
Project settings中C++项的Debug Info选择为Program Database，Link项的Debug中选择Debug Info和Microsoft format。
5、查看API的错误码，在watch窗口输入@err可以查看或者@err,hr，其中”,hr”表示错误码的说明。
6、Set Next Statement：该功能可以直接跳转到指定的代码行执行，一般用来测试异常处理的代码。
7、调试内存变量的变化：当内存发生变化时停下来。
常见错误
1、在函数返回的时候程序崩溃的原因
a)、写自动变量越界
b)、函数原型不匹配
2、MFC
a)、使用错误的函数原型处理用户定义消息
正确的函数原型为：
afx_msg LRESULT OnMyMessage(WPARAM wParam,LPARAM lParam);3、谨慎使用TerminateThread：使用TerminateThread会造成资源泄漏，不到万不得已，不要使用。
4、使用_beginthreadex，不要使用Create Thread来常见线程。
参考资料：
《Windows程序调试》
功能强大的vc6调试器
作者：yy2better
要成为一位优秀的软件工程师，调试能力必不可缺。本文将较详细介绍VC6调试器的主要用法。
windows平台的调试器主要分为两大类：
1 用户模式(user-mode)调试器：它们都基于win32 Debugging API，有使用方便的界面，主要用于调试用户模式下的应用程序。这类调试器包括Visual C++调试器、WinDBG、BoundChecker、Borland C++ Builder调试器、NTSD等。
2 内核模式(kernel-mode)调试器：内核调试器位于CPU和操作系统之间，一旦启动，操作系统也会中止运行，主要用于调试驱动程序或用户模式调试器不易调试的程序。这类调试器包括WDEB386、WinDBG和softice等。其中WinDBG和softice也可以调试用户模式代码。
国外一位调试高手曾说，他70％调试时间是在用VC++，其余时间是使用WinDBG和softice。毕竟，调试用户模式代码，VC6调试器的效率是非常高的。因此，我将首先在本篇介绍VC6调试器的主要用法，其他调试器的用法及一些调试技能在后续文章中阐述。
一 位置断点（Location Breakpoint）
大家最常用的断点是普通的位置断点，在源程序的某一行按F9就设置了一个位置断点。但对于很多问题，这种朴素的断点作用有限。譬如下面这段代码：
void CForDebugDlg::OnOK()
{
for (int i = 0; i < 1000; i++) //A
{
int k = i * 10 - 2; //B
SendTo(k); //C
int tmp = DoSome(i); //D
int j = i / tmp; //E
}
}
执行此函数，程序崩溃于E行，发现此时tmp为0，假设tmp本不应该为0，怎么这个时候为0呢？所以最好能够跟踪此次循环时DoSome函数是如何运行的，但由于是在循环体内，如果在E行设置断点，可能需要按F5（GO）许多次。这样手要不停的按，很痛苦。使用VC6断点修饰条件就可以轻易解决此问题。步骤如下。
1 Ctrl+B打开断点设置框，如下图：
Figure 1设置高级位置断点
2 然后选择D行所在的断点，然后点击condition按钮，在弹出对话框的最下面一个编辑框中输入一个很大数目，具体视应用而定，这里1000就够了。
3 按F5重新运行程序，程序中断。Ctrl+B打开断点框，发现此断点后跟随一串说明：...487 times remaining。意思是还剩下487次没有执行，那就是说执行到513（1000－487）次时候出错的。因此，我们按步骤2所讲，更改此断点的skip次数,将1000改为513。
4 再次重新运行程序，程序执行了513次循环，然后自动停在断点处。这时，我们就可以仔细查看DoSome是如何返回0的。这样，你就避免了手指的痛苦，节省了时间。
再看位置断点其他修饰条件。如Figure 1所示，在“Enter the expression to be evaluated:”下面，可以输入一些条件，当这些条件满足时，断点才启动。譬如，刚才的程序，我们需要i为100时程序停下来，我们就可以输入在编辑框中输入“i==100”。
另外，如果在此编辑框中如果只输入变量名称，则变量发生改变时，断点才会启动。这对检测一个变量何时被修改很方便，特别对一些大程序。
用好位置断点的修饰条件，可以大大方便解决某些问题。
二 数据断点（Data Breakpoint）
软件调试过程中，有时会发现一些数据会莫名其妙的被修改掉（如一些数组的越界写导致覆盖了另外的变量），找出何处代码导致这块内存被更改是一件棘手的事情（如果没有调试器的帮助）。恰当运用数据断点可以快速帮你定位何时何处这个数据被修改。譬如下面一段程序：
#include "stdafx.h"
#include
int main(int argc, char* argv[])
{
char szName1[10];
char szName2[4];
strcpy(szName1,"shenzhen");
printf("%s\n", szName1); //A
strcpy(szName2, "vckbase"); //B
printf("%s\n", szName1);
printf("%s\n", szName2);
return 0;
}
这段程序的输出是
szName1: shenzhen
szName1: ase
szName2: vckbase
szName1何时被修改呢？因为没有明显的修改szName1代码。我们可以首先在A行设置普通断点，F5运行程序，程序停在A行。然后我们再设置一个数据断点。如下图：
Figure 2 数据断点
F5继续运行，程序停在B行，说明B处代码修改了szName1。B处明明没有修改szName1呀？但调试器指明是这一行，一般不会错，所以还是静下心来看看程序，哦，你发现了：szName2只有4个字节，而strcpy了7个字节，所以覆写了szName1。
数据断点不只是对变量改变有效，还可以设置变量是否等于某个值。譬如，你可以将Figure 2中红圈处改为条件”szName2[0]==''''y''''“,那么当szName2第一个字符为y时断点就会启动。
可以看出，数据断点相对位置断点一个很大的区别是不用明确指明在哪一行代码设置断点。
三 其他
1 在call stack窗口中设置断点，选择某个函数，按F9设置一个断点。这样可以从深层次的函数调用中迅速返回到需要的函数。
2 Set Next StateMent命令（debug过程中，右键菜单中的命令）
此命令的作用是将程序的指令指针（EIP）指向不同的代码行。譬如，你正在调试上面那段代码，运行在A行，但你不愿意运行B行和C行代码，这时，你就可以在D行，右键，然后“Set Next StateMent”。调试器就不会执行B、C行。只要在同一函数内，此指令就可以随意跳前或跳后执行。灵活使用此功能可以大量节省调试时间。
3 watch窗口
watch窗口支持丰富的数据格式化功能。如输入0x65,u，则在右栏显示101。
实时显示windows API调用的错误：在左栏输入@err,hr。
在watch窗口中调用函数。提醒一下，调用完函数后马上在watch窗口中清除它，否则，单步调试时每一步调试器都会调用此函数。
4 messages断点不怎么实用。基本上可以用前面讲述的断点代替。
总结
调试最重要的还是你要思考，要猜测你的程序可能出错的地方，然后运用你的调试器来证实你的猜测。而熟练使用上面这些技巧无疑会加快这个过程。最后，大家如果有关于调试方面的问题，我乐意参与探讨。
VC调试入门
作者：阿荣
概述
调试是一个程序员最基本的技能，其重要性甚至超过学习一门语言。不会调试的程序员就意味着他即使会一门语言，却不能编制出任何好的软件。
这里我简要的根据自己的经验列出调试中比较常用的技巧，希望对大家有用。
本文约定，在选择菜单时，通过/表示分级菜单，例如File/Open表示顶级菜单File的子菜单Open。
设置
为了调试一个程序，首先必须使程序中包含调试信息。一般情况下，一个从AppWizard创建的工程中包含的Debug Configuration自动包含调试信息，但是是不是Debug版本并不是程序包含调试信息的决定因素，程序设计者可以在任意的Configuration中增加调试信息，包括Release版本。
为了增加调试信息，可以按照下述步骤进行：
打开Project settings对话框（可以通过快捷键ALT+F7打开，也可以通过IDE菜单Project/Settings打开)
选择C/C++页，Category中选择general ，则出现一个Debug Info下拉列表框，可供选择的调试信息 方式包括：
命令行 Project settings 说明
无 None 没有调试信息
/Zd Line Numbers Only 目标文件或者可执行文件中只包含全局和导出符号以及代码行信息，不包含符号调试信息
/Z7 C 7.0- Compatible 目标文件或者可执行文件中包含行号和所有符号调试信息，包括变量名及类型，函数及原型等
/Zi Program Database 创建一个程序库(PDB)，包括类型信息和符号调试信息。
/ZI Program Database for Edit and Continue 除了前面/Zi的功能外，这个选项允许对代码进行调试过程中的修改和继续执行。这个选项同时使#pragma设置的优化功能无效
选择Link页，选中复选框"Generate Debug Info"，这个选项将使连接器把调试信息写进可执行文件和DLL
如果C/C++页中设置了Program Database以上的选项，则Link incrementally可以选择。选中这个选项，将使程序可以在上一次编译的基础上被编译（即增量编译），而不必每次都从头开始编译。
断点
断点是调试器设置的一个代码位置。当程序运行到断点时，程序中断执行，回到调试器。断点是 最常用的技巧。调试时，只有设置了断点并使程序回到调试器，才能对程序进行在线调试。
设置断点：可以通过下述方法设置一个断点。首先把光标移动到需要设置断点的代码行上，然后
按F9快捷键
弹出Breakpoints对话框，方法是按快捷键CTRL+B或ALT+F9，或者通过菜单Edit/Breakpoints打开。打开后点击Break at编辑框的右侧的箭头，选择 合适的位置信息。一般情况下，直接选择line xxx就足够了，如果想设置不是当前位置的断点，可以选择Advanced，然后填写函数、行号和可执行文件信息。
去掉断点：把光标移动到给定断点所在的行，再次按F9就可以取消断点。同前面所述，打开Breakpoints对话框后，也可以按照界面提示去掉断点。
条件断点：可以为断点设置一个条件，这样的断点称为条件断点。对于新加的断点，可以单击Conditions按钮，为断点设置一个表达式。当这个表达式发生改变时，程序就 被中断。底下设置包括“观察数组或者结构的元素个数”，似乎可以设置一个指针所指向的内存区的大小，但是我设置一个比较的值但是改动 范围之外的内存区似乎也导致断点起效。最后一个设置可以让程序先执行多少次然后才到达断点。
数据断点：数据断点只能在Breakpoints对话框中设置。选择“Data”页，就显示了设置数据断点的对话框。在编辑框中输入一个表达式，当这个 表达式的值发生变化时，数据断点就到达。一般情况下，这个表达式应该由运算符和全局变量构成，例如：在编辑框中输入 g_bFlag这个全局变量的名字，那么当程序中有g_bFlag= !g_bFlag时，程序就将停在这个语句处。
消息断点：VC也支持对Windows消息进行截获。他有两种方式进行截获：窗口消息处理函数和特定消息中断。
在Breakpoints对话框中选择Messages页，就可以设置消息断点。如果在上面那个对话框中写入消息处理函数的名字，那么 每次消息被这个函数处理，断点就到达（我觉得如果采用普通断点在这个函数中截获，效果应该一样）。如果在底下的下拉 列表框选择一个消息，则每次这种消息到达，程序就中断。
值
Watch
VC支持查看变量、表达式和内存的值。所有这些观察都必须是在断点中断的情况下进行。
观看变量的值最简单，当断点到达时，把光标移动到这个变量上，停留一会就可以看到变量的值。
VC提供一种被成为Watch的机制来观看变量和表达式的值。在断点状态下，在变量上单击右键，选择Quick Watch， 就弹出一个对话框，显示这个变量的值。
单击Debug工具条上的Watch按钮，就出现一个Watch视图（Watch1,Watch2,Watch3,Watch4），在该视图中输入变量或者表达式，就可以观察 变量或者表达式的值。注意：这个表达式不能有副作用，例如++运算符绝对禁止用于这个表达式中，因为这个运算符将修改变量的值，导致 软件的逻辑被破坏。
Memory
由于指针指向的数组，Watch只能显示第一个元素的值。为了显示数组的后续内容，或者要显示一片内存的内容，可以使用memory功能。在 Debug工具条上点memory按钮，就弹出一个对话框，在其中输入地址，就可以显示该地址指向的内存的内容。
Varibles
Debug工具条上的Varibles按钮弹出一个框，显示所有当前执行上下文中可见的变量的值。特别是当前指令涉及的变量，以红色显示。
寄存器
Debug工具条上的Reigsters按钮弹出一个框，显示当前的所有寄存器的值。
进程控制
VC允许被中断的程序继续运行、单步运行和运行到指定光标处，分别对应快捷键F5、F10/F11和CTRL+F10。各个快捷键功能如下：
快捷键 说明
F5 继续运行
F10 单步，如果涉及到子函数，不进入子函数内部
F11 单步，如果涉及到子函数，进入子函数内部
CTRL+F10 运行到当前光标处。
Call Stack
调用堆栈反映了当前断点处函数是被那些函数按照什么顺序调用的。单击Debug工具条上的Call stack就显示Call Stack对话框。在CallStack对话框中显示了一个调用系列，最上面的是当前函数，往下依次是调用函数的上级函数。单击这些函数名可以跳到对应的函数中去。
其他调试手段
系统提供一系列特殊的函数或者宏来处理Debug版本相关的信息，如下：
宏名/函数名 说明
TRACE 使用方法和printf完全一致，他在output框中输出调试信息
ASSERT 它接收一个表达式，如果这个表达式为TRUE，则无动作，否则中断当前程序执行。对于系统中出现这个宏 导致的中断，应该认为你的函数调用未能满足系统的调用此函数的前提条件。例如，对于一个还没有创建的窗口调用SetWindowText等。
VERIFY 和ASSERT功能类似，所不同的是，在Release版本中，ASSERT不计算输入的表达式的值，而VERIFY计算表达式的值。
关注
一个好的程序员不应该把所有的判断交给编译器和调试器，应该在程序中自己加以程序保护和错误定位，具体措施包括：
对于所有有返回值的函数，都应该检查返回值，除非你确信这个函数调用绝对不会出错，或者不关心它是否出错。
一些函数返回错误，需要用其他函数获得错误的具体信息。例如accept返回INVALID_SOCKET表示accept失败，为了查明 具体的失败原因，应该立刻用WSAGetLastError获得错误码，并针对性的解决问题。
有些函数通过异常机制抛出错误，应该用TRY-CATCH语句来检查错误
程序员对于能处理的错误，应该自己在底层处理，对于不能处理的，应该报告给用户让他们决定怎么处理。如果程序出了异常， 却不对返回值和其他机制返回的错误信息进行判断，只能是加大了找错误的难度。
另外：VC中要编制程序不应该一开始就写cpp/h文件，而应该首先创建一个合适的工程。因为只有这样，VC才能选择合适的编译、连接 选项。对于加入到工程中的cpp文件，应该检查是否在第一行显式的包含stdafx.h头文件，这是Microsoft Visual Studio为了加快编译 速度而设置的预编译头文件。在这个#include "stdafx.h"行前面的所有代码将被忽略，所以其他头文件应该在这一行后面被包含。
对于.c文件，由于不能包含stdafx.h，因此可以通过Project settings把它的预编译头设置为“不使用”，方法是：
弹出Project settings对话框
选择C/C++
Category选择Precompilation Header
选择不使用预编译头。
关于调试时输出的字符串信息
作者：①塌糊涂
下载源代码
使用工具：VC6.0，IDA
当我们要在程序中输出调试信息时，常常以字符串的形式来输出，例如：
printf("Some debug information here!\n");这段代码在Debug和Release版下都输出调试信息，这不是我们所要的，一般地大家都会添加
预编译指令，如下所示：
#if _DEBUG
printf("Some debug information here!\n");
#endif这样就达到了在Debug版里程序输出调试信息，在Release版下不输出调试信息的目的。（在Release版里
连printf函数都没有调用）可如果要在程序里的许多地方输出调试信息，若采用上面的方式会很麻烦；
（至于为什么麻烦，可能就是不愿多敲几次键盘吧，呵呵。。。）
于是大家都想到写个输出函数，代码如下：
void printInfo(char *strInfo)
{
#if _DEBUG
printf(strInfo);
#endif
}注：该函数只是演示用的，很简单，没有其他检查字符串功能。
在要输出调试信息的地方，调用如下语句就行：
printInfo("Some debug information here!\n");
确实，在Debug模式下运行该程序，则输出如下信息：
Some debug information here!在Release模式下，则没输出什么信息；
我们往往在这个时候认为一切都OK了；如果你认为是，就没必要往下看了；呵呵。。。
虽然在Release版下运行程序没有输出调试信息来，可这些调试信息却留在了二进制的可执行文件里；
我们可以用IDA来打开该Release版的可执行文件，看到如图一所示的信息：
图一：IDA反汇编后的main函数
注：该函数就是main函数
可见调试信息字符串（“Some debug information here!\n”）确实存在于Release版的可执行文件里；
我们当然不希望别人看到这些调试信息，那有没有办法来防止该调试信息被编译进Release版的可执行文件里呢？
办法是有的，这里来描述2个方法。
办法一：
定义如下宏：
#if _DEBUG
#define _D(str) str
#else
#define _D(str) NULL
#endif此时输出语句变为：
printInfo(_D("Some debug information here!\n"));
在Debug模式下运行程序，依然输出调试信息：
“Some debug information here!”；在Release下，则什么都不输出，此时我们用IDA看一下Release版的二进制文件，则没有发现该调试信息字符串。
如图二示：
图二：IDA反汇编后的main函数
方法二：
定义如下宏：
#if _DEBUG
void printInfo(char *strInfo)
{
printf(strInfo);
}
#else
#define printInfo(str)
#endif注意：该宏把函数printInfo的定义也放进去了；
在Debug模式下运行程序，也同样输出调试信息：
“Some debug information here!”；在Release下，也什么都不输出，此时我们用IDA看一下Release版的二进制文件，也没有发现该调试信息字符串。
如图三示：
图三：IDA反汇编后的main函数
既然方法一和方法二都能实现同样的功能，那究竟那个方法好呢？
方法一和方法二确实都没在可执行文件里留下调试信息，比较一下图二和图三，我们不难发现：
图二当中多了一个函数调用 call nullsub_1，该函数就是printInfo，虽然该函数什么都不做，
但它却调用了，我们一般也不希望该函数调用，所以方法一中多了一个函数调用，增加了开销，
而方法二当中却没有调用该函数。
个人认为方法二较好。
结束语：
若要转载该文章，请保持原文章的完整性，谢谢！
文中如有不妥之处，请指正，谢谢！
E-mail：grapeky@etang.com
调用规范与可变参数表
作者：阿半
语言调用规范是指进行一次函数调用所采用的传递参数的方法，返回值的处理以及调用堆栈的清理。Microsoft C/C++ 语言中采用了五种调用规范，分别是__cdecl, __stdcall, __fastcall，thiscall和nake每一中调用规范都是利用eax作为返回值，如果函数返回值是64位的，则利用edx:eax对来返回值。Nake调用规范非常的灵活，足以独立的一篇文章描述，这里就不再描述nake调用规范。下表列出了前面四种规范调用的特点：
关键字 堆栈清理者 参数传递顺序
__cdecl 调用者 从右至左
__stdcall 被调用者 从右至左
__fastcall 被调用者 从右至左，前两个参数由寄存器ecx，edx传递
thiscall 被调用者或者调用者 从右至左
__cdecl 最大好处在于由于是调用者清理栈，它可以处理可变参数，缺点则在于它增加了程序的大小，因为在每个调用返回的时候，需要多执行一条清理栈的指令。
__stdcall 是在windows程序设计中出现的最多的调用规则，所有的不可变参数的API调用都使用这个规则。
__fastcall 在windows内核设计中被广泛的使用，由于两个参数由寄存器直接传递，采用这种规则的函数效率要比以上两种规则高。
thiscall是C++成员函数的默认调用规范，编译期间，这种调用会根据函数是否支持可变参数表来决定采用什么方式清理堆栈。如果成员函数不支持可变参数，那么它就是用参数入栈，ecx保存this指针的方式进行调用，如果成员函数支持可变参数，那么它的调用和__cdecl类似，唯一不同的是将this指针最后压入栈中进行传递。
调用者和被调用者必须采用同样的规则才能保证程序的正常执行，曾经看到很多程序员犯的错误就是由于调用规范的不一样，致使程序异常，比如：
DWORD ThreadFunc(LPVOID lpParam)
{
//…
}
CreateThread(..,(LPTHREAD_START_ROUTINE)ThreadFunc, …); 如果在编译期间没有指定编译选项/Gz（指定未指明调用规范的函数采用__stdcall方式），那么编译器自动将ThreadFunc处理成__cdecl调用规范（/Gd），这样可能在线程开始的时候正常执行，然而退出的时候由于堆栈没有正常清理，造成访问违例或者非法指令错误。
以上说了很多清理栈的问题，那么为什么清理栈很重要呢。堆栈是线程相关的，也就是说每一个线程含有一个堆栈，这个堆栈上保存了局部变量，调用返回地址等很多线程相关的数据，这也是为什么独立运行的线程可以调用同样一个函数而互不干扰的原因。堆栈的特点恐怕大家已经非常熟悉了，那么根据上面的每一种调用，我给出一个简单的图示来说明清理堆栈的重要性，以及为什么上面的例子代码会出错。
图一 这是线程堆栈在运行的时候的样子
调用前和后esp的差值中间包含了函数参数表，返回地址这样的重要信息，举个简单的调用例子．假设有某个函数定义是这样的：
Int __cdecl func（void* p）；再假设esp调用函数前的数值为0x1234，那么在进入这个函数体内看到的堆栈是这样的：
122C 1230 1234
Next p 这里的next指调用函数后的下一条指令的位置。调用函数的汇编码：
Push p
Call func
Add esp，4 《--注意这里，由于是cdecl调用，需要调用者清栈。而一个__stdcall调用的汇编码：
Push p
Call func 这里没有了add esp，4这个指令，因为在func函数返回的时候自己将esp已经复原了。再来看刚才举的错误的例子，由于强制转换的作用，线程开始函数被设置成了stdcall调用，而实际的线程函数被编译后，并没有执行堆栈的清理工作，线程函数返回的时候，由于堆栈的不正确，当然会发生错误。修改这个bug的方法只要在线程函数的定义前把__cdecl改成_stdcall即可。
有了上面的例子做基础来理解可变参数表就简单的多了，由于各种调用规范的限定，致使只有__cdecl调用规范可以采用可变参数表。先来看看可变参数表的定义（可以参考sdk目录下src\crt\varargs.h）：
typedef char *va_list;
#define _INTSIZEOF(n) ( (sizeof(n) + sizeof(int) - 1) & ~(sizeof(int) - 1) )
#define va_dcl va_list va_alist;
#define va_start(ap) ap = (va_list)&va_alist
#define va_arg(ap,t) ( *(t *)((ap += _INTSIZEOF(t)) - _INTSIZEOF(t)) )
#define va_end(ap) ap = (va_list)0 va_list居然被定义成char* ？没错，这实际是用来定义了一个指针，指针的sizeof()就是操作系统可访问的地址空间的大小，也就是CPU相关的字长。_INTSIZEOF宏很简单，就是用来将数据以n的数据大小对齐。va_start宏有点模糊，可是如果你看懂了上面的堆栈数据结构，那么显然它就是获得最后一个固定参数的地址，也就是堆栈上的地址，va_arg先使得ap指向下一个参数，然后取得当前参数的值（注意，这个值正是堆栈上的值），va_end使得取参数过程结束。
这几个宏完成的动作很简单了，实际就是取得可变参数表在堆栈上的起始位置，然后根据参数类型，依次从堆栈上取出每一个参数。
本文简单的介绍了微软C/C++支持的调用类型，结合实例描述了规范的实际应用，最后根据CRT提供的源代码分析了可变参数表的实现。
仅通过崩溃地址找出源代码的出错行
作者：老罗
提交者：eastvc 发布日期：2003-10-23 9:16:11
原文出处：http://www./articles/show_article.asp?Article_ID=29
作为程序员，我们平时最担心见到的事情是什么？是内存泄漏？是界面不好看？……错啦！我相信我的看法是不会有人反对的——那就是，程序发生了崩溃！
“该程序执行了非法操作，即将关闭。请与你的软件供应商联系。”，呵呵，这句 M$ 的“名言”，恐怕就是程序员最担心见到的东西了。有的时候，自己的程序在自己的机器上运行得好好的，但是到了别人的机器上就崩溃了；有时自己在编写和测试的过程中就莫名其妙地遇到了非法操作，但是却无法确定到底是源代码中的哪行引起的……是不是很痛苦呢？不要紧，本文可以帮助你走出这种困境，甚至你从此之后可以自豪地要求用户把崩溃地址告诉你，然后你就可以精确地定位到源代码中出错的那行了。（很神奇吧？呵呵。）
首先我必须强调的是，本方法可以在目前市面上任意一款编译器上面使用。但是我只熟悉 M$ 的 VC 和 MASM ，因此后面的部分只介绍如何在这两个编译器中实现，请读者自行融会贯通，掌握在别的编译器上使用的方法。
Well，废话说完了，让我们开始！ ：）
首先必须生成程序的 MAP 文件。什么是 MAP 文件？简单地讲， MAP 文件是程序的全局符号、源文件和代码行号信息的唯一的文本表示方法，它可以在任何地方、任何时候使用，不需要有额外的程序进行支持。而且，这是唯一能找出程序崩溃的地方的救星。
好吧，既然 MAP 文件如此神奇，那么我们应该如何生成它呢？在 VC 中，我们可以按下 Alt+F7 ，打开“Project Settings”选项页，选择 C/C++ 选项卡，并在最下面的 Project Options 里面输入：/Zd ，然后要选择 Link 选项卡，在最下面的 Project Options 里面输入： /mapinfo:lines 和 /map:PROJECT_NAME.map 。最后按下 F7 来编译生成 EXE 可执行文件和 MAP 文件。
在 MASM 中，我们要设置编译和连接参数，我通常是这样做的：
rc %1.rc
ml /c /coff /Zd %1.asm
link /subsystem:windows /mapinfo:exports /mapinfo:lines /map:%1.map %1.obj %1.res
把它保存成 makem.bat ，就可以在命令行输入 makem filename 来编译生成 EXE 可执行文件和 MAP 文件了。
在此我先解释一下加入的参数的含义：
/Zd 表示在编译的时候生成行信息
/map[:filename] 表示生成 MAP 文件的路径和文件名
/mapinfo:lines 表示生成 MAP 文件时，加入行信息
/mapinfo:exports 表示生成 MAP 文件时，加入 exported functions （如果生成的是 DLL 文件，这个选项就要加上）
OK，通过上面的步骤，我们已经得到了 MAP 文件，那么我们该如何利用它呢？
让我们从简单的实例入手，请打开你的 VC ，新建这样一个文件：
01 //****************************************************************
02 //程序名称：演示如何通过崩溃地址找出源代码的出错行
03 //作者：罗聪
04 //日期：2003-2-7
05 //出处：http://www.（老罗的缤纷天地）
06 //本程序会产生“除0错误”，以至于会弹出“非法操作”对话框。
07 //“除0错误”只会在 Debug 版本下产生，本程序为了演示而尽量简化。
08 //注意事项：如欲转载，请保持本程序的完整，并注明：
09 //转载自“老罗的缤纷天地”（http://www.）
10 //****************************************************************
11
12 void Crash(void)
13 {
14 int i = 1;
15 int j = 0;
16 i /= j;
17 }
18
19 void main(void)
20 {
21 Crash();
22 }
很显然本程序有“除0错误”，在 Debug 方式下编译的话，运行时肯定会产生“非法操作”。好，让我们运行它，果然，“非法操作”对话框出现了，这时我们点击“详细信息”按钮，记录下产生崩溃的地址——在我的机器上是 0x0040104a 。
再看看它的 MAP 文件：（由于文件内容太长，中间没用的部分我进行了省略）
CrashDemo
Timestamp is 3e430a76 (Fri Feb 07 09:23:02 2003)
Preferred load address is 00400000
Start Length Name Class
0001:00000000 0000de04H .text CODE
0001:0000de04 0001000cH .textbss CODE
0002:00000000 00001346H .rdata DATA
0002:00001346 00000000H .edata DATA
0003:00000000 00000104H .CRT$XCA DATA
0003:00000104 00000104H .CRT$XCZ DATA
0003:00000208 00000104H .CRT$XIA DATA
0003:0000030c 00000109H .CRT$XIC DATA
0003:00000418 00000104H .CRT$XIZ DATA
0003:0000051c 00000104H .CRT$XPA DATA
0003:00000620 00000104H .CRT$XPX DATA
0003:00000724 00000104H .CRT$XPZ DATA
0003:00000828 00000104H .CRT$XTA DATA
0003:0000092c 00000104H .CRT$XTZ DATA
0003:00000a30 00000b93H .data DATA
0003:000015c4 00001974H .bss DATA
0004:00000000 00000014H .idata$2 DATA
0004:00000014 00000014H .idata$3 DATA
0004:00000028 00000110H .idata$4 DATA
0004:00000138 00000110H .idata$5 DATA
0004:00000248 000004afH .idata$6 DATA
Address Publics by Value Rva+Base Lib:Object
0001:00000020 ?Crash@@YAXXZ 00401020 f CrashDemo.obj
0001:00000070 _main 00401070 f CrashDemo.obj
0004:00000000 __IMPORT_DESCRIPTOR_KERNEL32 00424000 kernel32:KERNEL32.dll
0004:00000014 __NULL_IMPORT_DESCRIPTOR 00424014 kernel32:KERNEL32.dll
0004:00000138 __imp__GetCommandLineA@0 00424138 kernel32:KERNEL32.dll
0004:0000013c __imp__GetVersion@0 0042413c kernel32:KERNEL32.dll
0004:00000140 __imp__ExitProcess@4 00424140 kernel32:KERNEL32.dll
0004:00000144 __imp__DebugBreak@0 00424144 kernel32:KERNEL32.dll
0004:00000148 __imp__GetStdHandle@4 00424148 kernel32:KERNEL32.dll
0004:0000014c __imp__WriteFile@20 0042414c kernel32:KERNEL32.dll
0004:00000150 __imp__InterlockedDecrement@4 00424150 kernel32:KERNEL32.dll
0004:00000154 __imp__OutputDebugStringA@4 00424154 kernel32:KERNEL32.dll
0004:00000158 __imp__GetProcAddress@8 00424158 kernel32:KERNEL32.dll
0004:0000015c __imp__LoadLibraryA@4 0042415c kernel32:KERNEL32.dll
0004:00000160 __imp__InterlockedIncrement@4 00424160 kernel32:KERNEL32.dll
0004:00000164 __imp__GetModuleFileNameA@12 00424164 kernel32:KERNEL32.dll
0004:00000168 __imp__TerminateProcess@8 00424168 kernel32:KERNEL32.dll
0004:0000016c __imp__GetCurrentProcess@0 0042416c kernel32:KERNEL32.dll
0004:00000170 __imp__UnhandledExceptionFilter@4 00424170 kernel32:KERNEL32.dll
0004:00000174 __imp__FreeEnvironmentStringsA@4 00424174 kernel32:KERNEL32.dll
0004:00000178 __imp__FreeEnvironmentStringsW@4 00424178 kernel32:KERNEL32.dll
0004:0000017c __imp__WideCharToMultiByte@32 0042417c kernel32:KERNEL32.dll
0004:00000180 __imp__GetEnvironmentStrings@0 00424180 kernel32:KERNEL32.dll
0004:00000184 __imp__GetEnvironmentStringsW@0 00424184 kernel32:KERNEL32.dll
0004:00000188 __imp__SetHandleCount@4 00424188 kernel32:KERNEL32.dll
0004:0000018c __imp__GetFileType@4 0042418c kernel32:KERNEL32.dll
0004:00000190 __imp__GetStartupInfoA@4 00424190 kernel32:KERNEL32.dll
0004:00000194 __imp__HeapDestroy@4 00424194 kernel32:KERNEL32.dll
0004:00000198 __imp__HeapCreate@12 00424198 kernel32:KERNEL32.dll
0004:0000019c __imp__HeapFree@12 0042419c kernel32:KERNEL32.dll
0004:000001a0 __imp__VirtualFree@12 004241a0 kernel32:KERNEL32.dll
0004:000001a4 __imp__RtlUnwind@16 004241a4 kernel32:KERNEL32.dll
0004:000001a8 __imp__GetLastError@0 004241a8 kernel32:KERNEL32.dll
0004:000001ac __imp__SetConsoleCtrlHandler@8 004241ac kernel32:KERNEL32.dll
0004:000001b0 __imp__IsBadWritePtr@8 004241b0 kernel32:KERNEL32.dll
0004:000001b4 __imp__IsBadReadPtr@8 004241b4 kernel32:KERNEL32.dll
0004:000001b8 __imp__HeapValidate@12 004241b8 kernel32:KERNEL32.dll
0004:000001bc __imp__GetCPInfo@8 004241bc kernel32:KERNEL32.dll
0004:000001c0 __imp__GetACP@0 004241c0 kernel32:KERNEL32.dll
0004:000001c4 __imp__GetOEMCP@0 004241c4 kernel32:KERNEL32.dll
0004:000001c8 __imp__HeapAlloc@12 004241c8 kernel32:KERNEL32.dll
0004:000001cc __imp__VirtualAlloc@16 004241cc kernel32:KERNEL32.dll
0004:000001d0 __imp__HeapReAlloc@16 004241d0 kernel32:KERNEL32.dll
0004:000001d4 __imp__MultiByteToWideChar@24 004241d4 kernel32:KERNEL32.dll
0004:000001d8 __imp__LCMapStringA@24 004241d8 kernel32:KERNEL32.dll
0004:000001dc __imp__LCMapStringW@24 004241dc kernel32:KERNEL32.dll
0004:000001e0 __imp__GetStringTypeA@20 004241e0 kernel32:KERNEL32.dll
0004:000001e4 __imp__GetStringTypeW@16 004241e4 kernel32:KERNEL32.dll
0004:000001e8 __imp__SetFilePointer@16 004241e8 kernel32:KERNEL32.dll
0004:000001ec __imp__SetStdHandle@8 004241ec kernel32:KERNEL32.dll
0004:000001f0 __imp__FlushFileBuffers@4 004241f0 kernel32:KERNEL32.dll
0004:000001f4 __imp__CloseHandle@4 004241f4 kernel32:KERNEL32.dll
0004:000001f8 \177KERNEL32_NULL_THUNK_DATA 004241f8 kernel32:KERNEL32.dll
entry point at 0001:000000f0
Line numbers for .\Debug\CrashDemo.obj(d:\msdev\myprojects\crashdemo\crashdemo.cpp) segment .text
13 0001:00000020 14 0001:00000038 15 0001:0000003f 16 0001:00000046
17 0001:00000050 20 0001:00000070 21 0001:00000088 22 0001:0000008d
如果仔细浏览 Rva+Base 这栏，你会发现第一个比崩溃地址 0x0040104a 大的函数地址是 0x00401070 ，所以在 0x00401070 这个地址之前的那个入口就是产生崩溃的函数，也就是这行：
0001:00000020 ?Crash@@YAXXZ 00401020 f CrashDemo.obj
因此，发生崩溃的函数就是 ?Crash@@YAXXZ ，所有以问号开头的函数名称都是 C++ 修饰的名称。在我们的源程序中，也就是 Crash() 这个子函数。
OK，现在我们轻而易举地便知道了发生崩溃的函数名称，你是不是很兴奋呢？呵呵，先别忙，接下来，更厉害的招数要出场了。
请注意 MAP 文件的最后部分——代码行信息（Line numbers information），它是以这样的形式显示的：
13 0001:00000020
第一个数字代表在源代码中的代码行号，第二个数是该代码行在所属的代码段中的偏移量。
如果要查找代码行号，需要使用下面的公式做一些十六进制的减法运算：
崩溃行偏移 = 崩溃地址（Crash Address） - 基地址（ImageBase Address） - 0x1000
为什么要这样做呢？细心的朋友可能会留意到 Rva+Base 这栏了，我们得到的崩溃地址都是由 偏移地址（Rva）+ 基地址（Base） 得来的，所以在计算行号的时候要把基地址减去，一般情况下，基地址的值是 0x00400000 。另外，由于一般的 PE 文件的代码段都是从 0x1000 偏移开始的，所以也必须减去 0x1000 。
好了，明白了这点，我们就可以来进行小学减法计算了：
崩溃行偏移 = 0x0040104a - 0x00400000 - 0x1000 = 0x4a
如果浏览 MAP 文件的代码行信息，会看到不超过计算结果，但却最接近的数是 CrashDemo.cpp 文件中的：
16 0001:00000046
也就是在源代码中的第 16 行，让我们来看看源代码:
16 i /= j;
哈！！！果然就是第 16 行啊！
兴奋吗？我也一样！ ：）
方法已经介绍完了，从今以后，我们就可以精确地定位到源代码中的崩溃行，而且只要编译器可以生成 MAP 文件（包括 VC、MASM、VB、BCB、Delphi……），本方法都是适用的。我们时常抱怨 M$ 的产品如何如何差，但其实 M$ 还是有意无意间提供了很多有价值的信息给我们的，只是我们往往不懂得怎么利用而已……相信这样一来，你就可以更为从容地面对“非法操作”提示了。你甚至可以要求用户提供崩溃的地址，然后就可以坐在家中舒舒服服地找到出错的那行，并进行修正。
是不是很爽呢？ ：）
对“仅通过崩溃地址找出源代码的出错行”一文的补充与改进
作者：上海伟功通信 roc
下载源代码
读了老罗的“仅通过崩溃地址找出源代码的出错行”(下称"罗文")一文后，感觉该文还是可以学到不少东西的。不过文中尚存在有些说法不妥，以及有些操作太繁琐的地方 。为此，本人在学习了此文后，在多次实验实践基础上，把该文中的一些内容进行补充与改进，希望对大家调试程序，尤其是release版本的程序有帮助 。欢迎各位朋友批评指正。
一、该方法适用的范围
在windows程序中造成程序崩溃的原因很多，而文中所述的方法仅适用与:由一条语句当即引起的程序崩溃。如原文中举的除数为零的崩溃例子。而笔者在实际工作中碰到更多的情况是:指针指向一非法地址 ，然后对指针的内容进行了，读或写的操作。例如：
void Crash1()
{
char * p =(char*)100;
*p=100;
} 这些原因造成的崩溃，无论是debug版本，还是release版本的程序，使用该方法都可找到造成崩溃的函数或子程序中的语句行，具体方法的下面还会补充说明。 另外，实践中另一种常见的造成程序崩溃的原因:函数或子程序中局部变量数组越界付值，造成函数或子程序返回地址遭覆盖，从而造成函数或子程序返回时崩溃。例如:
#include
void Crash2();
int main(int argc,char* argv[])
{
Crash2();
return 0;
}
void Crash2()
{
char p[1];
strcpy(p,"0123456789");
}在vc中编译运行此程序的release版本，会跳出如下的出错提示框。
图一 上面例子运行结果
这里显示的崩溃地址为:0x34333231。这种由前面语句造成的崩溃根源，在后续程序中方才显现出来的情况，显然用该文所述的方法就无能为力了。不过在此例中多少还有些蛛丝马迹可寻找到崩溃的原因:函数Crash2中的局部数组p只有一个字节大小 ，显然拷贝"0123456789"这个字符串会把超出长度的字符串拷贝到数组p的后面，即*(p+1)=''1''，*(p+2)=''2''，*(p+3)=''3''，*(p+4)=4。。。。。。而字符''1''的ASC码的值为0x31，''2''为0x32，''3''为0x33，''4''为0x34。。。。。，由于intel的cpu中int型数据是低字节保存在低地址中 ，所以保存字符串''1234''的内存，显示为一个4字节的int型数时就是0x34333231。显然拷贝"0123456789"这个字符串时，"1234"这几个字符把函数Crash2的返回地址给覆盖 ，从而造成程序崩溃。对于类似的这种造成程序崩溃的错误朋友们还有其他方法排错的话，欢迎一起交流讨论。
二、设置编译产生map文件的方法
该文中产生map文件的方法是手工添加编译参数来产生map文件。其实在vc6的IDE中有产生map文件的配置选项的。操作如下:先点击菜单"Project"->"Settings。。。"，弹出的属性页中选中"Link"页 ，确保在"category"中选中"General"，最后选中"Generate mapfile"的可选项。若要在在map文件中显示Line numbers的信息的话 ，还需在project options 中加入/mapinfo:lines 。Line numbers信息对于"罗文"所用的方法来定位出错源代码行很重要 ，但笔者后面会介绍更加好的方法来定位出错代码行，那种方法不需要Line numbers信息。
图二 设置产生MAP文件
三、定位崩溃语句位置的方法
"罗文"所述的定位方法中，找到产生崩溃的函数位置的方法是正确的，即在map文件列出的每个函数的起始地址中，最近的且不大于崩溃地址的地址即为包含崩溃语句的函数的地址 。但之后的再进一步的定位出错语句行的方法不是最妥当，因为那种方法前提是，假设基地址的值是 0x00400000 ，以及一般的 PE 文件的代码段都是从 0x1000偏移开始的 。虽然这种情况很普遍，但在vc中还是可以基地址设置为其他数，比如设置为0x00500000，这时仍旧套用
崩溃行偏移 = 崩溃地址 - 0x00400000 - 0x1000 的公式显然无法找到崩溃行偏移。 其实上述公式若改为
崩溃行偏移 = 崩溃地址 - 崩溃函数绝对地址 + 函数相对偏移即可通用了。仍以"罗文"中的例子为例:"罗文"中提到的在其崩溃程序的对应map文件中，崩溃函数的编译结果为
0001:00000020 ?Crash@@YAXXZ 00401020 f CrashDemo。obj 对与上述结果，在使用我的公式时 ，"崩溃函数绝对地址"指00401020， 函数相对偏移指 00000020， 当崩溃地址= 0x0040104a时， 则 崩溃行偏移 = 崩溃地址 - 崩溃函数起始地址+ 函数相对偏移 = 0x0040104a - 0x00401020 + 0x00000020= 0x4a，结果与"罗文"计算结果相同 。但这个公式更通用。
四、更好的定位崩溃语句位置的方法。
其实除了依靠map文件中的Line numbers信息最终定位出错语句行外，在vc6中我们还可以通过编译程序产生的对应的汇编语句，二进制码，以及对应c/c++语句为一体的"cod"文件来定位出错语句行 。先介绍一下产生这种包含了三种信息的"cod"文件的设置方法:先点击菜单"Project"->"Settings。。。"，弹出的属性页中选中"C/C++"页 ，然后在"Category"中选则"Listing Files"，再在"Listing file type"的组合框中选择"Assembly，Machine code， and source"。接下去再通过一个具体的例子来说明这种方法的具体操作。
图三 设置产生"cod"文件
准备步骤1)产生崩溃的程序如下:
01 //****************************************************************
02 //文件名称：crash。cpp
03 //作用: 演示通过崩溃地址找出源代码的出错行新方法
04 //作者： 伟功通信 roc
05 //日期： 2005-5-16
06//****************************************************************
07 void Crash1();
08 int main(int argc,char* argv[])
09 {
10 Crash1();
11 return 0;
12 }
13
14 void Crash1()
15 {
16 char * p =(char*)100;
17 *p=100;
18 }
准备步骤2)按本文所述设置产生map文件(不需要产生Line numbers信息)。
准备步骤3)按本文所述设置产生cod文件。
准备步骤4)编译。这里以debug版本为例(若是release版本需要将编译选项改为不进行任何优化的选项，否则上述代码会因为优化时看作废代码而不被编译，从而看不到崩溃的结果)，编译后产生一个"exe"文件 ，一个"map"文件，一个"cod"文件。
运行此程序，产生如下如下崩溃提示:
图四 上面例子运行结果
排错步骤1)定位崩溃函数。可以查询map文件获得。我的机器编译产生的map文件的部分如下:
Crash
Timestamp is 42881a01 (Mon May 16 11:56:49 2005)
Preferred load address is 00400000
Start Length Name Class
0001:00000000 0000ddf1H .text CODE
0001:0000ddf1 0001000fH .textbss CODE
0002:00000000 00001346H .rdata DATA
0002:00001346 00000000H .edata DATA
0003:00000000 00000104H .CRT$XCA DATA
0003:00000104 00000104H .CRT$XCZ DATA
0003:00000208 00000104H .CRT$XIA DATA
0003:0000030c 00000109H .CRT$XIC DATA
0003:00000418 00000104H .CRT$XIZ DATA
0003:0000051c 00000104H .CRT$XPA DATA
0003:00000620 00000104H .CRT$XPX DATA
0003:00000724 00000104H .CRT$XPZ DATA
0003:00000828 00000104H .CRT$XTA DATA
0003:0000092c 00000104H .CRT$XTZ DATA
0003:00000a30 00000b93H .data DATA
0003:000015c4 00001974H .bss DATA
0004:00000000 00000014H .idata$2 DATA
0004:00000014 00000014H .idata$3 DATA
0004:00000028 00000110H .idata$4 DATA
0004:00000138 00000110H .idata$5 DATA
0004:00000248 000004afH .idata$6 DATA
Address Publics by Value Rva+Base Lib:Object
0001:00000020 _main 00401020 f Crash.obj
0001:00000060 ?Crash1@@YAXXZ 00401060 f Crash.obj
0001:000000a0 __chkesp 004010a0 f LIBCD:chkesp.obj
0001:000000e0 _mainCRTStartup 004010e0 f LIBCD:crt0.obj
0001:00000210 __amsg_exit 00401210 f LIBCD:crt0.obj
0001:00000270 __CrtDbgBreak 00401270 f LIBCD:dbgrpt.obj
...
对于崩溃地址0x00401082而言，小于此地址中最接近的地址(Rva+Base中的地址)为00401060，其对应的函数名为?Crash1@@YAXXZ，由于所有以问号开头的函数名称都是 C++ 修饰的名称 ，"@@YAXXZ"则为区别重载函数而加的后缀，所以?Crash1@@YAXXZ就是我们的源程序中，Crash1() 这个函数。
排错步骤2)定位出错行。打开编译生成的"cod"文件，我机器上生成的文件内容如下:
TITLE E:\Crash\Crash。cpp
.386P
include listing.inc
if @Version gt 510
.model FLAT
else
_TEXT SEGMENT PARA USE32 PUBLIC ''CODE''
_TEXT ENDS
_DATA SEGMENT DWORD USE32 PUBLIC ''DATA''
_DATA ENDS
CONST SEGMENT DWORD USE32 PUBLIC ''CONST''
CONST ENDS
_BSS SEGMENT DWORD USE32 PUBLIC ''BSS''
_BSS ENDS
$SYMBOLS SEGMENT BYTE USE32 ''DEBSYM''
$SYMBOLS ENDS
$TYPES SEGMENT BYTE USE32 ''DEBTYP''
$TYPES ENDS
_TLS SEGMENT DWORD USE32 PUBLIC ''TLS''
_TLS ENDS
; COMDAT _main
_TEXT SEGMENT PARA USE32 PUBLIC ''CODE''
_TEXT ENDS
; COMDAT ?Crash1@@YAXXZ
_TEXT SEGMENT PARA USE32 PUBLIC ''CODE''
_TEXT ENDS
FLAT GROUP _DATA， CONST, _BSS
ASSUME CS: FLAT, DS: FLAT, SS: FLAT
endif
PUBLIC ?Crash1@@YAXXZ ; Crash1
PUBLIC _main
EXTRN __chkesp:NEAR
; COMDAT _main
_TEXT SEGMENT
_main PROC NEAR ; COMDAT
; 9 : {
00000 55 push ebp
00001 8b ec mov ebp， esp
00003 83 ec 40 sub esp, 64 ; 00000040H
00006 53 push ebx
00007 56 push esi
00008 57 push edi
00009 8d 7d c0 lea edi, DWORD PTR [ebp-64]
0000c b9 10 00 00 00 mov ecx， 16 ; 00000010H
00011 b8 cc cc cc cc mov eax， -858993460 ; ccccccccH
00016 f3 ab rep stosd
; 10 : Crash1();
00018 e8 00 00 00 00 call ?Crash1@@YAXXZ ; Crash1
; 11 : return 0;
0001d 33 c0 xor eax， eax
; 12 : }
0001f 5f pop edi
00020 5e pop esi
00021 5b pop ebx
00022 83 c4 40 add esp, 64 ; 00000040H
00025 3b ec cmp ebp, esp
00027 e8 00 00 00 00 call __chkesp
0002c 8b e5 mov esp, ebp
0002e 5d pop ebp
0002f c3 ret 0
_main ENDP
_TEXT ENDS
; COMDAT ?Crash1@@YAXXZ
_TEXT SEGMENT
_p$ = -4
?Crash1@@YAXXZ PROC NEAR ; Crash1, COMDAT
; 15 : {
00000 55 push ebp
00001 8b ec mov ebp, esp
00003 83 ec 44 sub esp, 68 ; 00000044H
00006 53 push ebx
00007 56 push esi
00008 57 push edi
00009 8d 7d bc lea edi, DWORD PTR [ebp-68]
0000c b9 11 00 00 00 mov ecx, 17 ; 00000011H
00011 b8 cc cc cc cc mov eax, -858993460 ; ccccccccH
00016 f3 ab rep stosd
; 16 : char * p =(char*)100;
00018 c7 45 fc 64 00
00 00 mov DWORD PTR _p$[ebp], 100 ; 00000064H
; 17 : *p=100;
0001f 8b 45 fc mov eax, DWORD PTR _p$[ebp]
00022 c6 00 64 mov BYTE PTR [eax], 100 ; 00000064H
; 18 : }
00025 5f pop edi
00026 5e pop esi
00027 5b pop ebx
00028 8b e5 mov esp, ebp
0002a 5d pop ebp
0002b c3 ret 0
?Crash1@@YAXXZ ENDP ; Crash1
_TEXT ENDS
END
其中
?Crash1@@YAXXZ PROC NEAR ; Crash1, COMDAT为Crash1汇编代码的起始行。产生崩溃的代码便在其后的某个位置。接下去的一行为:
; 15 : {冒号后的"{"表示源文件中的语句，冒号前的"15"表示该语句在源文件中的行数。 这之后显示该语句汇编后的偏移地址，二进制码，汇编代码。如
00000 55 push ebp其中"0000"表示相对于函数开始地址后的偏移，"55"为编译后的机器代码，" push ebp"为汇编代码。从"cod"文件中我们可以看出，一条(c/c++)语句通常需要编译成数条汇编语句 。此外有些汇编语句太长则会分两行显示如:
00018 c7 45 fc 64 00
00 00 mov DWORD PTR _p$[ebp], 100 ; 00000064H其中"0018"表示相对偏移，在debug版本中，这个数据为相对于函数起始地址的偏移(此时每个函数第一条语句相对偏移为0000)；release版本中为相对于代码段第一条语句的偏移(即代码段第一条语句相对偏移为0000，而以后的每个函数第一条语句相对偏移就不为0000了)。"c7 45 fc 64 00 00 00 "为编译后的机器代码 ，"mov DWORD PTR _p$[ebp]， 100"为汇编代码， 汇编语言中";"后的内容为注释，所以";00000064H"，是个注释这里用来说明100转换成16进制时为"00000064H"。
接下去，我们开始来定位产生崩溃的语句。
第一步，计算崩溃地址相对于崩溃函数的偏移，在本例中已经知道了崩溃语句的地址(0x00401082)，和对应函数的起始地址(0x00401060)，所以崩溃地址相对函数起始地址的偏移就很容易计算了:
崩溃偏移地址 = 崩溃语句地址 - 崩溃函数的起始地址 = 0x00401082 - 0x00401060 = 0x22。第二步，计算出错的汇编语句在cod文件中的相对偏移。我们可以看到函数Crash1()在cod文件中的相对偏移地址为0000，则
崩溃语句在cod文件中的相对偏移 = 崩溃函数在cod文件中相对偏移 + 崩溃偏移地址 = 0x0000 + 0x22 = 0x22第三步，我们看Crash1函数偏移0x22除的代码是什么?结果如下
00022 c6 00 64 mov BYTE PTR [eax], 100 ; 00000064H这句汇编语句表示将100这个数保存到寄存器eax所指的内存单元中去，保存空间大小为1个字节(byte)。程序正是执行这条命令时产生了崩溃，显然这里eax中的为一个非法地址 ，所以程序崩溃了!
第四步，再查看该汇编语句在其前面几行的其对应的源代码，结果如下:
; 17 : *p=100;其中17表示该语句位于源文件中第17行，而“*p=100;”这正是源文件中产生崩溃的语句。
至此我们仅从崩溃地址就查找出了造成崩溃的源代码语句和该语句所在源文件中的确切位置，甚至查找到了造成崩溃的编译后的确切汇编代码!
怎么样，是不是感觉更爽啊?
五、小节
1、新方法同样要注意可以适用的范围，即程序由一条语句当即引起的崩溃。另外我不知道除了VC6外，是否还有其他的编译器能够产生类似的"cod"文件。
2、我们可以通过比较 新方法产生的debug和releae版本的"cod"文件，查找那些仅release版本(或debug版本)有另一个版本没有的bug(或其他性状)。例如"罗文"中所举的那个用例 ，只要打开release版本的"cod"文件，就明白了为啥debug版本会产生崩溃而release版本却没有:原来release版本中产生崩溃的语句其实根本都没有编译 。同样本例中的release版本要看到崩溃的效果，需要将编译选项改为为不优化的配置。
关于MFC下检查和消除内存泄露的技巧
作者：freepublic
摘要
本文分析了Windows环境使用MFC调试内存泄露的技术，介绍了在Windows环境下用VC++查找，定位和消除内存泄露的方法技巧。
关键词：VC++；CRT 调试堆函数；试探法。
编译环境
VC++6.0
技术原理
检测内存泄漏的主要工具是调试器和 CRT 调试堆函数。若要启用调试堆函数，请在程序中包括以下语句：
#define CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>注意 #include 语句必须采用上文所示顺序。如果更改了顺序，所使用的函数可能无法正确工作。
通过包括 crtdbg.h，将 malloc 和 free 函数映射到其“Debug”版本_malloc_dbg 和_free_dbg，这些函数将跟踪内存分配和释放。此映射只在调试版本（在其中定义了 _DEBUG）中发生。发布版本使用普通的 malloc 和 free 函数。
#define 语句将 CRT 堆函数的基版本映射到对应的“Debug”版本。并非绝对需要该语句，但如果没有该语句，内存泄漏转储包含的有用信息将较少。
在添加了上面所示语句之后，可以通过在程序中包括以下语句来转储内存泄漏信息：
_CrtDumpMemoryLeaks();当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“输出”窗口中显示内存泄漏信息。内存泄漏信息如下所示：
Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete. 如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏转储如下所示：
Detected memory leaks!
Dumping objects ->
{18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete. 未定义 _CRTDBG_MAP_ALLOC 时，所显示的会是：
内存分配编号（在大括号内）。
块类型（普通、客户端或 CRT）。
十六进制形式的内存位置。
以字节为单位的块大小。
前 16 字节的内容（亦为十六进制）。
定义了 _CRTDBG_MAP_ALLOC 时，还会显示在其中分配泄漏的内存的文件。文件名后括号中的数字（本示例中为 20）是该文件内的行号。
转到源文件中分配内存的行
在"输出"窗口中双击包含文件名和行号的行。
-或-
在"输出"窗口中选择包含文件名和行号的行，然后按 F4 键。
_CrtSetDbgFlag 如果程序总在同一位置退出，则调用 _CrtDumpMemoryLeaks 足够方便，但如果程序可以从多个位置退出该怎么办呢？不要在每个可能的出口放置一个对 _CrtDumpMemoryLeaks 的调用，可以在程序开始包括以下调用：
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); 该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF 两个位域，如上所示。
说明
在VC++6.0的环境下，不再需要额外的添加
#define CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h> 只需要按F5，在调试状态下运行，程序退出后在"输出窗口"可以看到有无内存泄露。如果出现
Detected memory leaks!
Dumping objects -> 就有内存泄露。
确定内存泄露的地方
根据内存泄露的报告，有两种消除的方法：
第一种比较简单，就是已经把内存泄露映射到源文件的，可以直接在"输出"窗口中双击包含文件名和行号的行。例如
Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20)就是源文件名称和行号。
第二种比较麻烦，就是不能映射到源文件的，只有内存分配块号。
Detected memory leaks!
Dumping objects ->
{18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete. 这种情况我采用一种"试探法"。由于内存分配的块号不是固定不变的，而是每次运行都是变化的，所以跟踪起来很麻烦。但是我发现虽然内存分配的块号是变化的，但是变化的块号却总是那几个，也就是说多运行几次，内存分配的块号很可能会重复。因此这就是"试探法"的基础。
先在调试状态下运行几次程序，观察内存分配的块号是哪几个值；
选择出现次数最多的块号来设断点，在代码中设置内存分配断点： 添加如下一行（对于第 18 个内存分配）：
_crtBreakAlloc = 18; 或者，可以使用具有同样效果的 _CrtSetBreakAlloc 函数：
_CrtSetBreakAlloc(18);
在调试状态下运行序，在断点停下时，打开"调用堆栈"窗口，找到对应的源代码处；
退出程序，观察"输出窗口"的内存泄露报告，看实际内存分配的块号是不是和预设值相同，如果相同，就找到了；如果不同，就重复步骤3，直到相同。
最后就是根据具体情况，在适当的位置释放所分配的内存。
发表于 @ 2007年05月17日 15:56:00 | 评论( 0 ) | 编辑| 举报| 收藏
旧一篇:VC++6.0中内存泄漏检测(转) | 新一篇:_CrtDumpMemoryLeaks()的作用(转)
查看最新精华文章 请访问博客首页相关文章
vc++内存泄漏检测使用 CRT 调试功能来检测内存泄漏VC使用CRT调试功能来检测内存泄漏检测内存泄漏使用CRT调试功能来检测内存泄漏VC使用CRT调试功能来检测内存泄漏发表评论 表 情： 评论内容： 用 户 名： 登录 注册 匿名评论 匿名用户验 证 码： 重新获得验证码 热门招聘职位【《七雄争霸》研发商：北京游戏谷】诚聘JAVA、C++技术专家及各类游戏精英【华北计算技术研究所】急聘Java开发、系统架构、需求分析【无锡富赢科技有限公司】诚聘 程序员ASP.NET及软件开发工程师C++【励展博览集团】急聘IT Application Developer企业应用程序开发员【西安瑞祺科技】诚聘JAVA软件工程师【雅邦网络】诚聘网站项目经理、JAVA技术总监、JAVA开发、网站测试工程师【科锐】诚招IT中高级人才，抢工作机会，赢IPAD啦！【imo】-国际风投+福利租房+奖金+期权+不加班+调休，邀你共创互联网的奇迹【YOHO！新力传媒】高薪诚聘各类网站人才 北京+南京【方正国际】诚招软件精英 北京+苏州+武汉【热聘】搜狐畅游全国热招开发工程师【爱立信上海】急招多媒体、核心网开发测试工程师，国际团队等你加盟！ 【《七雄争霸》研发商：北京游戏谷】诚聘JAVA、C++技术专家及各类游戏精英【华北计算技术研究所】急聘Java开发、系统架构、需求分析【无锡富赢科技有限公司】诚聘 程序员ASP.NET及软件开发工程师C++【励展博览集团】急聘IT Application Developer企业应用程序开发员【西安瑞祺科技】诚聘JAVA软件工程师【雅邦网络】诚聘网站项目经理、JAVA技术总监、JAVA开发、网站测试工程师【科锐】诚招IT中高级人才，抢工作机会，赢IPAD啦！【imo】-国际风投+福利租房+奖金+期权+不加班+调休，邀你共创互联网的奇迹【YOHO！新力传媒】高薪诚聘各类网站人才 北京+南京【方正国际】诚招软件精英 北京+苏州+武汉【热聘】搜狐畅游全国热招开发工程师【爱立信上海】急招多媒体、核心网开发测试工程师，国际团队等你加盟！ 公司简介|招贤纳士|广告服务|银行汇款账号|联系方式|版权声明|法律顾问|问题报告
北京创新乐知信息技术有限公司 版权所有, 京 ICP 证 070598 号
世纪乐知(北京)网络技术有限公司 提供技术支持
江苏乐知网络技术有限公司 提供商务支持
Email:webmaster@csdn.net
Copyright © 1999-2010, CSDN.NET, All Rights Reserved
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/bairny/archive/2007/05/17/1613431.aspx
|
