我在VS2010中调试我的C ++ Win32程序，我总是得到“Windows在program.exe中触发了一个断点”。
我对代码进行了双重检查，三重检查和四重检查。我找不到任何它应该发生的原因。但它每次都发生在同一点，所以必须有一些东西。
涉及相当多的代码（构造函数，析构函数，窗口消息，内存分配和释放等等），所以在这里放置一些具体的东西是相当困难的，但同时我理解没有代码你无法做出太多解释。
基本上，只需单击一个按钮，就会显示一个显示图像的窗口。如果满足某个条件，我向该窗口发送WM_DESTROY并删除触发析构函数的变量，该析构函数在Release()上调用LPPICTURE，并且释放的变量设置为{{ 1}}。
然后，当用户再次单击该按钮时，它会尝试动态分配一个新实例（与之前完全相同），这就是生成断点的地方。 AFAIK（我一直试图调试这个超过一个小时），构造函数甚至没有启动。它似乎打破了动态内存分配的NULL函数。
据我所知，它突破new()，即第54行或malloc.c
奇怪的是，当我在VS2010之外运行exe时，一切都继续正常。该程序不会崩溃，它会继续按预期工作！
答案 0 :(得分：6)
在没有看到代码的情况下很难诊断，但根据您的描述，它听起来像堆损坏。我的猜测是HeapAlloc检测到损坏并生成int 3，这实际上会在调试器中触发断点。我的建议是检查所有对象分配/解除分配，并确保您没有踩到尚未分配的内存（或已经被释放的内存）。
此外，您提到您正在明确发送WM_DESTROY消息。通常，您希望让Windows为您生成WM_DESTROY消息，方法是致电{1}}，或将DestroyWindow发送到窗口并让WM_CLOSE拨打DefWindowProc } 为了你。这可能与您的问题无关，但仅限于FYI。
答案 1 :(得分：2)
根据我的经验，当发生这种情况时，你会有堆修正/无效指针使用。断点发生在检测到故障的位置。这几乎从来都不是实际的失败 - 问题发生得更早。这些类型的断点仅在存在调试器时发生。很多时候，腐败并不是致命的，甚至也不会通过其他行动来解决。
无论如何，您应该考虑appverifier以查看是否可以找到问题。请务必使用堆检查选项。
答案 2 :(得分：-1)
我认为问题是如果您在visual studio中调试必须将所需文件（在本例中是您正在讨论的图像）文件放在调试文件夹中的某个目录中，程序崩溃（在调试时）因为因此当你在VS2010之外运行exe时它找不到文件它不会崩溃