Cannot lauch 64 bits application under VS2015

Question

I migrated an existing C++ application from VS2008 to VS2015, which is made of mixed code.

It worked like a charm both compiled for 32 and 64 bits under VS2008.

Now compiled under VS2015, the 32 bits version works (though it recompiles nearly every time) but the 64 bits version (Release build) crashes immediately with the message

Unhandled exception at 0x00007FFF52E3B049 (ntdll.dll) in mViz+.exe: 0xC0000374: A heap has been corrupted (parameters: 0x00007FFF52EA27F0)

and call stack

    ntdll.dll!RtlReportFatalFailure()   Unknown
    ntdll.dll!RtlReportCriticalFailure()    Unknown
    ntdll.dll!RtlpHeapHandleError() Unknown
    ntdll.dll!RtlpHpHeapHandleError()   Unknown
    ntdll.dll!RtlpLogHeapFailure()  Unknown
    ntdll.dll!RtlSizeHeap() Unknown
    ucrtbase.dll!_recalloc_base()   Unknown
    ucrtbase.dll!<lambda>(void)()   Unknown
    ucrtbase.dll!__crt_seh_guarded_call<int>::operator()<<lambda_638799b9deba96c50f710eeac98168cd>,<lambda>(void) & __ptr64,<lambda_a6f7d7db0129f75315ebf26d50c089f1> >()   Unknown
    ucrtbase.dll!_register_onexit_function()    Unknown
>   mViz+.exe!_onexit(int(*)() function) Line 268   C++
    mViz+.exe!atexit(void(*)() function) Line 276   C++
    mViz+.exe!__scrt_initialize_thread_safe_statics() Line 110  C++
    [External Code] 
    mscoreei.dll!_CorExeMain()  Unknown
    mscoree.dll!_CorExeMain_Exported()  Unknown
    kernel32.dll!BaseThreadInitThunk()  Unknown
    ntdll.dll!RtlUserThreadStart()  Unknown

This is what happens under debugger control. Otherwise, the application just doesn't start.

A Debug build also has a problematic behavior. Without the debugger,

and with:

Exception thrown at 0x00007FFF52DA70A0 (ntdll.dll) in mViz+.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

If there is a handler for this exception, the program may be safely continued.

This seems to be a heap corruption problem but I have the feeling that the crash occurs before any of my code is called.

How can I investigate that ?

Update:

Under certain circumstances, I get the following message:

Unhandled Exception: System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at _initterm_e((fnptr)* pfbegin, (fnptr)* pfend) in f:\dd\vctools\crt\crtw32\msilcrt\puremsilcode.cpp:line 69
   at <CrtImplementationDetails>.LanguageSupport.InitializeNative(LanguageSupport* ) in f:\dd\vctools\crt\crtw32\msilcrt\mstartup.cpp:line 355
   at <CrtImplementationDetails>.LanguageSupport._Initialize(LanguageSupport* ) in f:\dd\vctools\crt\crtw32\msilcrt\mstartup.cpp:line 598
   at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* ) in f:\dd\vctools\crt\crtw32\msilcrt\mstartup.cpp:line 805
   at .cctor() in f:\dd\vctools\crt\crtw32\msilcrt\mstartup.cpp:line 856
   --- End of inner exception stack trace ---

Update 2:

I know that it is difficult to answer without seeing the phenomenon. But I am not asking for a cause, I am rather asking about how to investigate deeper, given that the debugger is of no help. (All it tells me is that there is heap corruption at launch-time.)

Update 3:

When migrated to VS2017, the application does start, but the 64 bits version is dead slow. In fact, unusable. One of the threads shows 100% load for ages. The 32 bits build behaves normally.

whops, sorry :) Anyway, without some code it's not much easy to say anything, could depend on a 3rd party library though if you have one. — Michael Chourdakis, Jul 12 '19 at 19:44
@MichaelChourdakis: all code Is C++ CLI and native C++ precompiled in a library (code of mine). Everything validated since years. — , Jul 12 '19 at 19:48
see if this can help: https://learn.microsoft.com/en-us/cpp/porting/overview-of-potential-upgrade-issues-visual-cpp?view=vs-2019 — RATHI, Jul 12 '19 at 20:02
Are all libraries that are linked also recompiled? You will get heap corruption if you try to allocated in a 2008 library and free in a 2017 one, similarly if you're accidentally using a 32bit lib in a 64bit app! I find crashes before your code even starts are down to library load + startup issues. — gbjbaanb, Jul 13 '19 at 16:43
@gbjbaanb: yes they are. Double-checked and triple-checked. The platform toolsets and target platform are identical, as well as other relevant settngs. I am used to that kind of issues. — , Jul 13 '19 at 16:51

score 0 · Answer 1 · answered Jul 13 '19 at 21:30

I have made big progress. From this post, Mixed-mode C++/CLI crashing: heap corruption in atexit (static destructor registration), I observe that indeed the entry point of the application was not standard, and restoring it solved the crash issue.

Now remains to understand the slowness of the 64 bits version.

Cannot lauch 64 bits application under VS2015

1 Answers1