我正在使用其他人创建的程序。我在编码方面有相当多的经验，但在 C++ 编码方面没有那么多经验，所以我在这里做了很多“边做边学”。所以这个程序看起来很稳定，我开始了我的工作，主要包括对程序的小部分进行小修改。最近做了一些性能优化，看起来也很稳定，但是前两天我改了一些东西，一直在崩溃。所以我恢复了我的更改，但仍然出现崩溃。我开始使用带有激活页面堆的应用程序验证器和全局标志，并检查所有与堆相关的内容以找出导致这些问题的原因。因此，从那时起，调试器总是因“std::bad_alloc”错误而崩溃。
现在我的问题是：我可以绝对确定，启用应用程序验证程序的这个 bad_alloc 崩溃是程序内部错误的一个指标吗？使用应用程序验证程序时，程序本身会使用大量内存，大约 1-1.1gb，但不再使用了。总系统内存最多使用了 80-90%，所以我不认为有可用空间太少导致的实际分配问题。你怎么看？
不，您不能绝对确定任意 C++ 程序中的任何内容，因为您的程序可能包含未定义的行为（事实上，几乎可以肯定它确实存在，尽管它可能与手头的问题无关）。也就是说，通常的原因std::bad_alloc是无法分配内存。
使用std::set_new_handler设置自定义new_handler，并在其中放置断点。如果触发了断点，那么您的问题几乎可以肯定是无法分配内存（此时程序的状态可能有助于调试您的问题）。
默认情况下，x86 的 Windows 上的 32 位进程被限制为 2GB 的地址空间（完整地址空间的下半部分）。
如果您的程序执行大量分配和释放，或者如果您的程序需要大量连续分配，那么是的，当您的程序仅使用 1.1GB 工作集时，很有可能没有足够的连续地址空间来服务分配。
（几年前我参与了一个大型项目，该项目受到地址空间的严格限制。对于我们来说，使用 1.2 到 1.4 GB 的工作集“内存不足”是很常见的。）
Page Heap 肯定会使这个问题更加严重，因为大多数分配比它们通常的大小要大得多。
您应该研究当二进制文件因 std::bad_alloc 崩溃时收到的堆栈。
通常，这应该是因为new无法分配内存。通过堆栈，您应该能够知道请求了多少内存，如果这对您来说很奇怪（例如“请分配 3Go！”），那么您就知道错误在哪里了。
阅读您的问题时不清楚，但是如果您的意思是该进程使用了高达 80%-90% 的可用虚拟内存，那么您的内存可能是碎片化的，并且您正在尝试分配一个对象太大而无法容纳剩余的空闲小内存块......因此分配错误，尽管您的进程仍有内存可玩。
在您的代码中进行搜索以查看您的代码的某些部分是否手动抛出 bad_alloc 也是一个好主意。