Windows 10: Terminal exiting with code 4294967295 every time

I have been struggling with this problem very recently. The terminal will give me the regular prompt, at which point I can quickly type something in and maybe get it to run, but then in about 5 seconds I get the "[process exited with code 4294967295 0xffffffff]" message. When and WhereThis problem occurs in any terminal I open, be it Command Prompt, the Terminal app, or Visual Studio Code. What I've TriedI have tried disabling and shutting down WSL2 because that was recommended, but it changed nothing. I have no clue how to fix it, and since I haven't found anything else online that seems to

:)

 

Is there a way to continue giving input after terminating process with Ctrl + C and getting exit code?

I'm using Powershell from Windows Terminal. When I run some CMD process (such as serving file on local server) and quiet with Ctrl + C, It outputs Process exited with code ****** and stops taking input after that. So I have to open new terminal tab, CD into
working directory and cont. every time. Is there a way to continue giving input after terminating process with Ctrl + C and getting exit code?

 

Windows Terminal Release Candidate v0.11.1333.0 (1.0rc2) to Windows 10

Source: https://github.com/microsoft/termina...g/v0.11.1333.0

 

Silent Process Exit: process '?' was terminated by the process 'C:\Windows\System32\svchost.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:

Using Configuring Silent Process Exit Monitoring - Windows drivers we have configured silent process exit monitoring. And we finally have a few samples of this:

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:

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:

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.

UPDATE 3: Perhaps the above statement was wrong, the default in the TaskScheduler library seems to be 3 days or 72 hours.

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: