I have a timer within my Windows service which is built using C# 2.0. We are in the process of designing the Exception handling. Since it is Timer runs on its own thread we would like to handle the out of memory exception. When that occurs we would like to stop the service. How can we gently stop the service when that happens on the different thread ?
OutOfMemoryException is never supposed to be "handled" by your application. You should start to troubleshoot if there is any memory leak immediately and resolve the leaks.
Use the service control manager API to send your own service a "stop" command? That would allow your standard functionality for handling that command to be invoked.
Related
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?
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.)
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
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?
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://learn.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 e.g. 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.
Could I get an explanation of what happens when a WPF application becomes idle and the user tries to use it again. For instance, when I click any UI control after the idle, it either takes quite some time longer than it should or the whole app just crashes. What is causing this issue and how can I solve it?
(This is a single threaded application as well)
We have faced same issue when WCF calls are there from UI. Basically WCF channels gets faulted if the application is idle for sometime.
Put try catch around WCF calling code and check if the app is crashing.
Once you confirm its WCF proxy issue look for proxy pooling, recreation of proxy via factory which takes care of fault state etc...
I have developed one application in C#.net 3.5 and VS 2008, which contain many controls such as tab, textbox, objelistview, gauges, zedgraph.
My application is intended to communicate on serial port and update the data on said ui. To achive this i am using another timer thread.
Its 24X7 running application, but sometime it just freeze and timer thread stops executing automatically, i can see the sceen but can't click anywhere and simply i need to restart application to make it run again.
Please note i dont see application not responding message or likewise, it just simply freeze.
If any one can provide any inputs for the same it would be great.
You may have memory leaks or too many uncolsed resources. While your application is freezed see Task Manager and check Memory and CPU usage. They can help you gueesing if too many of RAM is used or if your application consumes too many CPU processing power.
In your application consider disposable objects. Try to dispose them correctly. After opening a serial port don't forget to close it again. Also you can use logging mechanisms to see at what point your application freezes.
Try implementing a watchdog using System.Threading.Timer and check if thread responsible for communication is responsive. Also, I'm not sure what do you mean by "another timer thread", but again, you should use aforementioned class to track time between datapolls and use callback method.
Please also remember, like afsharm said, that you need to free resources you don't use anymore, so either get one handle on your COM port and use it or just release it everytime update has ended.
When an AppDomain has an unhandled exception, you can handle the AppDomain.CurrentDomain.UnhandledException event.
However, you cannot prevent the AppDomain from shutting down. You can't just block the thread. Eventually the AppDomain will shut it down.
In ASP.NET, if you have objects registered (IRegisteredObject), the AppDomain will give your code 30 seconds to run.
Does anyone know what the timeout is for a standard WPF application?
I don't know how to set timeout for DispatcherUnhandledException handler
But, is the application terminating with a Environment.Exit or Application.Exit where there's an unhandled exception?
Quoting: http://www.dev102.com/2008/06/24/how-do-you-exit-your-net-application/
Environment.Exit - From MSDN: Terminates this process and gives the
underlying operating system the specified exit code. This is the code
to call when you are using console application.
Application.Exit -
From MSDN: Informs all message pumps that they must terminate, and
then closes all application windows after the messages have been
processed. This is the code to use if you are have called
Application.Run (WinForms applications), this method stops all running
message loops on all threads and closes all windows of the
application. There are some more issues about this method, read about
it in the MSDN page.
For WPF, if an unhandled exception will crash the app with an Environment.Exit (as supposed to Application.Exit) - I suspect application don't exit until all threads are done. If so, then you may try do what you need to do via a thread in DispatcherUnhandledException handler.
Can you let me know if this is the behavior as well? I am curious. We never had problem with this as on WPF DispatcherUnhandledException handler we only do simple logging to disk
Sure, we must avoid catching and attempting to handle AccessViolationExceptions(AVEs). However, in my current case, the exception is thrown from a COM+ managed component which terminates the process that threw the exception, therefore, cleaning up correctly. However, a windows service, hosting WCF, that consumes said COM+ component receives the bubbled up AVE causing the service crash.
The IErrorHandlers in place don't seem to fire/detect AVEs.
Is there any way to enable WCF IErrorHandlers to catch AVEs?
As a variant you can try to add a handler on AppDomain.CurrentDomain.UnhandledException where you can restart a service again.
Or, you can run your main win_service in one ('Main')AppDomain and host the WCF service in another ('Sub')AppDomain. In such way you can unloaded(reload) the sub-proccess without affecting the main process.
It is not possible for IErrorHandlers to catch exceptions similar to AccessViolationExceptions (SEHExceptions).