污染管道故障排除
Polluted pipeline troubleshooting
我有一个脚本，其中此代码失败，退出代码为 -2145124322
$new.ExitCode > $null
$filePath = "wusa.exe"
$argumentList = "`"\PX_SERVER\Rollouts\Microsoft\VirtualPC\Windows6.1-KB958559-x64-RefreshPkg.msu`" /quiet /norestart"
$exitCode = (Start-Process -FilePath:$filePath -argumentList:$argumentList -wait -errorAction:Stop -PassThru).ExitCode
Write-Host $exitCode
现在，主脚本有大约 15,000 行 "other stuff going on"，而这些行与原来完全不同。变量是从 XML 中提取的，有数据验证和 try/catch 块，各种各样的东西。所以，我开始提取相关的代码行，将它们放在一个单独的小脚本中，并对变量进行硬编码。在那里，它起作用了，我得到了一个很好的 3010 退出代码，然后开始比赛。所以，我把我的工作代码、硬编码变量和所有的东西都粘贴回原来的脚本，它又坏了。
因此，我将代码从它所属的函数中移出，并在我初始化所有内容之后和开始执行主循环之前将其放入。在那里它起作用了！现在，我必须相信这是通常的 "polluted pipeline"，但如果我能弄清楚是什么原因导致的，该死的。我想我的下一步是开始单步执行代码，将这个块放在某个地方，运行 测试，如果它有效，请将其向下移动，再试一次。嘎嘎！
所以，跳槽某人有一些见解。它可能是什么，或者可能是改进的测试协议。或者一些技巧来实际看到整个管道并以某种方式识别污染。
FWIW，我通常使用 PoSH v2，但我用 v4 尝试过，结果完全相同。但也许更高版本中有一些管道监控功能可以帮助排除故障？
此外，我的理解是 PoSH v2 存在负 return 代码的问题，因此它们不可信任。但我认为较新的版本解决了这个问题，对吗？所以我在 v4 中得到相同的代码意味着它对 Google 有意义吗？并不是说到目前为止我在任何地方都发现了该退出代码的任何提示。
十指交叉。
编辑：好的，多一点数据。我搜索了没有 - 的退出代码，并使用 DuckDuckGo 而不是 Google，找到了这个。
0x8024001E -2145124322 WU_E_SERVICE_STOP操作未完成，因为服务或系统正在关闭。
好的，这是一些方向。我有一些代码可以让我暂时终止服务。但这似乎有点严厉。这一切的重点，就像从 Microsoft 安装更新的第 10 种方式，不应该是为了让自动化更容易吗？无论如何，我找不到任何迹象表明 WUSA 的命令行标志可以避免这个问题，但我不得不相信我做错了什么。
已解决！在尝试不同的事情（包括关闭防火墙等）跟踪了许多不同的错误之后，结果证明错误不是服务不会停止，而是服务不会启动。看，这 15K 行代码中的一些代码在我的脚本持续时间内抑制了 Windows 更新，因为 Windows 更新导致许多 Autodesk 部署失败，这就是我的代码的全部意义所在。好吧，WUSA 当然需要这项服务。因此，看起来，与其在脚本执行期间抑制 Windows 更新，我需要不那么粗暴，只在部署任务期间抑制。这将需要几个小时来实施和测试，但完全可行。而且可能更优雅。哇！
是的，这一次不是我无意中在我的管道中大便。 ;)
我有一个脚本，其中此代码失败，退出代码为 -2145124322
$new.ExitCode > $null
$filePath = "wusa.exe"
$argumentList = "`"\PX_SERVER\Rollouts\Microsoft\VirtualPC\Windows6.1-KB958559-x64-RefreshPkg.msu`" /quiet /norestart"
$exitCode = (Start-Process -FilePath:$filePath -argumentList:$argumentList -wait -errorAction:Stop -PassThru).ExitCode
Write-Host $exitCode
现在，主脚本有大约 15,000 行 "other stuff going on"，而这些行与原来完全不同。变量是从 XML 中提取的，有数据验证和 try/catch 块，各种各样的东西。所以，我开始提取相关的代码行，将它们放在一个单独的小脚本中，并对变量进行硬编码。在那里，它起作用了，我得到了一个很好的 3010 退出代码，然后开始比赛。所以，我把我的工作代码、硬编码变量和所有的东西都粘贴回原来的脚本，它又坏了。 因此，我将代码从它所属的函数中移出，并在我初始化所有内容之后和开始执行主循环之前将其放入。在那里它起作用了！现在，我必须相信这是通常的 "polluted pipeline"，但如果我能弄清楚是什么原因导致的，该死的。我想我的下一步是开始单步执行代码，将这个块放在某个地方，运行 测试，如果它有效，请将其向下移动，再试一次。嘎嘎！ 所以，跳槽某人有一些见解。它可能是什么，或者可能是改进的测试协议。或者一些技巧来实际看到整个管道并以某种方式识别污染。
FWIW，我通常使用 PoSH v2，但我用 v4 尝试过，结果完全相同。但也许更高版本中有一些管道监控功能可以帮助排除故障？
此外，我的理解是 PoSH v2 存在负 return 代码的问题，因此它们不可信任。但我认为较新的版本解决了这个问题，对吗？所以我在 v4 中得到相同的代码意味着它对 Google 有意义吗？并不是说到目前为止我在任何地方都发现了该退出代码的任何提示。
十指交叉。
编辑：好的，多一点数据。我搜索了没有 - 的退出代码，并使用 DuckDuckGo 而不是 Google，找到了这个。 0x8024001E -2145124322 WU_E_SERVICE_STOP操作未完成，因为服务或系统正在关闭。 好的，这是一些方向。我有一些代码可以让我暂时终止服务。但这似乎有点严厉。这一切的重点，就像从 Microsoft 安装更新的第 10 种方式，不应该是为了让自动化更容易吗？无论如何，我找不到任何迹象表明 WUSA 的命令行标志可以避免这个问题，但我不得不相信我做错了什么。
已解决！在尝试不同的事情（包括关闭防火墙等）跟踪了许多不同的错误之后，结果证明错误不是服务不会停止，而是服务不会启动。看，这 15K 行代码中的一些代码在我的脚本持续时间内抑制了 Windows 更新，因为 Windows 更新导致许多 Autodesk 部署失败，这就是我的代码的全部意义所在。好吧，WUSA 当然需要这项服务。因此，看起来，与其在脚本执行期间抑制 Windows 更新，我需要不那么粗暴，只在部署任务期间抑制。这将需要几个小时来实施和测试，但完全可行。而且可能更优雅。哇！
是的，这一次不是我无意中在我的管道中大便。 ;)