调用 exe 后批处理脚本错误退出答案

【问题标题】：Batch script incorrectly exits after call to exe调用 exe 后批处理脚本错误退出
【发布时间】：2014-11-26 16:42:06
【问题描述】：

好吧，我有一个名为 WC_Error_Resolution 的程序，它是用 C# 编写的（带有 .NET 4.0 的 C# 控制台应用程序）。该程序根据运行程序时所做的操作返回 0、1 或 2。如果我从 cmd.exe 调用它，一切正常。但是，这是我感到困惑的地方。我有一个测试批处理脚本（真正的要大得多），它的名称如下：

    ECHO Start
    WC_Error_Resolution.exe file1.xml file2.xml inifile.ini log1.log log2.log
    ECHO ERRORLEVEL=%ERRORLEVEL%

这里的问题是第二个回显永远不会被执行。脚本到达程序的第二个，它调用它并退出批处理脚本。然后我决定试试：

    ECHO Start
    START /B /WAIT "" WC_Error_Resolution.exe file1.xml file2.xml inifile.ini log1.log log2.log
    ECHO ERRORLEVEL=%ERRORLEVEL%

这一次，它按预期工作。我已经创建了大量的批处理脚本，它们像第一个示例一样调用 .exe 文件，并且从未遇到过这样的问题。什么会导致 WC_Error_Resolution.exe 程序返回后脚本停止执行？

编辑
-------------------------------------------------- ---
所以现在这出现在我的另一个程序中。这两个程序都引用了System.Xml.Linq。这些程序可以在 Windows 7、Windows 8 和 Windows Server 2012 R2 上编写脚本。这些程序无法在 Windows Server 2008 R2 上执行，并且没有显示任何错误。该脚本根本不会执行程序调用下面的程序或命令。快速说明，这是一个 32 位程序，在启用了 WoW64 的 64 位环境中运行。在 Windows Server 2008 R2 上运行的 .NET 应用程序是否存在一些我不知道的问题？

【问题讨论】：

您的 WC_Error_Resolution.exe 应用程序是 32 位还是 64 位控制台应用程序？为什么第二批使用/B？ main() 中的 return 0;（或 1 或 2）是否正确退出控制台应用程序？在 Visual Studio 中以调试模式运行您的应用程序并检查它是如何真正退出的。
项目的构建属性将目标平台指定为“Any CPU”。我应该改为将其更改为 x86 吗？我使用 /B 是因为对 exe 的调用是更大脚本的一部分，所以我不希望在执行期间出现第二个窗口。应用程序正常运行，并在没有任何更改时退出代码 0，在更改特定文件时退出代码 1，在出错时退出代码 2。在 VS 中运行良好。当我像第一个示例一样编写脚本时，不会执行第二个回显，但是如果我在脚本返回后在命令行上输入ECHO ERRORLEVEL=%ERRORLEVEL%，我会得到正确的退出代码。
请参阅What does the Visual Studio “Any CPU” target mean? 使用 x86 配置显式构建您的控制台应用程序，并测试这是否有所作为。
我会向您推荐stackoverflow.com/questions/516730/…，了解“任何 CPU”的含义。基于此，我预计执行行为不会有任何差异，但会试一试并返回结果。
start /B /W "" 将CREATE_NEW_PROCESS_GROUP 添加到进程创建标志中。在 64 位 Windows 7 中，当我在运行 C:\Windows\System32\where.exe 作为测试用例时比较两种情况下传递给 CreateProcessW 的参数时，这是我看到的唯一主要区别。如果您删除 /B 选项（如有必要，请在末尾添加 pause），它是否会在新窗口中正确回显？

标签： c# windows batch-file cmd windows-server-2008-r2

【解决方案1】：

这在问题的答案中得到了回答（通过使用 C++ 示例）：

How do I get the application exit code from a Windows command line?

如果程序从控制台分离，那么批处理文件会在程序运行时继续运行，START /B /WAIT 是获取errorlevel 的正确解决方法。如果您看不到 C# 程序与控制台分离的原因，您可能想根据 C# 程序的提取提出另一个问题。

【讨论】：

这不再是一个问题，因为我们已经改变了流程来解决它。但是，我会说链接的答案虽然有用，但不一定适用，因为被调用的程序是控制台程序。除非这同样适用于 c# 控制台应用程序。
是的：控制台应用程序可以分离控制台，并且可以使用窗口，您的应用程序可能就是这种情况，这就是我做笔记的原因。
如果是这样的话，你认为这个问题会出现在机器上吗？它只发生在我同事的机器上。