Silent Process Exit: process '?' was terminated by the process 'C:WindowsSystem32svchost.exe' with termination code 1067

We have a serious issue with a C# application being terminated silently at random and infrequent points in time on a Windows 10 32-bit installation.
E.g. it might be a month between occurrences. Or sometimes just a day.

Basic system specifications:

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

Using https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-and-clearing-flags-for-silent-process-exit we have configured silent process exit monitoring. And we finally have a few samples of this:

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.

Looking at the dumps for this, which was setup for the monitoring we got a process ID for the svchost. This service was still running at the system, and it shows the following list of services:

Which seems to be a list of "netsvcs" for Windows. Opening the dump from the svchost.exe and looking at this a single thread was found with an interesting call stack:

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 is the Unified Background Process Manager. But how can this be terminating our application? And why? And what does the termination code 1067tell us?

Below is the log entry from 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:

  
    
    3001
    0
    4
    0
    0
    0x80000000000000
    
    4853
    
    
    Application
    PC
    
  
  
    APPLICATIONPATH\APPLICATIONNAME.exe
    C:\Windows\System32\svchost.exe
    1067
    01d43ed2aee892ab
  

NOTES: The PC is not being shut down at the moment the app terminates nor are there any other indications in event logs as to why the process was terminated.

UPDATE 1: Here a few extra details (trying to answer as many as in comments):

• Process is (sometimes) started via TaskScheduler when Windows is started yes. Other times by user. Not entirely sure problem only occurs when started via TaskScheduler. But interesting point? Could windows kill a task for some reason? Note that times between process exiting can be up to a month.


• We have the source for the main program, but would have problems running it inside a debugger since this is running at a customer, but maybe. We can't run it compiled for Debug though. Not at all, due to performance. This is live production.


• Application is a normal WPF application without any child processes or any other inter-process communication. It does use a few third party devices e.g. libraries and drivers.


• We have setup event handling of appdomain exceptions and application exceptions etc. None of these occur. The process exits without any indication of an exception occurring. It is a hard process exit.


• We have suspected perhaps a third party driver being the source, but how? And how could we determine whether this was the case?

UPDATE 2: We use the nuget package TaskScheduler to setup the task via code. Note we do not set the ExecutionTimeLimit, which should therefore be Nothing and hence infinite.

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: Perhaps the above statement was wrong, the default in the TaskScheduler library seems to be 3 days or 72 hours.

//
// 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: Only thing is we observe silent process exits after the process has been running for much longer than 3 days, e.g. 30 days so not sure it is this after all.

UPDATE 5: The longer than 3 days was not correctly observed, so after everything it is now clear this was due to incorrect settings for the task scheduler task. The wrong settings shown below:

Correct settings being:

Answer

It's just a theory, but maybe since it's started with a scheduled task that somehow the task scheduler still has "parent" control of the process after it's started? It would seem to me that there may be some condition that's reached or problem where the windows task scheduler is stopping the task. Perhaps you should try running it using the start command so that the application is started yet the "scheduled task" is allowed to complete, and therefore control of the application is released from windows task scheduler.

E.G. C:\Windows\System32\cmd.exe /c start "title" C:\Windows\System32\notepad.exe

(or whatever program you're running)

You have to run the cmd.exe because the start command is a built-in. Also, if you read the documentation for the start command you'll notice that the title argument is required. You can leave it as "Title" or set it to whatever you want.