windows - 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 编码。