Silent Process Exit: Prozess '?' wurde durch den Prozess 'C: \ Windows \ System32 \ svchost.exe' mit dem Beendigungscode 1067 beendet

857
nietras

Wir haben ein schwerwiegendes Problem mit einer C # -Anwendung, die bei einer Windows 10 32-Bit-Installation zu zufälligen und seltenen Zeitpunkten stumm beendet wird. Es kann zB ein Monat zwischen den Vorkommen sein. Oder manchmal nur einen Tag.

Grundlegende Systemspezifikationen:

Microsoft Windows 10 Enterprise 2016 LTSB Version 10.0.14393 Build 14393 32-bit 

Mithilfe von https://docs.microsoft.com/de-de/windows-hardware/drivers/debugger/setting-and-clearing-flags-for-silent-process-exit haben wir die Überwachung des Prozessausgangs ohne Ende konfiguriert. Und wir haben endlich ein paar Beispiele davon:

The process 'APPLICATIONPATH\APPLICATIONNAME.exe' was terminated by  the process 'C:\Windows\System32\svchost.exe' with termination code 1067.  The creation time for the exiting process was 0x01d43bd8689073eb. 

Bei der Suche nach den Dumps, die für die Überwachung eingerichtet wurden, haben wir eine Prozess-ID für den svchost erhalten. Dieser Dienst wurde noch auf dem System ausgeführt und zeigt die folgende Liste von Diensten:

Dienstleistungen

Was scheint eine Liste von "Netsvcs" für Windows zu sein. Beim Öffnen des Dumps wurde svchost.exeein einzelner Thread mit einem interessanten Aufrufstapel gefunden:

ntdll.dll!_KiFastSystemCallRet@0 () ntdll.dll!_NtWaitForSingleObject@12 () ntdll.dll!RtlReportSilentProcessExit() KERNELBASE.dll!TerminateProcess() ubpm.dll!_UbpmpTerminateProcessCallback@12 () ubpm.dll!UbpmUtilsTimerCallback() ntdll.dll!TppTimerpExecuteCallback() ntdll.dll!TppWorkerThread() kernel32.dll!@BaseThreadInitThunk@12 () ntdll.dll!__RtlUserThreadStart() ntdll.dll!__RtlUserThreadStart@8 () 

UBPM ist der Unified Background Process Manager. Aber wie kann dies unsere Bewerbung beenden? Und warum? Und was 1067sagt uns der Beendigungscode ?

Unten ist der Protokolleintrag von Silent Process Monitoring:

Log Name: Application Source: Microsoft-Windows-ProcessExitMonitor Date: 2018-08-31 15:26:09 Event ID: 3001 Task Category: None Level: Information Keywords: Classic User: SYSTEM Computer: PC Description: The process 'APPLICATIONPATH\APPLICATIONNAME.exe' was terminated by the process 'C:\Windows\System32\svchost.exe' with termination code 1067. The creation time for the exiting process was 0x01d43ed2aee892ab. Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-ProcessExitMonitor" Guid="" EventSourceName="Process Exit Monitor" /> <EventID Qualifiers="16384">3001</EventID> <Version>0</Version> <Level>4</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2018-08-31T13:26:09.988216500Z" /> <EventRecordID>4853</EventRecordID> <Correlation /> <Execution ProcessID="0" ThreadID="0" /> <Channel>Application</Channel> <Computer>PC</Computer> <Security UserID="S-1-5-18" /> </System> <EventData Name="EVENT_PROCESSTERMINATION_CROSSPROCESS"> <Data Name="param1">APPLICATIONPATH\APPLICATIONNAME.exe</Data> <Data Name="param2">C:\Windows\System32\svchost.exe</Data> <Data Name="param3">1067</Data> <Data Name="param4">01d43ed2aee892ab</Data> </EventData> </Event> 

HINWEISE: Der PC wird zum Zeitpunkt, an dem die App beendet wird, weder heruntergefahren, noch gibt es in den Ereignisprotokollen weitere Hinweise, warum der Prozess beendet wurde.

UPDATE 1: Hier ein paar zusätzliche Details (versuchen, so viele wie in Kommentaren zu beantworten):

  • Prozess wird (manchmal) über TaskScheduler gestartet, wenn Windows gestartet wird. Ja. Andere Zeiten vom Benutzer. Ein nicht ganz sicheres Problem tritt nur auf, wenn es über TaskScheduler gestartet wird. Aber interessanter Punkt? Könnten Fenster eine Aufgabe aus irgendeinem Grund töten? Beachten Sie, dass die Zeit zwischen dem Beenden eines Prozesses bis zu einem Monat betragen kann.
  • Wir haben die Quelle für das Hauptprogramm, hätten aber Probleme, es in einem Debugger auszuführen, da dies bei einem Kunden läuft, aber vielleicht. Wir können es jedoch nicht für Debug kompiliert ausführen. Überhaupt nicht wegen der Leistung. Das ist Live-Produktion.
  • Anwendung ist eine normale WPF-Anwendung ohne untergeordnete Prozesse oder andere Kommunikation zwischen Prozessen. Es verwendet einige Geräte von Drittanbietern, z. B. Bibliotheken und Treiber.
  • Wir haben die Ereignisbehandlung für Appdomain-Ausnahmen und Anwendungsausnahmen usw. eingerichtet. Keines davon tritt auf. Der Prozess wird beendet, ohne dass eine Ausnahme angezeigt wird. Es ist ein harter Prozessausstieg.
  • Wir haben vermutet, dass ein Treiber von Drittanbietern die Quelle ist, aber wie? Und wie können wir feststellen, ob dies der Fall war?

UPDATE 2: Wir verwenden das Paket nuget, TaskSchedulerum die Aufgabe über Code einzurichten . Beachten Sie, dass wir das ExecutionTimeLimit nicht festlegen. Daher sollte Nothing und damit unendlich sein.

using (TaskService m_service = new TaskService()) { var task = m_service.NewTask();  task.Principal.UserId = userId; task.Principal.LogonType = TaskLogonType.InteractiveToken; task.Principal.RunLevel = TaskRunLevel.Highest;  task.Settings.Enabled = true; task.Settings.MultipleInstances = TaskInstancesPolicy.IgnoreNew; task.Settings.Hidden = false;  // NOTICE: A subset of the following 4 settings will cause app to hang on Win10 //task.Settings.AllowHardTerminate = true; //task.Settings.DisallowStartOnRemoteAppSession = false; //task.Settings.RunOnlyIfLoggedOn = true;  var trigger = (LogonTrigger)task.Triggers.Add(new LogonTrigger()); trigger.Enabled = true; trigger.UserId = userId;  task.Actions.Add(new ExecAction(executableFilePath, arguments: null, workingDirectory: m_installDirectoryPath));  if (!IsAdministrator()) { var message = "Cannot register task with your current identity's permissions level."; m_logger.Error(message); } m_service.RootFolder.RegisterTaskDefinition(taskName, task, TaskCreation.Create, userId, password: null, logonType: TaskLogonType.InteractiveToken); } 

UPDATE 3: Vielleicht war die obige Aussage falsch, der Standard in der TaskSchedulerBibliothek scheint 3 Tage oder 72 Stunden zu sein.

// // Summary: // Gets or sets the amount of time that is allowed to complete the task. By default, // a task will be stopped 72 hours after it starts to run. // // Remarks: // If a task is started on demand, the ExecutionTimeLimit setting is bypassed. Therefore, // a task that is started on demand will not be terminated if it exceeds the ExecutionTimeLimit. [DefaultValue(typeof(TimeSpan), "3")] public TimeSpan ExecutionTimeLimit { get; set; } 

UPDATE 4: Die einzige Sache ist, dass wir stille Prozess-Exits beobachten, nachdem der Prozess viel länger als 3 Tage ausgeführt wurde, z. B. 30 Tage.

UPDATE 5: Der Zeitraum von mehr als 3 Tagen wurde nicht korrekt beachtet. Nach allem, was jetzt klar ist, lag dies an falschen Einstellungen für die Taskplaner-Task. Die falschen Einstellungen werden unten gezeigt:

Falsche Einstellungen für den Taskplaner

Richtige Einstellungen sind:

Richtige Einstellungen für den Aufgabenplaner

0
Bei stackoverflow gibt es ein ähnliches Problem, aber dies scheint eher ein Windows-Problem zu sein: https://stackoverflow.com/questions/16992011/why-is-svchost-exe-terminating-my-c-sharp-application nietras vor 5 Jahren 0
Anmerkung: Beendigungscode 1067 [bedeutet] (https://docs.microsoft.com/de-de/windows/desktop/debug/system-error-codes--1000-1299-) "ERROR_PROCESS_ABORTED - Der Prozess wurde unerwartet beendet". Nicht sehr hilfreich und sagt nichts aus. harrymc vor 5 Jahren 0
Anmerkung 2: Es kann sinnvoll sein, die gebündelten Dienste von svchost wie hier beschrieben zu trennen (https://superuser.com/a/1192108/8672). harrymc vor 5 Jahren 0
@ harrymc Anmerkung 2: Ja, wir haben das bereits getan und warten auf den nächsten Anlass, aber einen guten Vorschlag. nietras vor 5 Jahren 0
@ harrymc Anmerkung: Ja, das ist alles was wir auch auf 1067 finden konnten. Hatte gehofft, es könnte auf etwas hindeuten ... nietras vor 5 Jahren 0
Anmerkung 3: Sie können alle Ereignisanbieter von UBPM über Systemmonitor> Datensammlersätze> Ereignisablaufverfolgungssitzungen anzeigen. Doppelklicken Sie auf UBPM und dann auf die Registerkarte Ablaufverfolgungsanbieter. Wenn Sie die Liste überprüfen, erhalten Sie möglicherweise eine Vorstellung von einem Ereignis, von dem Ihr Programm abhängig ist, oder von einem möglichen Konflikt. Mein eigener Verdacht ist, dass der Stack-Trace, den Sie erhalten haben, nur die Verarbeitung des Ereignisses Ihrer Programmbeendigung ist, also keine besondere Bedeutung oder Information hat. harrymc vor 5 Jahren 0
Frage: Haben Sie die Quellen des Programms und können es in einem Debugger ausführen? harrymc vor 5 Jahren 0
Wird dieser Prozess durch eine geplante Aufgabe gestartet? apocalysque vor 5 Jahren 0
Ich habe versucht, der obigen Frage unter Update 1 weitere Informationen hinzuzufügen. Und dies wird beim Start von Windows mit einer Task gestartet. Ideen? @apocalysque nietras vor 5 Jahren 0
Können Sie Screenshots der geplanten Aufgabe posten? apocalysque vor 5 Jahren 0
@apocalysque Ich habe einen Code angehängt, der zeigt, wie wir den Taskplaner einrichten. ExecutionTimeLimit sollte Nothing und somit unendlich sein. nietras vor 5 Jahren 0
@apocalysque Tatsächlich könnte das falsch sein, da das Nuget-Paket einen Standardwert von 72 Stunden zu haben scheint! Also könnten wir uns tatsächlich auf etwas einlassen! nietras vor 5 Jahren 0
siehe Updates in Frage. nietras vor 5 Jahren 0
Können Sie den Start der Anwendung testen, ohne dass der Task-Manager beteiligt ist, um zu sehen, ob die Anwendung trotzdem abstürzt? apocalysque vor 5 Jahren 0

2 Antworten auf die Frage

0
harrymc

Ich denke, dass die Informationen, die Sie in Ihrem Posting zur Verfügung stellen, alle von der Tatsache abhängen.

Zum einen, 1067 Beendigungskode nur bedeutet „ERROR_PROCESS_ABORTED - Der Prozess wurde unerwartet beendet“.

Zum anderen ist der Stack-Trace, den Sie angegeben haben, meiner Meinung nach nur die Verarbeitung des Ereignisses Ihrer Programmbeendigung. Dies ist der Thread, der das stillschweigende Melden durchgeführt hat. Daher müssen keine Informationen hinzugefügt werden.

Ich denke, wir werden mehr darüber erfahren, ob das Problem erneut auftritt, nachdem die gebündelten Dienste auf svchost wie hier beschrieben getrennt wurden . Aber auch das Design von svchost als Ursache könnte irreführend sein.

Nach meiner eigenen Erfahrung besteht der einfachste sichere Weg, das Problem zu finden, das die vollständige Kontrolle über die Quellen des Produkts erfordert, darin, das Produkt für das Debugging zu kompilieren und im Debugger auszuführen, wobei Haltepunkte für alle Systembeendigungsroutinen festgelegt werden. Für C sind dies _exitund _abort, aber es kann andere geben.

Wenn das Programm im Debugger angehalten wird, können Sie anhand der Aufrufliste und der globalen / lokalen Variablen feststellen, warum.

Wenn Sie den Debugger nicht verwenden können, benötigen wir viel mehr Daten zum Programm, um eine aussagekräftige Meinung abgeben zu können.

BEARBEITEN

Selbst wenn Sie für die Produktion kompilieren, können Sie zumindest eine Symboldatei erstellen, die bei der Fehlersuche und Analyse hilfreich ist.

Sie sollten die Ereignisanzeige untersuchen. Wenn das Programm abstürzt, befinden sich dort möglicherweise einige Informationen und auch in User-Mode-Dump-Dateien .

Um die Abstürze besser analysieren zu können, können Sie Benutzer-Dumps in Systemsteuerung> System> Erweiterte Systemeinstellungen> Registerkarte Erweitert> Starten und Wiederherstellen> Einstellungen> Debugging-Informationen schreiben, auf "Complete memory dump" setzen und OK wählen.

Sie können diese Dumps zusammen mit der Symboldatei in einem Debugger verwenden. Sie können dies auf einem anderen Computer tun, normalerweise dort, wo Sie die ausführbare Datei kompiliert haben. Wenn Sie Visual Studio verwenden, gibt es jedoch einige wichtige Punkte:

  • Die Dump- und Symboldatei muss von derselben ausführbaren Version generiert worden sein
  • Der Speicherauszug muss sich bei der Analyse in genau dem Ordner befinden, in dem er erstellt wurde ( C:\some-path\usw.).
Weitere Informationen finden Sie in der aktualisierten Frage. Lassen Sie mich wissen, wenn Sie weitere Fragen haben. nietras vor 5 Jahren 0
Mehr Infos hinzugefügt. Und in welcher Sprache ist das ausführbar? harrymc vor 5 Jahren 0
Wir haben Ereignisbetrachter, mögliche Protokolle usw. beobachtet. Es gibt keine Ausnahmen, ich erwähne das auch an anderer Stelle. Der Prozess wird ohne jede Spur von Ausnahmen oder warum beendet. nietras vor 5 Jahren 0
C # nicht das ist Sachen, denke ich. .NET 4.6. nietras vor 5 Jahren 0
Ich möchte nur wissen, ob Sie Visual Studio verwenden, aber ich habe diesen Teil trotzdem hinzugefügt. harrymc vor 5 Jahren 0
0
apocalysque

Es ist nur eine Theorie, aber vielleicht, da es mit einer geplanten Aufgabe begonnen hat, die der Aufgabenplaner irgendwie noch übergeordnete Kontrolle über den Prozess hat, nachdem er gestartet wurde? Es scheint mir, dass es eine Bedingung gibt, die erreicht wurde, oder ein Problem, bei dem der Task-Scheduler von Windows die Task stoppt. Vielleicht sollten Sie es mit dem Befehl start ausführen, damit die Anwendung gestartet wird, die "geplante Aufgabe" jedoch abgeschlossen werden kann und die Steuerung der Anwendung daher vom Windows-Aufgabenplaner freigegeben wird.

ZB C: \ Windows \ System32 \ cmd.exe / c "Titel" C: \ Windows \ System32 \ notepad.exe starten

(oder welches Programm auch immer Sie ausführen)

Sie müssen die cmd.exe ausführen, da der Startbefehl ein integrierter Befehl ist. Wenn Sie die Dokumentation für den Startbefehl lesen, werden Sie auch feststellen, dass das Titelargument erforderlich ist. Sie können es als "Titel" belassen oder beliebig einstellen.

Nicht sicher, warum das Down stimmen. So funktioniert der Taskplaner. Erstellen Sie einen Task ohne Trigger, der notepad.exe ausführt, und starten Sie ihn manuell. Solange der Prozess notepad.exe geöffnet ist, wird die Aufgabe als "ausgeführt" angesehen. Standardmäßig ist der Aufgabenplaner so konfiguriert, dass Aufgaben, die länger als drei Tage dauern, automatisch geschlossen werden. Auch wenn dies nicht der Fall ist, gibt es möglicherweise eine andere Bedingung oder ein Problem mit dem Taskplaner, der die App schließt. Wenn Sie den Prozess notepad.exe beendet haben, wird der Task wieder in den Bereitschaftsstatus versetzt. apocalysque vor 5 Jahren 0
Die Absicht ist, dass Antworten endgültige Lösungen sind. Es ist großartig, eine Theorie zu haben. Nachdem Sie es getestet haben und sich vergewissert haben, dass es funktioniert, wäre dies der richtige Zeitpunkt, um es als Antwort zu posten. [Aus Bewertung] (https://superuser.com/review/low-quality-posts/789523). fixer1234 vor 5 Jahren 0
Es ist nur eine Theorie, weil ich nicht genug Informationen habe, um zu wissen, welche Anwendung dieser Typ ausführt, ganz zu schweigen davon, was dieser Fehler für die Anwendung bedeuten würde. Offensichtlich möchte der Typ nicht sagen, also habe ich nicht gefragt. Dies ist so gut wie es mit den begrenzten Informationen wird. Da seine Protokolle jedoch ausdrücklich darauf hinweisen, dass sie durch denselben Prozess wie der Task-Scheduler beendet werden, würde ich sagen, dass dies eine ziemlich starke Korrelation ist. Die einzige Möglichkeit, diesem Mann eine endgültige Antwort zu geben, wäre, an der Box zu sitzen und sie selbst zu debuggen. Ich habe die Theorie übrigens getestet. apocalysque vor 5 Jahren 0
@apocalysque Ich werde das Kopfgeld erneut erstellen, wenn wir die genaue Ursache des Problems herausfinden, dies kann jedoch eine Weile dauern. Wenn es jedoch an einem Task-Scheduler lag, gebe ich Ihnen natürlich das Kopfgeld. nietras vor 5 Jahren 0
@apocalysque Leider habe ich nicht genug Punkte, um die Kopfgeldmenge neu zu erstellen, dachte, die Punkte würden zurückgehen. Sie hatten trotzdem recht, es waren falsche Taskplaner-Einstellungen, siehe Fragen-Update. nietras vor 5 Jahren 0