FolderBrowserDialog causes app to stay in memory after exit?

Question

0.00/5 (No votes)

See more:

Has anyone else run into a problem where creating a new FolderBrowserDialog() in a C# Windows Forms app causes the app to stay in memory after the app exits normally?

After getting the result from FolderBrowserDialog.ShowDialog() call, I called the Dispose() method. However, after exiting the app normally, I can use Windows Task Manager and see that the exe is still in the process list.
This app has lots of forms, and none of them cause this problem except FolderBrowserDialog().
Does anyone know of a workaround for this?

OK, so I created a little test app as suggested, and sure enough, the test app has the same problem.
In the test app, I used Visual Studio 2010 and created a new Windows Forms project.
Then, I added a button to the main form. The following code shows the button event.
When I run this test app, the app goes away normally as long as I never click the button1.
If I do click button1, then the app appears to exit normally when I quit it. However, using Task Manager shows the exe is still in the processes tab.
One other thing is that this problem only comes from running the Release version. Running inside the IDE debugger doesn't cause this problem. Apparently, Visual Studio knows how to clean up even though the release exe somehow still holds on to resources or something.

This app is running on Win XP SP3, and .NET 4.

C#

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace FolderBrowserTest
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, EventArgs e)
        {
            FolderBrowserDialog fbd = new FolderBrowserDialog();
            DialogResult result = fbd.ShowDialog();
            fbd.Dispose();
        }
    }
}

Posted 12-Jan-12 9:45am

amp_dude

Updated 23-Jan-12 5:21am

v5

Add a Solution

Comments

Sergey Alexandrovich Kryukov 12-Jan-12 16:32pm

No, but it sounds weird. Could you possible create a complete but shortest possible code sample to reproduce it. Is so, please use "Improve question" above.
--SA

Catalin Serafimescu 12-Jan-12 16:40pm

I suspect there is thread remained alive. Please provide more information about what are you doing.

Nathan Stiles 21-Jan-12 10:33am

I can't reproduce this in 32bit Windows 7 .NET 3.5. Both my debug and release assemblies were removed from memory when I closed the form. I usually wrap disposable objects in a using statement.

amp_dude 23-Jan-12 11:26am

@Nathan Stiles - Thanks for trying. I updated the question to indicate it happens in Win XP SP3 and .NET 4.
Why do you wrap disposable objects in a using statement? Do you think there is a problem with the way I have done it?
BTW, in examples on MSDN, they don't even bother with the Dispose() call. In case there was a bug in the Dispose() method, I tried without it too, but got the same results.
Could you show a snippet of your wrapper?
Thanks

Nathan Stiles 23-Jan-12 15:06pm

I use the using because if the code before the dispose call throws an exception then I don't think the dispose call is hit.
I simply do this:
using (FolderBrowserDialog fbd = new FolderBrowserDialog ())
{
if(fbd.showdialog == DialogResult.OK)
{
//whatever here
}
}

amp_dude 23-Jan-12 15:11pm

Good point! As a result of reading your suggestion, I have started putting in using statements also. Even though it doesn't solve my question, I agree that this is a good idea. Thanks!

amp_dude 23-Jan-12 14:18pm

I wrapped my FolderBrowserDialog in a using statement as Nathan suggested, but it still isn't solving the problem.
Maybe there is a bug with FolderBrowserDialog that only comes up in Win XP and/or .NET 4?

Nathan Stiles 23-Jan-12 15:09pm

amp_dude: Are you debugging when you see this behavior? Does control return to VS2010 after you close the form? Are you sure you're not seeing the whatever.vshost.exe in taskmanager?

amp_dude 23-Jan-12 15:17pm

No. Actually, the opposite is true. When running in the debugger, all is well. But when I run the Release build on its own (Not in Visual Studio), I see the process sticking around after exiting the App.
After extensive searching the internet, it does seem a couple other people have noticed this, but it seems to have some machine dependence. Not sure if it is dependent on which Windows OS or which .NET target yet.

My next idea is to target .NET 3.5, but that would mean I'd have to make some other changes to my application for the downgrade.

Nathan Stiles 23-Jan-12 15:23pm

Knowing that you have much else going on in the code makes me a bit skeptical. Did you reproduce this with a completely empty windows forms project only adding the button and the browserdialog?

amp_dude 23-Jan-12 15:24pm

Yes. I reproduced it using the code above.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Winston_D · Answer 1 · 2012-02-02T04:41:00

I am not sure if this will work but it is worth a shot. When the program is closed (whereever or whatever method called to do this), add this as the last line of code:

C#

//on Exit Event Handler Method or the program exit methods you use:
{
    //..... blah blah blah
    Environment.Exit(0);
    //you may use a different ExitCode to 0 but 0 should work fine. it does for me
}

it might not be the most professional way of doing it but if it works with no other way, why not;)