Click here to Skip to main content
15,918,275 members
Please Sign up or sign in to vote.
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
Updated 23-Jan-12 5:21am
v5
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
}
}

1 solution

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;)
 
Share this answer
 
Comments
amp_dude 2-Feb-12 11:49am    
Thanks. I tried this, but it still didn't solve my issue.
Winston_D 6-Feb-12 5:11am    
Sorry, I have no other tricks up my sleeve

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



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900