Unmanaged memory leak when transitioning between WPFChromium-based controls

[Helder Pinto]

Hi!

I am using RadTransitionControl to perform transitions between heterogeneous views that generally contain pure WPF controls, but that sometimes also use interop-based controls.

I detected recently an unmanaged memory leak in my application when using RadTransition with a WPFChromium-based control (http://wpfchromium.codeplex.com). The application is stable when performing transitions between pure WPF controls. It is still stable when performing transitions between views that contain DirectShow-based controls. However, whenever I use WPFChromium in my transitions, there is a significant, constant unmanaged memory leak (about 20MB/hour with transitions occuring every 30 seconds).

If I take RadTransitionControl off my application, it becomes stable, even when using WPFChromium.

The interesting part is that it does not seem a transition-related problem, because if I keep setting the Content property always to the same view (i.e., the transition does not occur), the unmanaged leak persists. It seems that just using the RadTransitionControl as a container of WPFChromium triggers the leak.


I collected heap data with WinDgb, and there are two kinds of memory blocks leaking:

a) 48 bytes long blocks leaking about 100.000 units every hour. This is the code stack leaking those blocks:
        7744dd6c ntdll!RtlAllocateHeap+0x00000274
        6ebe13ff wpfgfx_v0300+0x000013ff
        6ebe7e69 wpfgfx_v0300!MilChannel_CommitChannel+0x0000008b
        6ebe8940 wpfgfx_v0300!MilChannel_CommitChannel+0x00000b62
        6ebe89bf wpfgfx_v0300!MilChannel_CommitChannel+0x00000be1
        6ebe891b wpfgfx_v0300!MilChannel_CommitChannel+0x00000b3d
        6ebe88ec wpfgfx_v0300!MilChannel_CommitChannel+0x00000b0e
        6ebedede wpfgfx_v0300!MilChannel_AppendCommandData+0x00000961
        6ebec992 wpfgfx_v0300!MilComposition_PeekNextMessage+0x00000078
        6ebec9b3 wpfgfx_v0300!MilComposition_PeekNextMessage+0x00000099
        6ebe73c8 wpfgfx_v0300!MilResource_SendCommand+0x000024d4
        6ebe7437 wpfgfx_v0300!MilResource_SendCommand+0x00002543
        6ebe74b6 wpfgfx_v0300!MilResource_SendCommand+0x000025c2

b) 3686384 bytes long blocks leaking about 2/3 units every hour. This is the code stack leaking those blocks:

        7744dd6c ntdll!RtlAllocateHeap+0x00000274
        73c62423 WindowsCodecs!WPF::ProcessHeapImpl::Alloc+0x00000016
        73c63491 WindowsCodecs!WPF::HrMalloc+0x0000004b
        73c663ba WindowsCodecs!CSystemMemoryBitmap::HrInit+0x0000006c
        73d0d5b9 WindowsCodecs!CLateBitmap::FinalizeBitmap+0x0000002e
        73d0d6b9 WindowsCodecs!CLateBitmap::CopyPixels+0x0000004a
        73d00f7b WindowsCodecs!IWICBitmapSource_CopyPixels_Proxy+0x00000023

Are you aware situations leading to unmanaged memory leaks with WPFChromium or any other C++ wrapper-based control? Do you suggest any work-around or further debugging?


Thanks!

Helder Pinto

[Helder Pinto]

Hi, again!


Forget about the last message regarding unmanaged leaks with WPFChromium inside Telerik's RadTransitionControl. I've further isolated the problem and I am sure the leak is not caused by any of the mentioned components.

Sorry for the inconvenience.

Regards,

Helder