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 ?

Splenic

I guess any finally blocks will not be processed in this case, which may cause unexpected bugs in the future when someone else maintains the code. – Dreamland

@Hosam: That's a good point. Why don't you post it as an answer so it can be upvoted? – Splenic

Answer 1

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.

Dreamland

The OS isn't supposed to leak resources just because a process was killed. But those finally blocks and finalizers are a good point. – Neapolitan

@Neapolitan Yes, but sometimes it does. For example, a camera may be left open even though an application crashes. It could be a bug in the driver, but that's also part of "the system". – Dreamland

Answer 2

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.

Stenson

In fact it's Process.GetCurrentProcess().Kill(); I fixed my post accordingly. Thanks for noticing it !:) – Splenic

Answer 3

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!

Ascending

And yet I have a test-case right now that fails with the Kill hack. It's loaded dice, of exactly when the process was killed, and exactly what the process was doing, and exactly what is supposed to happen. This is why ACID databases go through tremendous lengths to ensure data writes/replayability - so that they can be rudely shut down at any time and not lose data. If the stuck process was doing squat all with critical data (then or later), then by all means nuke it; it's really no different than killing the process via process explorer. – Gouda

Answer 4

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.

Uzbek

Answer 5

It should be noted that finalizers may actually be never executed, so killing the process is not much different from any other reason to skip finalization code, like slow finalizers or a finalizer throwing an exception.

All in all, I wouldn't worry much about closing the application taking a few seconds, especially if it immediately hides all its windows and "disappears" for the user. However, if closing takes dozens of seconds and/or the user is likely to execute the application again and it doesn't support multiple instances, calling Process.Kill may be a good idea.

I know some applications which take ages to terminate, and I hope to see them one day just brutally killing themselves rather than making me, the user, do it (it's especially annoying on OS restart).

Fadil

Answer 6

Using Third party libraries with no way to catch their errors or leaks, sometimes the only way to end it without throwing up a crash MessageBox, is to Kill the process.

Masoretic

Answer 7

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.

Finkelstein

Environment.Exit(int) does not guarantee exit in case the underlying appdomain or native code jumps into WER / ReportFault family of functions. Even Kill() is not a termination guarantee since kernel-level deadlock will prevent the process to quit, but Kill usually terminates instantly, while Exit allows the program to cleanup. – Callison