污染管道故障排除

Question

我有一个脚本，其中此代码失败，退出代码为 -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 行“正在发生的其他事情”，而这些行最初并不完全像这样。变量是从 XML 中提取的，有数据验证和 try/catch 块，各种各样的东西。所以，我开始把相关的线拉出来，把它们放在一个单独的小脚本中，并对变量进行硬编码。在那里，它起作用了，我得到了一个不错的 3010 退出代码并开始比赛。所以，我把我的工作代码、硬编码的变量和所有的东西都粘贴回了原来的脚本中，它又坏了。 因此，我将代码从它所属的函数中移出，并在初始化所有内容之后以及开始执行主循环之前将其放入。它在那里工作！现在，我必须相信这是通常的“污染管道”，但如果我能找出可能导致这种情况的原因，那该死的。我想我的下一步是开始单步执行代码，将这个块放在某个地方，运行测试，如果它有效，将它向下移动，再试一次。盖克！ 因此，跳跃某人有一些见解。可能是什么，或者可能是改进的测试协议。或者一些技巧来实际查看整个管道并以某种方式识别污染。

FWIW，我通常使用 PoSH v2，但我已经尝试使用 v4，结果完全相同。但也许在以后的版本中有一些管道监控功能可以帮助解决问题？

另外，我的理解是 PoSH v2 存在负返回码的问题，因此它们不能被信任。但我认为较新的版本解决了这个问题，对吗？那么我在 v4 中获得相同代码的事实意味着它对 Google 有意义吗？并不是说到目前为止我在任何地方都发现了该退出代码的任何提示。

交叉手指。

编辑：好的，多一点数据。我搜索了没有 - 的退出代码，并使用 DuckDuckGo 而不是谷歌，并找到了这个。 0x8024001E -2145124322 WU_E_SERVICE_STOP 操作未完成，因为服务或系统正在关闭。 好的，这是一些方向。而且我有一些代码可以让我暂时终止服务。但这似乎有点严厉。这难道不是重点，就像从微软安装更新的第十种方式，应该是为了让自动化更容易吗？无论如何，我找不到任何迹象表明有 WUSA 的命令行标志可以避免这个问题，但我必须相信我做错了什么。

Answer 1

解决了！在跟踪了许多不同的错误尝试不同的事情之后，包括关闭防火墙等，结果发现错误不是服务不会停止，而是服务不会启动。看，这 15K 行代码中的一些在我的脚本期间抑制了 Windows 更新，因为 Windows 更新导致许多 Autodesk 部署失败，这就是我的代码的重点。好吧，WUSA 当然需要这项服务。因此，看起来，与其在脚本执行期间抑制 Windows 更新，我需要不那么笨拙，只在部署任务期间抑制。这将需要几个小时来实施和测试，但完全可行。无论如何，可能更优雅。哇！

是的，这一次不是我无意中在管道中大便。 ;)