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

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:

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:

Richtige Einstellungen sind: