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

这个简单的批处理文件以相对较短的顺序使用Windows 7（x64）上的所有可用内存。发生什么事？我们可以采取什么预防措施来预防它

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

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

• 插入符号

  ^

  是文件中的最后一个内容，脚本不会以换行符结尾
• 插入符号前面至少有2个空格或字符，例如，如果下面的点表示空格，则不会触发内存泄漏

  ^

  ，而这一个将

  。^

  （只是缓慢）

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

如果要尝试此操作，请确保可以使用关闭窗口[X]控件，或者启动任务管理器或Process Explorer，并准备就绪，因为Ctrl-C、Ctrl-Break、Alt-F4无效

多个插入符号似乎会导致内存使用率更快地增加。我第一次遇到这种情况时，在1到2分钟内没有足够的内存来做一些简单的事情，比如Alt Tab，甚至连3个手指的敬礼Ctrl-Alt-Del都没有效果。我不得不硬关机。

造成这种情况的原因（据我所知）是由于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编码

---

这不是一个bug，而是一个功能。不，我收到两条错误消息（XP）：

以下字符串太长

&

语法错误

（翻译）在那之后，脚本终止了。我添加了标签：因为这可能会被恶意使用，而不会引起太大的麻烦。不确定这是否是对该标签的不当使用；如果是的话，请删除。我可以想象地球上成千上万的人在同事的机器上运行它，当他们将其解锁时……只需打开一个cmd窗口，执行e、 最小化窗口并走开..在Windows 10中修复。感谢扩展的试用信息和可能的解释。我没有想到测试编码。第一个预防措施的另一种措辞可能是“始终以空行结束”“，这是stock notepad.exe在我记忆中所做的事情。也许这就是原因之一；-）@谢谢，我最喜欢你的措辞。“始终以空行结尾”

：）

事实证明，这实际上是命令行解析器中的一个错误，以及它如何解析批处理文件。更具体地说，逻辑错误；如果插入符号位于EOF，则实际EOF将被“忽略”和“跳过”，将文件句柄重置为0，从而重新设置脚本的版本。有关这一切的更多信息，请参见我的详细问题：@txtechhelp+1这个问题的详细分析。对于任何对此问题背后的内部工作方式感兴趣的人，建议阅读。@txtechhelp这是您的问题的一部分，因为原始问题已被删除。