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 甚至是三指敬礼 Ctrl-Alt-Del 无效。我不得不硬关闭机器。

Answer 1

想法

原因（据我了解）是由于 cmd 解释器正在寻找要转义的字符，因为 ^ 是批处理转义字符。在这种情况下，cmd 没有正确识别文件 eof 的结尾，而是在寻找要转义的字符时不断循环和初始化一些东西。

在 Windows 8 Pro (64) 上使用cc^^^ 复制（多个插入符号用于加速泄漏）。

试验

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

cc^^ 崩溃并出现正常的无效命令错误。

cc^^^ 无限循环和泄漏更快。

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

cc ^^ 崩溃并出现正常的无效命令错误。

cc ^^^ 无限循环和泄漏更快。

cc"^ 崩溃并出现正常的无效命令错误。

cc"^^ 崩溃并出现正常的无效命令错误。

cc"^^^ 崩溃并出现正常的无效命令错误。

注意事项

• 只有在字面上使用插入符号^（在引号之外）时才会出现无限循环和泄漏。添加引用时，脚本会因标准无效命令错误而崩溃。
• 当批处理文件被编码为 UTF-8 或 ASCII 时，只有无限循环和泄漏。当 UTF-16 时，脚本会因标准无效命令错误而崩溃。
• 必须是奇数个插入符号，以免漏掉最后一个插入符号。

注意事项

• 确保没有批处理脚本以插入符号 ^ (0x5E) 或至少奇数个插入符号结尾。
• 或将它们编码为 UTF-16。