The assertion failure happens in line 160 of afxwin2.inl, and the break point takes me to line 1394 of dbgheap.c - "_ASSERTE(pHead->nBlockUse == nBlockUse);". This only happens on exit (I don't have to do anything, just start app, then close and it fails. Oddly enough, it only happens on Release Build. My understanding at this point is that there is some sort of memory corruption happening, but for the life of me, I've had so much trouble finding the cause. I was looking at this and thought perhaps my bug could be an issue of mismatching CRT Libs as I get the warnings:
1>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4098: defaultlib 'mfc90.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4098: defaultlib 'mfcs90.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
The main statically linked library I started using leading up to the error is written in C++, not C, so according to the previously linked reply, it looks like that could explain why ignoring the offending libs the compiler says are conflicting doesn't seem to do a thing. What makes me think that perhaps it isn't that is that I have the src for that lib. It seems to use the same CRT as my app (checked via project properties). That being said, I may simply not understand how the generation of a .lib from src works and this may not be a valid way to check what CRT was used to make the .lib, in which case, please enlighten me.
I've attempted to use app verifier to root out the cause, but I'm having trouble using that well. The log says there were no errors or warnings and I can't seem to open the log file itself to have a closer look - not that it would matter, given no errors detected, I would assume it is essentially empty.
This issue doesn't appear to affect the app's functionality in any way. When testing the app outside the IDE, no issues show themselves. I just really don't like giving the okay on something buggy like this regardless of the effect - or lack there of - on functionality.
It looks like the issue was that the legacy code I'm using doesn't mesh well with the ribbon api. Replacing all the ribbon functionality with classic toolbars and dialog bars completely eliminated the bug.