none
HeapAlloc and HeapFree failing in release version RRS feed

  • Question

  • I am  executing some c++ applications(Dll's) which is getting called from a c++ DCOM application. In certain schenario's when it encounters HeapAlloc and HeapRelease it crashes...And most important this happens only in the release version. We can also execute these C++ applications individually by attaching the Dll's from any C++ MFC Calling process. In those cases it works fine in both release and debug. The issues happens when these C++ applications are called from DCOM application in release version.  Any update regarding this issue will be very helpfull.
    Monday, June 17, 2019 8:24 AM

All replies

  • Hello,

    how do you call HeapAlloc and HeapFree?

    Regards, Guido

    Monday, June 17, 2019 8:48 AM
  • Anyone attempting to help will ask for more information. The following information from you would help and should have been provided in the original question.

    • What does failing mean in the context of this question? What error code or whatever?
    • Source code, especially the source code for HeapAlloc and HeapRelease
    • Why you must create a new account for every question you ask


    Sam Hobbs
    SimpleSamples.Info

    Monday, June 17, 2019 8:57 AM
  • HeapCreate( HGE, 16 * si.dwPageSize, 0L )

    This is the way HeapAlloc and HeapFree are being called. Before calling them HeapCreate is called once.

    TCHAR* path = (TCHAR *) HeapAlloc( hHeap, HGE, sizeof (TCHAR ));

    TCHAR* path2 = (TCHAR *) HeapAlloc( hHeap, HGE, sizeof (TCHAR ));

    HeapFree(hHeap,0,path);

    HeapFree(hHeap,0,path2);

    Monday, June 17, 2019 10:49 AM
  • Well, I would say that the usage of the memory allocated is important here.

    In the code you provided, you are only allocating enough memory for a single TCHAR in each call, so if you use it as a string then this is going to result in heap corruption.

    But anyway, as a simple example:

    #define _CRT_SECURE_NO_WARNINGS
    #include <Windows.h>
    #include <cstdio>
    #include <cstring>
    
    int wmain()
    {
    	HANDLE heap = HeapCreate(0, 16 * 4096, 0);
    	if (heap == nullptr)
    	{
    		return GetLastError();
    	}
    
    	wchar_t *str1 = static_cast<wchar_t *>(HeapAlloc(heap, 0, sizeof(wchar_t) * (500)));
    	if (str1 == nullptr)
    	{
    		return GetLastError();
    	}
    	wchar_t *str2 = static_cast<wchar_t *>(HeapAlloc(heap, 0, sizeof(wchar_t) * (500)));
    	if (str2 == nullptr)
    	{
    		return GetLastError();
    	}
    
    	wcscpy(str1, L"Hello World, this is a string in str1");
    	wcscpy(str2, L"Hello World, this is a string in str2");
    
    	wprintf(L"%s\n", str1);
    	wprintf(L"%s\n", str2);
    
    	HeapFree(heap, 0, str2);
    	HeapFree(heap, 0, str1);
    
    	return 0;
    }

    This works perfectly fine for x86 and x64 using the release configuration.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Monday, June 17, 2019 11:46 AM
  • If HGE means HEAP_GENERATE_EXCEPTIONS be aware that any exceptions generated will NOT be C++ exceptions that can be caught with try/catch.  Rather, they will be SEH (Structured Exception Handling) exceptions.  See https://docs.microsoft.com/en-us/windows/desktop/Debug/structured-exception-handling

    So any such unhandled exception will result in program termination.

    • Edited by RLWA32 Monday, June 17, 2019 11:56 AM
    Monday, June 17, 2019 11:49 AM
  • Thanks very much for your response. Just one question. Shall i try changing it from TCHAR* to wchar_t*. we do use TCHAR to return values. 
    Wednesday, June 19, 2019 8:51 AM
  • an additional information..My application character set is configured as "Use Multi Byte"..Thanks
    Wednesday, June 19, 2019 8:56 AM
  • Still waiting for an answer to Simple Samples' very relevant question -- "What does failing mean in the context of this question? What error code or whatever?"
    In other words, what does "crash" mean?

    • Edited by RLWA32 Wednesday, June 19, 2019 11:02 AM
    Wednesday, June 19, 2019 11:01 AM
  • No, I was using wchar_t in my sample as a design choice. There is no requirement for this.

    If you don't use the Unicode character set, using wchar_t would introduce compiler errors too, since TCHAR would be a typedef of char, and char * is not compatible with wchar_t *.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Wednesday, June 19, 2019 1:36 PM
  • The running application crashes  the following Error in windbg

    (38ec.1ab0): Unknown exception - code c0000374 (!!! second chance !!!)
    eax=004fd458 ebx=77e84920 ecx=00000001 edx=77e848e8 esi=00000002 edi=04620a40
    eip=77e4941a esp=004fd434 ebp=004fd4c4 iopl=0         nv up ei pl zr na pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
    ntdll!RtlReportCriticalFailure+0x88:
    77e4941a eb33            jmp     ntdll!RtlReportCriticalFailure+0xbd (77e4944f)

    in windbg. When I further checked the call stack  in details These is the exact spot where the errors are reported.

    ChildEBP RetAddr  
    00 004fd4c4 77e5261b ntdll!RtlReportCriticalFailure+0x88
    01 004fd4d0 77df5d94 ntdll!RtlpReportHeapFailure+0x2f
    02 004fd4d8 77df5e37 ntdll!RtlpHeapHandleError+0x16
    03 004fd508 77daac45 ntdll!RtlpLogHeapFailure+0x9f
    04 004fd6e0 77da996a ntdll!RtlpAllocateHeap+0x505
    05 004fd728 77da97de ntdll!RtlpAllocateHeapInternal+0x17a
    *** WARNING: Unable to verify checksum for E:\CloudForms - New\advl-lfh-hub-LFormPdfEngine\advl-LFMClassic-LForm4-master\Release\LForm4.ocx
    06 004fd740 1000e9e0 ntdll!RtlAllocateHeap+0x3e
    07 004fd75c 1000fa37 LForm4!CTagInfo::CTagInfo+0x9d [e:\cloudforms - new\advl-lfh-hub-lformpdfengine\lfmclassic-lformshared\lform\cformxml.cpp @ 256]

    I have highlighted the issue. Its related to HeapAlloc in the file Cformxml.cpp. Here the application is allocating memory using HeapAlloc and its crashing. The application reads line by line from a XMLFile allocates memory using HeadAlloc and does some parsing. Till the first 4 lines it reads and allocates memory without problems in the fifth line while allocating it crashes...

    Thursday, June 20, 2019 8:29 AM
  • I want to add one more thing. This happens only in the release version. Sometimes in release version it works fine without any issues. 
    Thursday, June 20, 2019 8:43 AM
  • The running application crashes  the following Error in windbg

    (38ec.1ab0): Unknown exception - code c0000374 (!!! second chance !!!)
    eax=004fd458 ebx=77e84920 ecx=00000001 edx=77e848e8 esi=00000002 edi=04620a40
    eip=77e4941a esp=004fd434 ebp=004fd4c4 iopl=0         nv up ei pl zr na pe nc
    cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
    ntdll!RtlReportCriticalFailure+0x88:
    77e4941a eb33            jmp     ntdll!RtlReportCriticalFailure+0xbd (77e4944f)

    in windbg. When I further checked the call stack  in details These is the exact spot where the errors are reported.

    ChildEBP RetAddr  
    00 004fd4c4 77e5261b ntdll!RtlReportCriticalFailure+0x88
    01 004fd4d0 77df5d94 ntdll!RtlpReportHeapFailure+0x2f
    02 004fd4d8 77df5e37 ntdll!RtlpHeapHandleError+0x16
    03 004fd508 77daac45 ntdll!RtlpLogHeapFailure+0x9f
    04 004fd6e0 77da996a ntdll!RtlpAllocateHeap+0x505
    05 004fd728 77da97de ntdll!RtlpAllocateHeapInternal+0x17a
    *** WARNING: Unable to verify checksum for E:\CloudForms - New\advl-lfh-hub-LFormPdfEngine\advl-LFMClassic-LForm4-master\Release\LForm4.ocx
    06 004fd740 1000e9e0 ntdll!RtlAllocateHeap+0x3e
    07 004fd75c 1000fa37 LForm4!CTagInfo::CTagInfo+0x9d [e:\cloudforms - new\advl-lfh-hub-lformpdfengine\lfmclassic-lformshared\lform\cformxml.cpp @ 256]

    I have highlighted the issue. Its related to HeapAlloc in the file Cformxml.cpp. Here the application is allocating memory using HeapAlloc and its crashing. The application reads line by line from a XMLFile allocates memory using HeadAlloc and does some parsing. Till the first 4 lines it reads and allocates memory without problems in the fifth line while allocating it crashes...

    Exception C0000374 is heap corruption.  It is likely that at some point your code has corrupted the heap and the problem is made evident when execution reaches the HeapAlloc function. 

    I suggest you review Darran Rowe's earlier observation that pointed out - "In the code you provided, you are only allocating enough memory for a single TCHAR in each call, so if you use it as a string then this is going to result in heap corruption."

    Thursday, June 20, 2019 8:46 AM
  • I suggest you run a static code analysis tool to help identify the misbehaving code.  VS includes code analysis and there are also third-party tools such as CppCheck.
    Thursday, June 20, 2019 9:04 AM