I’m debugging my C++ Win32 program in VS2010 and I always get “Windows has triggered a breakpoint in program.exe”.
I’ve double-checked, triple-checked, and quadruple-checked the code. I can’t find any reason it should be happening. But it happens at the same point each time so there must be something.
There is quite a lot of code involved (constructors, destructors, window messages, memory allocation and deallocation, etc…) so it’s quite difficult to put something concrete here, but at the same time I understand that without the code you can’t really do much to give an explanation.
Basically at the click of a button, a window is shown which shows an image. If a certain condition is met, I send a WM_DESTROY to that window and delete the variable which triggers the destructor which calls Release() on my LPPICTURE, and the freed variable gets set to NULL.
Then, when the user clicks the button again, it tries to dynamically allocate a new instance (in the exact same way it did previously), and that’s where the breakpoint is generated. AFAIK (and I’ve been trying to debug this for over an hour now), the constructor doesn’t even start. It seems to be breaking inside the new() function for dynamic memory allocation.
As far as I can tell, it breaks on return HeapAlloc(_crtheap, 0, size ? size : 1); which is line 54 or malloc.c
What’s weird is that when I run the exe outside of VS2010, everything continues fine. The program doesn’t crash, and it continues to work as expected!
It’s difficult to diagnose without seeing the code, but based on your description, it sounds like heap corruption. My guess is that
HeapAllocdetected corruption and generated aint 3which will essentially trigger a breakpoint in the debugger. My advice is to review all of your object allocations/deallocations and make sure that you aren’t stepping on memory that you have not allocated (or that has already been freed).Also, you mentioned that you are sending a
WM_DESTROYmessage explicitly. Typically, you want to let Windows generate theWM_DESTROYmessage for you, either by callingDestroyWindow, or by sendingWM_CLOSEto the window and lettingDefWindowProccallDestroyWindowfor you. This may be unrelated to your issue, but just FYI.