防止 windows 服务器暂停我的进程

Question

I've developed a program (winforms application, not a service) in C# that runs on a windows server.

The program starts multiple times based on requests from outside the server.

From time to time I see that the program is "Suspended" for an unknown reason. I think it is related to a lack of resources, but not sure.

How can I prevent windows from suspending my program?

Update To be clear, I know that the program crash and it is OK. What I'm asking is not how to improve performance \ prevent the crash, but how to remove the process from the process list \ prevent this suspended status?

Answer 1

Depends in your hardware/software configuration , it's hard to know where is your bottleneck.

I recommend instead to do Multi-thread/task app where you're able to control threads and asign priority, resources, stop, resume, abort, etc...

use on command console to start and check if happends the same but with the parameter high:

start /HIGH <ProgramPath>

Read more how to change priority on executables

Task Scheduler on windows servers MSDN -> Priority

(It's only an opinion, start digging about others solutions.)

Answer 2

You must set the ServiceBase.CanPauseAndContinue Property to False in the constructor of the service before it is started.

NOTE the side effect is:

If CanPauseAndContinue is false, the SCM will not pass Pause or Continue requests to the service, so the OnPause and OnContinue methods will not be called even if they are implemented. In the SCM, the Pause and Continue controls are disabled when CanPauseAndContinue is false.

For more information see this Microsoft Doc

Answer 3

There are multiple methods of keeping an app awake.

One method would be to request a deferral and then only mark that deferral complete when you are done.

First you need a deferral object that will remain in scope of your process

SuspendingDeferral deferral

Then you need to override OnSuspending

async protected void OnSuspending(object sender, SuspendingEventArgs args)
{
    deferral = args.SuspendingOperation.GetDeferral();
    await SuspensionManager.SaveAsync();
}

Then you need to mark the deferral complete when your process is done doing whatever it was doing

    if (deferral is not null) { deferral.Complete(); }

Full details can be found in the Microsoft docs

For discussion of other methods see this thread: How to Disable UWP App Suspension?

Answer 4

Technically the process is suspended but if you look at the memory consumption of 32K you can tell it was not suspended. Your process did crash with an unhandled exception which in turn triggers Windows Error Reporting to take a memory dump.

This involves some kernel magic which keeps a process handle in the kernel (System process) alive. It is not a big deal or memory leak since the process did already terminate. Only the PEB (Process Environment Block) the 32K which includes mostly command line, loaded dlls and environment variables are still there.

I would not worry about suspended processes but why your process did crash with an unhandled exception. This could even be a feature to make programers aware that their process did crash by looking at a looong list of suspended processes in Task Manager;-).

Since it is a .NET Application you will find a generic error messages that a process did crash in the Application event log and a .NET Runtime logged error message with more exception details.

Perhaps that is already enough to keep you going to fix your issue. If not you can configure WER to create a full memory dump via a registry setting ( https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps ). Now you have for each "suspended" process a full memory dump you can load into Visual Studio to look further what was the issue.

To further check who holds your process handle still open you can use handle eg ProcessHacker (the better Process Explorer) https://processhacker.sourceforge.io/nightly.php

If something else is happening you can see with this tool who is holding any outstanding handles to your process open. But I strongly suspect it is the Windows Kernel.