VB.NET Framework 2.0 OLEDB not disposing correctly?

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.
Post Reply
Simon Lockington
Posts: 5
Joined: Mon Jul 10, 2006 4:31 am

VB.NET Framework 2.0 OLEDB not disposing correctly?

Post by Simon Lockington » Thu Sep 14, 2006 11:55 pm

Hi guys,
I've been using your software now for a few months tracing down memory leaks and it has been invaluable.

However I have a question I'm hoping you could help me with.

I have a system that periodically (ie once a minute) does some data activity via OLEDB. I've noticed that many of my OLEDB objects are registering as being 'undisposed' even though I specifically 'close' them and assign them 'nothing'.

To try and rectify this as per one of your tutorials, I moved all the data interaction code into Using - End Using blocks.

However I still see many 'undisposed' instances. The objects most commonly undisposed are:

System.Data RBTree<DataRow>.RBTreeEnumerator
System.Data.OleDB SessionWrapper
System.Data.OleDB DataSourceWrapper
System.ComponentModel EventHandlerList

My question is, are undisposed instances really bad? My understanding is the object has been garbage collected (and certainly there aren't any extraneous live instances lying around), but just didn't have 'disposed' explicitly called on them.

However if I'm using the Using/End Using statement, shouldn't the disposing actions be automatically taken care of for me?

Thank you in advance for any help you might be able to provide.

Kind Regards,

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Fri Sep 15, 2006 3:55 pm


You can only take care of disposing instances that you create yourself. Instances created by the framework must be destroyed by the framework. So if you have undisposed instances that are created by the framework and that are not correctly disposed, there's not much you can do. However, even though failing to dispose instance can cause big memory usage problems, in many cases an undisposed instance does not affect performance and memory utilization.

System.Data.RBTree<K>.RBTreeEnumerator: Only contains an empty Dispose method. The Dispose method exists since IEnumerator<T> derives from IDisposable

System.Data.OleDB.SessionWrapper and System.Data.OleDB DataSourceWrapper: Derives from SafeHandle and it is highly recommended that instances of these classes are disposed. Do you have any information about who's creating these instances?

System.ComponentModel.EventHanderList: Only clears the head of a list of delegates. There should be no reason for disposing an EventHandlerList instance, as long as the list itself becomes eligible for GC.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Posts: 6
Joined: Mon Mar 21, 2005 2:13 pm

Post by PK » Sun Nov 04, 2007 5:43 pm


I noticed the same thing was happening with my program. The DataSourceWrapper would increase its undisposed counter and I do not know how to correctly dispose of it. How is this done? :?:

Your previous answer says that it is highly recommended that they are disposed of.

I did notice that if you create a OleDb.OleDbDataAdapter with a closed connection then the connection is opened a closed for you automatically. This process left a DataSourceWrapper undisposed. If I first opened the connection myself, then a DataSourceWrapper was not created.

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Mon Nov 05, 2007 6:55 pm

Even though it is recommended that you always dispose a disposable instance, it is often not possible if you're not the author of the code that creates the instance. So if the OleDbDataAdapter creates an DataSourceWrapper, and then lets it be GCed without being disposed, there's unfortunately not much you can do about that (since you never have access to the DataSourceWrapper instance). To find out how the undisposed instances were created, you can sort the allocation stack by undisposed instances.

As mentioned, failing to properly dispose instances can cause bad memory and resource utilization, but it often will not create a memory leak. Unless the dispose method is used to remove references to the instance (e.g. an event handler), the memory/resource will be reclaimed eventually.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Post Reply

Who is online

Users browsing this forum: No registered users and 11 guests