污染管道故障排除

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中提取的，有数据验证和尝试/捕捉块之类的东西。因此，我开始抽出相关的行，并将它们放在一个很小的独立脚本中，并对变量进行硬编码。在那里，它的工作，我得到了一个不错的3010出口代码和出发的比赛。所以，我把我的工作代码，硬编码的变量和所有的，并粘贴回原来的脚本，它再次崩溃。因此，我将代码从它所属的函数中移出，并将其放在初始化所有内容之后，然后再开始执行主循环。它就在那儿工作！现在，我得相信这是通常的“污染管道”，但如果我能找出原因的话，那就糟了。我猜我的下一步就是开始执行代码，把这个核心元素放到某个地方，运行测试，如果它工作得更深入，再试一次。盖克！所以，跳一个人有一些洞察力。或者它可能是什么，或者是一个改进的测试协议。或者是某种诡计，让我们看到整个管道，并以某种方式认识到污染。

FWIW，我通常与PoSH v2一起工作，但我用v4进行了尝试，结果完全相同。但是，也许在以后的版本中有一些管道监视功能可以帮助排除故障呢？

另外，我的理解是，PoSH v2存在负返回码的问题，因此不能信任它们。但我认为新版本解决了这个问题，对吧？所以，我在v4中得到了相同的代码，这对谷歌来说是有意义的吗？到目前为止，我并没有发现任何关于退出代码的提示。

祝你好运。

编辑:好的，更多一些数据。我在没有-的情况下搜索了退出代码，使用了DuckDuckGo而不是Google，并找到了这个。由于服务或系统被关闭，0x8024001E-2145124322 WU_E_SERVICE_STOP操作没有完成。 OK，这是一个方向。我有一些代码可以让我暂时终止一项服务。但这似乎有点严厉。这样做的全部目的，就像第10种安装微软更新的方式，难道不是为了让自动化变得更容易吗？在任何情况下，我都找不到任何指示WUSA的命令行标志可以避免这个问题，但我必须相信我做错了什么。

Answer 1

解决了！在跟踪了许多不同的错误之后，尝试了不同的事情，包括关闭防火墙等等，结果发现错误不是服务不会停止，而是服务不会启动。请注意，在我的脚本期间，其中一些15K行代码会抑制Windows，因为Windows会导致很多Autodesk部署失败，这就是我的代码的全部要点。当然，WUSA需要这种服务。因此，看起来，与其在脚本执行期间禁用Windows，我还需要更少的手工操作，并且只在部署任务的持续时间内进行抑制。这将需要几个小时来实现和测试，但是完全可行的。也许还会更优雅。哇哦！

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