4

I'm having an issue where my application is failing a debug assertion (_CrtIsValidHeapPointer) before anything is even executed. I know this because I added a breakpoint on the first statement of my main function, and it fails the assertion before the breakpoint is reached.

Is there a way to somehow "step through" everything that happens before my main function is called? Things like static member initializations, etc.

I should note that my program is written in C++/CLI. I recently upgraded to VS2015 and am targeting the v140 toolset. The C++ libraries I'm using (ImageMagick, libsquish, and one of my own C++ libraries) have been tested individually, and I do not receive the assertion failure with these libraries, so it has to be my main application.

I haven't changed any of the code since I upgraded from VS2013, so I'm a little stumped on what is going on.

EDIT: Here is the call stack. This is after I click "Retry" in the assertion failed window. I then get a multitude of other exceptions being thrown, but they are different each time I run the program.

>   ucrtbased.dll!527a6853()    
[Frames below may be incorrect and/or missing, no symbols loaded for ucrtbased.dll] 
ucrtbased.dll!527a7130()    
ucrtbased.dll!527a69cb()    
ucrtbased.dll!527c8116()    
ucrtbased.dll!527c7eb3()    
ucrtbased.dll!527c7fb3()    
ucrtbased.dll!527c84b0()    
PathCreator.exe!_onexit(int (void)* const function)  Line 268 + 0xe bytes   C++
PathCreator.exe!atexit(void (void)* const function)  Line 276 + 0x9 bytes   C++
PathCreator.exe!std::`dynamic initializer for '_Fac_tidy_reg''()  Line 65 + 0xd bytes   C++
[External Code] 
mscoreei.dll!7401cd87()     
mscoree.dll!741fdd05()  
kernel32.dll!76c33744()     
ntdll.dll!7720a064()    
ntdll.dll!7720a02f()
Noah Roth
  • 276
  • 6
  • 19
  • You can try a different debugger, typically [tag:WinDbg]. It's not easy to use, but give it a try. Run the executable from WinDbg, at the first breakpoint [set up the symbols](http://stackoverflow.com/questions/30019889/how-to-set-up-symbols-in-windbg) and run the application (`g`). When the exception is thrown, show it (`.exr -1`) and the callstack (`k`). `!analyze -v` might give some results too. If you consider WinDbg as an option, I can write a more detailed answer, but for now, this is tagged as Visual Studio. – Thomas Weller Sep 01 '15 at 21:48

1 Answers1

6

You have to debug the C runtime initialization code. Not intuitive to do because the debugger tries hard to avoid it and get you into the main() entrypoint instead. But still possible, use Debug > New Breakpoint > Function Breakpoint.

Enter _initterm for the function name, Language = C.

Press F5 and the breakpoint will hit. You should see the C runtime source code. You can now single-step through the initialization functions of your program one-by-one, every call to (**it)() executes one.

That's exactly what you asked for. But not very likely what you actually want. The odds that your code produces this error are very low. Much more likely is that one of these libraries causes this problem. They are likely to be built targeting another version of the C runtime library. And therefore have their own _initterm() function.

Having more than one copy of the C runtime library in a process is generally very unhealthy. And highly likely to generate heap corruption. If you can't locate it from the stack trace (be sure to change the Debugger Type from Auto to Mixed, always post the stack trace in an SO question) then the next thing you should strongly consider is rebuilding those libraries with the VS version you use.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 1
    Strangely, I added that function breakpoint, and it still failed the debug assertion before it hit the breakpoint. I clicked "Continue" and went through a plethora of other errors, but it never hit the breakpoint at _initterm. As for recompiling the libraries, I recompiled all 3 of the C++ libraries I use and ensured I was targeting the same toolset (v140). I have edited my question to include the call stack. – Noah Roth Sep 02 '15 at 02:15