Remote-Prozess wird auf mysteriöse Weise getötet

Question

Ich führe einen Remote-Prozess mit PowerShell und es scheint nach ein paar Minuten spurlos getötet zu werden.

Der Befehl Ich verwende folgt:

$command = {Start-Process -NoNewWindow -Wait -FilePath $filepath -ArgumentList $args} 
Invoke-Command -Session $MyPSSession -ScriptBlock $command 

Während Fern desktopping die Maschine, schaue ich auf den Task-Manager: Der Prozess ist in der Liste aus und nimmt so viel Speicher und CPU-Ressourcen wie gewohnt (dh als ob ich denselben Befehl direkt an der Maschine ausgeführt hätte anstatt Invoke-Command), aber nach 3 bis 6 Minuten stoppt der Prozess ohne jede Spur.

Gibt es eine Möglichkeit, dieses Verhalten zu verhindern? Mein Prozess sollte im Durchschnitt eine lange Zeit (mehr als 10 Minuten) dauern und wird sowieso getötet.

Edit 1: Alles klar, also habe ich dieses Problem mit Procmon gelöst und es scheint, als ob der Prozess kurz vor dem Absterben einen Exit-Code 3 startet. Ich habe nachgeschlagen und es ist "System konnte Pfad nicht finden". Es ist wieder mysteriös, weil das Ausführen des Prozesses direkt auf der Maschine keinen solchen Beendigungscode auslöst.

... Dann würde es einen Weg geben zu wissen, welchen Weg der Prozess gesucht hat?

Edit 2: Es gibt in der Tat eine Möglichkeit zu wissen, auf welchen Pfad der Prozess nicht zugreifen konnte, aber in meinem Fall gibt es Tausende (!!!) von Ereignissen protokolliert von procmon, die das Ergebnis "NAME NICHT GEFUNDEN" bei der Operation hatte "RegOpenKey" und so. Auch scheint es, wie meine Remote-Computer eine harte Zeit mit der Funktion Create hat, die immer „FILE MIT NUR DIE LESER LOCKED“ zurückzukehren, ganz gleich, welche DLL es versucht, zu „Karte“ ...

Bearbeiten 3: I fand heraus, dass das Betreten der Sitzung, die vorher erstellt wurde und dann den Prozess ausführte, das Verhalten änderte, aber der Prozess noch einige Zeit nach dem Start getötet wird, dieses Mal mit einem Exit-Code '-1073741819' ... der "Zugriff verweigert" ist. Wird weiter untersuchen.

Edit 4: Auf dem Remote-Computer war die PS-Version 2.0. Auf meiner Arbeitsstation war die PS-Version 5.0. Ich installierte Service Pack 1, .NET Framework 4.5.2 und WMF 5.0 (enthält PowerShell 5.0). Bis heute funktionierte der Prozess gut und starb nicht auf mysteriöse Weise, aber jetzt spuckt er nach einigen Sekunden einen Exit-Code 3 aus. Ich habe versucht, eine andere App auf meinem Remotecomputer auszuführen: Ich habe es fertiggestellt und die Ergebnisse ausgegeben, auch wenn der Vorgang länger dauerte als diese paar Sekunden. "Dann muss es die App sein!" Ich habe mir gesagt ... nein! Wenn ich die gleiche App mit den gleichen Parametern von der VM auf meine Workstation laufe, funktioniert es gut. "Es muss dann die entfernte Maschine sein!" ... ja, darüber. Wie kann ich die Unterschiede zwischen diesen beiden Computern erkennen und den Remote-Computer reparieren, damit ich meine App von meinem Arbeitsplatz aus starten kann?

Answer 1

Auf dem Remote-Computer war die PS-Version 2.0. Auf meiner Arbeitsstation war die PS-Version 5.0. Ich installierte Service Pack 1, .NET Framework 4.5.2 und WMF 4.0 (einschließlich PowerShell 4.0) auf dem Remotecomputer, und dann startete ich meinen Prozess remote von meiner Arbeitsstation und es ist gesünder als je zuvor.

Fazit: Die Verwendung von PowerShell 2.0 für Remoting ist keine gute Lösung für langfristige Prozesse und wird sicherlich später zu Problemen führen, insbesondere wenn auf dem empfangenden Rechner eine ältere Version von PS läuft.

Lektion der Woche: Aktualisieren Sie Ihre Sachen, Leute.