WPF memory leak with text fields displayed

Question

In one of my applications, I have a performance issue that I cannot solve:

The application is built with input controls derived from the TextBox class, which has its own control template in Themes\Generic.xaml .

My problem is that these controls will not be released after they are no longer used. If I look at them using SciTech MemoryProfiler, I see that they are held by an instance of System.Windows.Documents.TextEditor , and TextEditor -instance is held in the finalizer queue.
The memory profiler attaches a warning to the TextEditor value, saying "An instance indirectly associated with the finalizer queue."
Does anyone know what is going on here? Is it possible to get directly from a TextBox? Or did I forget something important to implement?

Additional information for implementation:
Implementing some of these derived controls is very simple. In the class constructor, the DefaultStyleKeyPropertys metadata is overridden, and no event handlers are bound to the elements contained in the control template. Sort of:

 public class MyDerivedTextBox : TextBox{ static MyDerivedTextBox(){ DefaultStyleKeyProperty.OverrideMetadata(typeof(MyDerivedTextBox), new FrameworkPropertyMetadata(typeof(MyDerivedTextBox))); } } 

The style (simplified) looks something like this:

 <Style TargetType="{x:Type myApp_controls:MyDerivedTextBox}"> <Setter Property="SnapsToDevicePixels" Value="True"/> <Setter Property="UndoLimit" Value="1"/> <Setter Property="FocusVisualStyle" Value="{x:Null}"/> <Setter Property="Template"> <Setter.Value> <ControlTemplate TargetType="{x:Type myApp_controls:MyDerivedTextBox }"> <Border Name="Border" ... > <ScrollViewer Margin="1" x:Name="PART_ContentHost" /> </Border> </Setter.Value> </Setter> </Style> 

Answer 1

Final queue
The answer to the question about the finalizer queue is that the observed effect is not constant: the finalization simply did not end at the point where I analyzed the memory. The problem here is to understand the tool (and environment) that I used.

Memory leak
The leak itself was a real problem, and it turned out that it was the same thing that I observed in other positions (in the same application). Bindings to the CLR properties of classes that do not implement INotifyPropertyChanged ! http://support.microsoft.com/kb/938416/en-us

This was one of my first WPF projects, and in the meantime it has turned into a huge application. At the time I started, I did not know that WPF had problems with the bindings mentioned above, and during development I tried to do as much as possible with the data binding, but did not care about the targets. Now, after the application has become so large and the number of clients has increased dramatically, these memory problems have come to light (and led to very strange consequences).

After resolving the most problematic bindings, the effect with the finalizer queue declined sharply. It seems that before this memory leak led to the delayed finalization of the object (this is just an assumption, I did not delve into the GC behavior).

Received text fields:
I created a small sample project with such derivative text controls, using them in some stresstests in the memory profiler. As far as I can tell from my observation of the test project, I get from TextBoxes, since I worked perfectly.

Fazit
I can only emphasize the importance of checking Bindings targets during application creation. Otherwise, there will be a lot of work to detect leaks in the application. I hope this explanation helps someone not to make the same mistakes as me.

Answer 2

Not sure if this will change anything, but instead of the static constructor in your control, you tried something like:

 public MyDerivedTextBox() { this.DefaultStyleKey = typeof(MyDerivedTextBox); } 

This is a pattern that I am more familiar with. Perhaps MetaDataOverride is doing something elusive.

Aside, one thing I noticed with some Silverlight memory problems was the unexplained AutomationPeers caused by Tablet PC input services (see http://www.wintellect.com/CS/blogs/sloscialo/archive/2011/04/ 13 / silverlight-memory-leaks-and-automationpeers.aspx ).