PRB: The Garbage Collector Does Not Release a COM Object That Handles Events as You Expect (827417)
The information in this article applies to:
- Microsoft .NET Framework 1.1
- Microsoft .NET Framework 1.0
- Microsoft Common Language Runtime (included with the .NET Framework 1.1)
- Microsoft Common Language Runtime (included with the .NET Framework) 1.0
SYMPTOMSThe garbage collector does not release the Component Object
Model (COM) object that handles events as you might expect. For example, you
create a COM object and then you add an event-handler to your COM object. You
remove this event-handler from your COM object. Next, you set the reference to
your COM object not to refer to an object by using null in Microsoft Visual C# .NET or by using Nothing in Microsoft Visual Basic .NET. If you run the garbage collector
and then you wait for the thread that processes the queue of finalizers to empty
the queue, you might expect the garbage collector to release your COM object.
However, the garbage collector does not release your COM object.CAUSEYou can handle unmanaged COM events by using the connection
point event model. You can handle managed events by using the delegate
model. A COM object in managed code uses synchronization objects that
have finalizers to wire COM
events to their corresponding managed event-handlers. Therefore, the garbage collector releases such a COM object
only after it releases the associated synchronization objects.
When
you run the garbage collector for the first time after it considers releasing a
synchronization object, the garbage collector does not release the
synchronization object because the synchronization object has a finalizer.
Instead, the garbage collector adds the synchronization object to the queue of
finalizers. You might wait for the thread that processes the queue of
finalizers to empty the queue. However, the garbage collector releases your
synchronization object only when you run the garbage collector again.
Therefore, even if you wait for the thread that processes the queue of
finalizers to empty the queue, the garbage collector does not release the
associated COM object, and the problem that is described in the "Symptoms"
section of this article occurs.WORKAROUNDTo work around this problem, run the garbage collector
again, and then wait for the thread that processes the queue of finalizers to
empty the queue. To do this, follow these steps: Note The following procedure is based on the sample from the "More
Information" section of this article. The code and the file names in this
procedure may differ from your code and from your file names.
- Quit your application.
- In Visual C# .NET, locate the following code in the
Form1.cs file:
GC.WaitForPendingFinalizers(); In Visual Basic .NET, locate the following code in the Form1.vb file:GC.WaitForPendingFinalizers() - In Visual C# .NET, add the following code after the code
that you located in step 2:
// Run the garbage collector again.
GC.Collect();
// Wait for the thread that processes the queue of finalizers to empty the queue.
GC.WaitForPendingFinalizers(); In Visual Basic .NET, add the following code after the code that you
located in step 2:' Run the garbage collector again.
GC.Collect()
' Wait for the thread that processes the queue of finalizers to empty the queue.
GC.WaitForPendingFinalizers() - Build your application, and then run your application.
By default, Form1 is displayed. - Click MyButton.
Your application
breaks at the set breakpoint when the garbage collector releases your COM
object.
STATUS This
behavior is by design.REFERENCES For additional information, click the following article
number to view the article in the Microsoft Knowledge Base: 317866
INFO: Roadmap for Garbage Collection in the Microsoft .NET Framework
For more information, visit the following Microsoft
Web sites:
Modification Type: | Major | Last Reviewed: | 10/2/2003 |
---|
Keywords: | kbManaged kbMemory kbide kbDebug kbCOMInterop kbEvent kbProgramming kbinterop kbGarbageCollect kbprb KB827417 kbAudDeveloper |
---|
|