VC开发中HEAP CORRUPTION DETECTED错误

今天在VS2010调试项目中出现的问题,通过调用free出现了这个错误。一般VC的HEAP CORRUPTION DETECTED这类错误只有在开发的DEBUG版本上出现,Realse版本可能看不到这个错误,有时甚至软件程序还能正常运行,但是千万不能被表象所蒙蔽,随着时间的流逝,程序会因为一些莫名其妙的问题而崩溃,所以在Debug版本上出现这个问题是有其道理的,这里无非是对内存的操作出现了问题,内存经典的操作就是通过调用malloc申请内存,以及调用free释放内存,微软在调试模式下帮我们修改了这两个函数,特别是malloc多分配了一些空间,这些空间就是用于检测内存泄漏(Memory Leaks)和内存损坏(Memory damage)等一系列问题的。所以一旦出现这些问题,Debug版本下能立刻反应过来,告知HEAP CORRUPTION DETECTED以及详细原因并中止程序执行。不过我们如果点击调试,VC将跟踪到SDK的malloc实现中去,不是我们自己的程序问题点,这是比较头疼的地方。

首先出现内存泄漏,一般是内存泄漏不会出现这么明显的中断,所以判断是否因为分配内存损坏的原因,经典的是“野指针”问题,因为free释放指针指定的空间后不能置空指针,所以该指针就变成了野指针,其所指向的地址不是我们所期望的,如果这个时候调用free将造成内存损坏,Realse模式下可能会导致程序异常中止,Debug模式下就会出现HEAP CORRUPTION DETECTED的错误。

鉴于此我检查了代码,并没有找到类似问题,这时我的注意力集中在下面图片指示的一段文字上:

继续阅读“VC开发中HEAP CORRUPTION DETECTED错误”

VC++中忽略所有默认库纯Win32 API编译及链接

原文发表于2008年10月15日 已略作修改

我们在用VC++编写Windows程序的时候可能会发现一般可执行体(.EXE)的文件体积都比较大,于是非常羡慕那些使用Win32汇编编写程序的人,因为他们编写的可执行文件非常小。其实应用程序的体积是一方面,另外应用程序的部署环境则是需要注意的另一方面,这方面我深有体会,曾经使用Visual Studio 2008编译过一个C++的Win32程序,本地测试正常,但是部署到客户机时,出现缺少什么动态库,于是还要安装Visual C++ 2008可再发行组件包(Visual C++ 2005 Redistributable Package),这给软件部署带来了一定的麻烦,另外对于一个功能比较简单的程序,安装如此的组件包,可能心里会不好受,我们希望对于一些比较简单的应用程序可以直接调用系统提供的API,从而降低部署程序的复杂度。

其实对于VC++我们可以采用忽略所有默认库的方式避免编译器引入不必要的动态链接库,当然你可以使用如下的预编译宏。

#pragma comment(linker, "/nodefaultlib")

实际上,我们还需要在属性的 连接器->清单文件 将 生成清单 改为 否;然后选择 清单工具->输入和输出 将嵌入清单改为否;在C/C++中选择代码生成将缓冲区安全检查改为否(/GS-),否则编译会出现一个错误,设定程序的主入口点。注意上述配置一般在Release下,生成文件也在Release下编译链接,Debug可能无法使用,如果需要防止Debug模式编译,可以使用如下宏命令:

#ifdef _DEBUG   
#error Debug is disabled   
#endif    //    _DEBUG

另外对于函数入口的重新定义可以使用如下宏以代替属性配置。

#pragma comment(linker,"/ENTRY:wWinMainCRTStartup")

由于这里指定使用的宽字符(Unicode)API调用,所以我们将入口点定义为wWinMainCRTStartup,ANSI版建议定义为WinMainCRTStartup,另外Windows API有两个版本的API接口,ANSI版和Unicode版,ANSI版主要是为了兼容Windows 98等旧系统,一般ANSI API编译的程序体积比较小,但由于现在的基于NT的新的操作系统基本使用的Unicode API,相对而言,对于这些系统,Unicode API接口的速度要快于ANSI 接口的速度。

入口点做如下定义:

#include <windows.h>
HINSTANCE g_hInst    = NULL;
int WINAPI SimpleMain(VOID)
{
  return 0; 
}
VOID WINAPI wWinMainCRTStartup(VOID)
{
  g_hInst = GetModuleHandle(NULL);
  ExitProcess(SimpleMain());
}

理论上这样可以编译链接了,实际上还有很多错误,主要是链接方面的。由于我们使用了纯Windows API,所以不能使用memset,这时可以调用FillMemory(RtlFillMemory)、ZeroMemory(RtlZeroMemory)等等,这时编译会出现链接错误 是关于_memset符号链接的,实际上我们并没有使用memset,那这个错误是怎么产生的呢?其实微软重新定义了RtlFillMemory等API并使它们挂接到memset这个函数下,为了我们能够顺利编译,我们需要在自己的头文件里做如下处理。

#undef RtlFillMemory 
#undef RtlZeroMemory
extern "C" NTSYSAPI BOOL NTAPI 
RtlFillMemory ( VOID *Source1,DWORD Source2,BYTE Fill );
extern "C" NTSYSAPI BOOL NTAPI 
RtlZeroMemory( PVOID Destination, SIZE_T Length);
#define memset(Destination,Fill,Length) \
    RtlFillMemory((Destination),(Length),(Fill))

下面我们继续我们的编译,在链接这里又出现错误。

error LNK2001: 无法解析的外部符号 __imp__InitCommonControls@0
error LNK2001: 无法解析的外部符号 __imp__InitCommonControlsEx@4

跟踪后发现这两个函数InitCommonControls和InitCommonControlsEx由COMCTL32.dll导出,参考网上的解决方案,加入lib库。

#include <commctrl.h>
#pragma comment(lib, "comctl32.lib")

错误依旧!经过仔细寻找发现在属性配置里 链接器->输入 在附加依赖项里填入 comctl32.lib,编译,通过!

另外对于空间分配建议参考HeapAlloc、HeapFree等等API函数。

如果大家在操作过程中遇到什么问题欢迎讨论!

2011年4月5日更新

这篇文章在网上转载还是比较多的,部分童鞋在转载时没有署名,希望他们在看到这篇文章时及时更新出处,另外文章我略作修改,去掉了一个问题比较大的函数,就是处理命令行的那段,以免误导大家。

最后要说的是,除非你是做病毒木马,否则再小体积的程序势必带来运行的不稳定,请三思,如果对编译小体积的程序感兴趣的话,可以参考TCC : Tiny C Compiler

VB与C语言的DLL新线程回调问题

原文由本人于2007年8月1日 18:52:59 发布于wyev.com(该域名已停用)。

不使用新线程回调成功,但使用新的线程回调VB出现<程序遇到问题需要关闭…>的错误。我为这个问题已经头疼几天了,问了微软的工程师,答复如下:

In vb6,Calling a function back from a different thread will cause access violations, so, Please prevent such designs.

看来还是要另想办法啦^_^。

—源代码如下—
MyTest.Dll (编译环境:VS2005)
MyTest.c

#include <stdio .h>
#include <stdlib .h>
#include <malloc .h>
#include <string .h>
#include <windows .h>
typedef void (__stdcall *FUNPTR)(BSTR pbstr);
typedef struct _TEST_PARA{
	long pfunA;
	long pfunB;
}UTESTMY;
 
DWORD __stdcall NewRun(UTESTMY *pAt){
	FUNPTR vbFunA,vbFunB;
	vbFunA=(FUNPTR)(pAt->pfunA);
	vbFunB=(FUNPTR)(pAt->pfunB);
	vbFunA(SysAllocString(L""回调A""));
	vbFunB(SysAllocString(L""回调B""));
	free(pAt);
	return 0;
}
//线程结构体传参数回调VB显示程序遇到问题需要关闭
void __stdcall TheRun(long pfunA,long pfunB){
	HANDLE hThread;
	DWORD dwThreadId;
	UTESTMY *pAt;
	pAt=(UTESTMY *)malloc(sizeof(UTESTMY));
	pAt->pfunA=pfunA;
	pAt->pfunB=pfunB;
	hThread = 
CreateThread(NULL,NULL,(LPTHREAD_START_ROUTINE)NewRun,pAt,0,&dwThreadId);
	WaitForSingleObject(hThread,INFINITE); 
	CloseHandle(hThread);
}
 
//下面这个在VB里调用是正常的
DWORD __stdcall ComRun(long pfunA,long pfunB){
	FUNPTR vbFunA,vbFunB;
	vbFunA=(FUNPTR)(pfunA);
	vbFunB=(FUNPTR)(pfunB);
	vbFunA(SysAllocString(L""回调A""));
	vbFunB(SysAllocString(L""回调B""));
	return 0;
}</windows></string></malloc></stdlib></stdio>

继续阅读“VB与C语言的DLL新线程回调问题”