0

I have a WPF application with a close button which calls Application.Shutdown() to close the application. The window closes, but the app keeps running. It is clearly visible in Visual Studio that something is going on, but pausing doesn't work anymore.

I have seen similar questions on here which led me to try some other solutions. I have tried all the options for ShutdownMode in App.xaml but none of them seemed to make a difference. Same with Environment.Exit().

The obvious cause would be that a thread is still running but I can't find any such threads.

I finally resorted to a very unelegant method, in App.xaml:

protected override void OnExit(ExitEventArgs e) { base.OnExit(e); Process proc = System.Diagnostics.Process.GetCurrentProcess(); proc.Kill(); }

This actually works, the application close immediately, but I wonder if this might cause any problems somewhere along the line.

Improve this question
5
  • Normally, closing the Window (calling Close()) is enough to close the app. I don't think we'll able to help you without more information though Commented Jul 21, 2018 at 23:31
  • Hit the pause button in VS right after you close the window. Open the Debug > Threads window and see where they’re blocking. Also, does this happen if you run it without a debugger attached? Commented Jul 22, 2018 at 5:16
  • Thank you for the input. The problem is clearly visible when debugging, but also occurs when I run the application outside VS. It will take a couple of seconds to close, sometimes longer. It will still be visible in Task Manager. I tried pausing after the window closes, but that doesn't work. Commented Jul 22, 2018 at 23:57
  • @Remco "that doesn't work" - well, what happens, exactly? Does VS fail to break execution? Commented Jul 23, 2018 at 0:03
  • It doesn't work in that nothing happens. The application window is gone, but the diagnostic tool keeps running and hitting the pause button has no effect. I can set a break point when the window closes or the application exits (either OnClosed in the MainWindow.cs or OnExit in the App.xaml.cs) but no code seems to be executed after that, while the programma still appears to be running. Commented Jul 23, 2018 at 21:26

2 Answers 2

Reset to default
1

Thanks for everyones insights.

I looked into it a little deeper today (with some help, I'll admit), especially because this problem didn't occur in earlier versions and the application has been in development for several years. So tracking back to where the issue first arose gave some insights.

It turns out that there was a MediaElement with an invalid source that caused this problem. Having a non-existing file as source for a MediaElement apparently doesn't give any problem when the application is running, but does cause it to be very slow when closing down. Luckily that is easily fixed.

Digging a little further I noticed that having a storyboard that is still running also might slow down the closing process, but that is just a matter of two or three seconds. The problem with the MediaelEment could cause a lag of (much) more than ten seconds.

So the problem is solved, but my question, though academic now, more or less remains: is it a problem to close down the application by simply killing the process? That still appears to be the quickest way to shut things down.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

can you add the MediaElement properties that you were using? I am curious what MediaElement.UnloadedBehavior Property value is.
0

but my question, though academic now, more or less remains: is it a problem to close down the application by simply killing the process?

It's a bad idea to kill processes. It can be safe in some circumstances but if you do anything that disallows the cleanup of system owned resources you can leave clutter in the form or semaphores and handles. It's good that you kept digging until you found your bug. I would never, ever throw proc.kill into production, especially for your own process.

If you know a child process can be safely killed, maybe. But it would always be better to signal it to shutdown, give it a reasonable amount of time, and if you have to kill it, do it in a way that can't be ignored. Then behave like a dog with a bone until you eliminate the root cause, like you did with this one.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.