Revealing the native memory pressure of WPF Bitmaps

A couple of months ago, I bumped into an interesting memory leak with regards to the ElementHost WinForms control that is the primary means to host WPF content in any WinForms environment. I was able to trace back the root cause to a known issue, that I just call "the memory pressure bug". Alois did a great job in summarizing the story.
 
The basic idea to monitor native memory pressure of managed objects has been there for years in .NET, but for WPF bitmaps they didn't do a very good job at it. As a result, the GC had no idea that a collection should be induced if - for instance - many wpf bitmaps held large amounts of native resources. This introduced all kinds of problems you can think of, like virtual address space fragmentation and OutOfMemory exceptions coming from both the managed and the native world. While investigating the issue I came up with a handy WinDbg script, that can tell you how much the native overhead is for your wpf bitmaps in terms of memory usage.

[bmp.txt]

$$ Run with $$>a<"bmp.txt" $$ Created by Tamas Vass (2016) $$ This script displays the GC memory pressure of System.Windows.Media.Imaging.BitmapSourceSafeMILHandle objects $$  that basically represent the amount of unmanaged memory needed by them (x86 only) $$ MT of BitmapSourceSafeHandle r @$t3=0 $$ Running !dumpheap -type System.Windows.Media.Imaging.BitmapSourceSafeMILHandle -short seems to fail sporadically $$  but !dumpheap -mt <mtaddr> -short is stable, so let's fetch the Method Table address and use that .foreach /pS 7 /ps 1 (i {!name2ee PresentationCore.dll!System.Windows.Media.Imaging.BitmapSourceSafeMILHandle}) {     r @$t3=${i}     .printf "BitmapSourceSafeHandle MT: %x", @$t3     .break } $$ Count of valid r @$t0=0 $$ Count of invalid r @$t1=0 $$ Size in bytes r @$t2=0 $$ Print header .printf "\n\nAddress -> Size in bytes" .foreach (var {!DumpHeap /d -mt @$t3 -short}) {     .if ($vvalid(poi(${var}+0x10),4)==1)     {         r @$t0=@$t0+1         r @$t2=@$t2+dwo((poi(${var}+0x10))+4)         .printf "\n%x -> %u", ${var}, qwo((poi(${var}+0x10))+4)     }     .else     {         r @$t1=@$t1+1         .printf "\n%x -> NULL", ${var}     } } .printf "\n\nTotal: %u", @$t0+@$t1 .printf "\n |- Valid: %u", @$t0 .printf "\n |- Invalid: %u", @$t1 .foreach /pS 1 /ps 1 (i {?? @$t2 / 1048576.0f}) {        .printf "\n\nTotal size: %u bytes (${i} MB)", @$t2     .break } .printf "\n"

If you're running a .NET version older than 4.6.2, then you can easily reproduce the leak by following these steps:
1. Create a WinForms app and dock an ElementHost in the middle of your Form
2. In code-behind, add any WPF content to the ElementHost, by setting its Child property
3. Start the application
4. Resize your Form a few times (the closer the Form to being full screen, the better)

Resizing causes the ElementHost, to create a wpf bitmap of its rendered background. Don't ask me why, this is what happens. Using the script above and performing a couple of window resizes I got this output:

0:015> $$>a<"bmp.txt" BitmapSourceSafeHandle MT: 547519ac Address -> Size in bytes 2dd8e24 -> NULL 2dd8e50 -> NULL 2dd8e9c -> NULL <removed 610 entries for brevity> 2dfdcf0 -> 6371508 303fa68 -> NULL 303fa80 -> 6371508 Total: 616  |- Valid: 180  |- Invalid: 436 Total size: 1190832240 bytes (1135.67 MB)

Nice, isn't it? I had 1135 MB of native garbage and the GC had absolutely no idea about it. Of course eventually, when garbage collection occurs these objects will go away, but as they have a finalizer, they require 2 collections and their finalizers run in-between, but more on that in an other article of mine.

Fortunately, .NET 4.6.2 solves this issue in a nice way - by maintaining and taking into account the native memory pressure when determining the need for a collection. See GC.AddMemoryPressure for further details.