我有一個腳本，在此代碼失敗，與-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退出代碼，並在比賽中。所以，我把我的工作代碼，硬編碼變量和所有變量粘貼到原始腳本中，並再次打破。 因此，我將代碼從它所屬的函數中移出，並在初始化所有內容之後並在開始通過主循環之前將其放入。它在那裏工作！現在，我必須相信這是通常的「污染管道」，但是如果我能弄清楚可能會導致這種情況的話。我想下一步就是開始單步執行代碼，將這個塊放在某個地方，運行測試，如果它有效，將它向下移動，再試一次。 GACK！所以，跳躍的人有一些見解。不管它是什麼，或者是一個改進的測試協議。或者有些訣竅可以看到整個管道，並以某種方式識別污染。
FWIW，我通常與PoSH v2一起工作，但我已經用v4嘗試過，結果完全相同。但是在更高版本中可能有一些管道監視功能可以幫助解決問題？
此外，我的理解是，PoSH v2有負面的返回碼的問題，所以他們不能被信任。但我認爲新版本解決了這個問題，對嗎？因此，我在v4中獲得相同的代碼意味着它對Google有意義嗎？並不是說我到目前爲止在任何地方都找不到任何退出代碼的暗示。
交叉的手指。
編輯：好的，多一點數據。我在沒有 - 的情況下搜索了退出代碼，並用DuckDuckGo代替Google搜索，並找到了它。 0x8024001E -2145124322 WU_E_SERVICE_STOP由於服務或系統正在關閉，操作未完成。 好的，這是一些方向。而且我有一些代碼可以讓我暫時殺死一個服務。但那似乎有點嚴厲。這是不是完整的點，就像第十種安裝微軟更新的方式一樣，應該是讓自動化更容易？無論如何，我找不到任何跡象表明WUSA有命令行標誌可以避免這個問題，但我必須相信我做錯了什麼。