Windows批处理文件末尾的简单插入符号（^）占用所有内存

Question

这个简单的批处理文件以相对较短的顺序消耗Windows 7（x64）上的所有可用内存。这是怎么回事？并采取什么预防措施来抵御它？

any-invalid-command-you-like-here ^

显示效果的显然必要的先决条件：

• 插入符号^是文件中最后一个，并且脚本不以换行符终止
• 插入符号前面至少有2个空格或字符，例如如果下面的点代表空格，则不会触发内存泄漏.^，而此内容将..^（只是缓慢地）

在这个 Process Explorer 屏幕截图中，脚本运行了大约30秒，消耗了2.9GB，并且仍然以稳定的速度攀升：

如果您要对此进行实验，请确保您可以进入关闭窗口[X]控件或启动任务管理器或进程资源管理器并准备为 Ctrl-C ， Ctrl-Break ， Alt-F4 无效。

看起来多个插入符将导致内存使用量增加得更快。我第一次遇到这个时，在1或2分钟内没有足够的内存来做简单的事情，比如 Alt-Tab 甚至3手指致敬 Ctrl-Alt-Del 无效。我不得不把电脑硬起来。

Answer 1

思想

原因（根据我的理解）是由于cmd解释器正在寻找要逃脱的角色，因为^是批量转义字符。在这种情况下，cmd只是在寻找要逃脱的角色时保持循环和初始化，而不是正确识别文件的末尾eof。

在带有cc^^^的Windows 8 Pro（64）上重现（多个克拉用于加速泄漏）。

试验

cc^无限循环并且泄漏非常缓慢。

cc^^因正常的无效命令错误而崩溃。

cc^^^无限循环并且泄漏速度更快。

cc ^无限循环并且泄漏非常缓慢。

cc ^^因正常的无效命令错误而崩溃。

cc ^^^无限循环并且泄漏速度更快。

cc"^因正常的无效命令错误而崩溃。

cc"^^因正常的无效命令错误而崩溃。

cc"^^^因正常的无效命令错误而崩溃。

注释

• 当按字面意思（在引用之外）使用克拉^时，只有无限循环和泄漏。添加引号时，脚本会因标准无效命令错误而崩溃。
• 批处理文件编码为 UTF-8 或 ASCII 时，只有无限循环和泄漏。当 UTF-16 时，脚本会因标准无效命令错误而崩溃。
• 必须是奇数克拉才能逃脱最后一颗克拉。

注意事项

• 确保没有批处理脚本以克拉^（0x5E）或至少奇数克拉结束。
• 或以UTF-16编码。