Why shouldn't I use Process.GetCurrentProcess().Kill() to exit my WinForm application?

Question

Right now, when the user want to exit my application, I do the few things I have to (ie disconnecting from the server, saving the user data...) and then I do the following :

• Exit all my mainloops using booleans
• abort the threads still running (typically, my server polling thread)
• kindly call Application.Exit();

This takes a few seconds to exit, and serves no real purpose (everything is already saved on the server, so I don't really care what happens there)

If I use this instead, I got instant termination with no drawback I can think of :

 System.Diagnostics.Process.GetCurrentProcess().Kill();

Why wouldn't I just terminate my process and let the CLR drop the AppDomain ?

I know that carefully disposing your shared resources (IO file handlers, etc.) is important (so please don't answer that:)), but once it's done, is there a real reason to cleanly exit my App ?

Answer 1

Firstly, I think you mean Process.Kill(), not Process.TerminateProcess(). Secondly, killing the process will just rip it out. Any cleanup code will not execute and your application will not get a chance to cancel the kill (eg. if the user has unsaved data). If you're happy with that, go for it.

HTH, Kent

Answer 2

That's indeed a good question!

Once upon a time (over ten years ago) I wrote a VB6 app wich hung at termination due to a confirmed bug in the WinINet OCX (or whatever it was called) due to the particular certificate used on a web server it was talking to.

Without any way to come around this bug I used TerminateProcess and for all that I know, this app was in use on several thousand machines for several years and I never heard of any problem regarding this hack!

Answer 3

Keep in mind that if you are writing to a file/network stream it's possible that your write will be imcomplete.

If your application is ready to deal with corrupt data in that way, then there's no reason not to do it. However, if you can exit by other means I'd recommend that.

Answer 4

Proper shutdown is a general extensibility principle. By committing to cleaning up in a controlled fashion you ensure new features/classes added to your code also cleaned up properly. Otherwise every time you extend your software with a new feature you'll have to evaluate if you need to revise your "quick bailout".

Instead of going for a shortcut, I would suggest eliminating unnecessary cleanup code causing slow shutdown instead. For instance you may not need to kill every thread one by one. You may not need to exit from all the loops but just the main one. This way you'll have more granular control over what you cleanup rather than being left at the discretion of a harsh kill.

Cleanup only what you really need to cleanup. Your exit will be much faster and you'll have complete control over your bailout strategy.

Answer 5

Killing the process would mean that finally blocks will not be executed, and probably not even critical finalizer objects, which may actually be critical, and cause resource leakage at system level. It can also cause unexpected bugs in the future when someone else maintains the code, as they (or you) will have to twist their heads, having to think every time they write a finally block whether it will be executed.

Answer 6

Why not use System.Environment.Exit(int)? It seems like you want to do this just to save code. To me it's much clearer to see the call to Exit does and your shutdown will be more controlled, Finalizers and Critical Finalizers will run.