2

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!

cpx
  • 17,009
  • 20
  • 87
  • 142
Ozzah
  • 10,631
  • 16
  • 77
  • 116

3 Answers3

6

It's difficult to diagnose without seeing the code, but based on your description, it sounds like heap corruption. My guess is that HeapAlloc detected corruption and generated a int 3 which 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_DESTROY message explicitly. Typically, you want to let Windows generate the WM_DESTROY message for you, either by calling DestroyWindow, or by sending WM_CLOSE to the window and letting DefWindowProc call DestroyWindow for you. This may be unrelated to your issue, but just FYI.

cbranch
  • 4,709
  • 2
  • 27
  • 25
  • 1
    +1 This could very well be it. After the window handles the fake `WM_DESTROY` it is liable to get another one when the window really is destroyed properly. @Ozzah Do not ever generate `WM_DESTROY`. The system generates it and you handle it. – David Heffernan Nov 11 '11 at 05:23
  • 1
    Relevant link: http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspx – Mike Kwan Nov 11 '11 at 10:20
  • I checked over my code and I am not sending `WM_DESTROY`, I'm calling `DestroyWindow(HWND)`. I realise it's difficult but there really is a lot of possibly-related code. I'm going to have another long, careful look over it again and see if I can pinpoint it. – Ozzah Nov 12 '11 at 23:59
2

In my experience when that happens you have heap correction/invalid pointer usage. The breakpoint occurs at the point where the fault is detected. This is almost never the actual failure - the problem occurred earlier. Those types of breakpoint occur only with a debugger present. Many times the corruption is not fatal or even is fixed by some other action.

In any event you should consider appverifier to see if it can find the problem. Be sure to use the heap checking options.

Robin Caron
  • 627
  • 4
  • 8
-1

i think the problem is if your debugging inside visual studio you must put the needed files (in this case the image you are talking about) files in a certain directory in the debug folder ,the program crashes (while being debugged) because it does not find the file therefore when you run the exe outside of VS2010 it doesnt crash

andrewmag
  • 252
  • 1
  • 4
  • 11
  • then why it runs perfectly outside visual studio it really happens to me a lot when i load images it runs perfectly outside the VS but crashes while debugging and putting the image inside the debug directory solves the problem (there is two debug folders) – andrewmag Nov 14 '11 at 00:22
  • For starters, I'm loading an image from an arbitrary path using an `OPENFILENAME` so the path is completely irrelevant. It wouldn't be convenient if it could only load images in the same working directory. Secondly, I did say in my original question that the breakpoint is triggered when allocating on the heap - the code that does anything at all with images happens in the distant future. I'm pretty sure this is an `INT 3` interrupt which should be completely invisible to the user when the program isn't running in a debugger. (Confirmation?) Only the side-effects like later crashes can be seen. – Ozzah Nov 14 '11 at 02:19