WPF Memory Leak but only when total document footprint exceeds threshold

WPF Memory Leak Problem. Memory stable with small docum开发者_Python百科ents, but grows until OOM exception with large documents.

Background:

We've developed a WPF application for controlling a dynamic display. There is a Design component, where the user lays out the display document, and a document Display component.

Elements in the display can contain text and/or graphics. Each element can cycle through different strings or images using various transitions--scrolling, fading, flashing, etc.

Problem:

The problem is with an element displaying graphics, with a cross-fade between different graphics. The fade is accomplished by animating the opacity property of two WPF image controls (one for incoming, one for outgoing).

Everything works fine as long as the total memory footprint of the application while running is below a (not yet precisely defined) threshold. When the total foot print increases (for example, by adding another graphic element with a large graphic) then the total memory used by the application begins to grow, and I'm eventually presented with an OOM exception. The large graphic on its own, or the fading graphics on its own do not have the memory leak problem, but only the combination.

Has anyone else seen similar behavior? Any ideas for a solution? I'm guessing that the problem has something to do with Large Object Heap fragmentation, but this is only a guess.

Unfortunately, I don't have sample code to post as this is part of a larger solution. I will try to create a sample app that illustrates this behavior and update my post.

---

To diagnose this properly you could start with a minidump at or just before the point of crash, and use a suitable debugger (WinDbg with SOS, for me) to work out what's going on. In Win7 (not in XP, not sure about Vista) you can generate a minidump by right-clicking a application/process in task manager and selecting the appropriate option.

If it's not large-object-heap, this it could be GC-related. Presumably there is an overhead of associated classes with each element you're adding - are there a lot of transient classes being created (say, on each render of the display)? It could be that the memory pressure is causing GC to push lots of objects into Gen1 and/or Gen2, and that's adding to the memory pressure.

The SOS/WinDbg command "!eeheap -gc" will print the size of your GC generations, which might show you that Gen2 is filling up as your app's data increases.