Opening XPS document in .Net causes a memory leak

Question

The following code snippet illustrates a memory leak when opening XPS files. If you run it and watch the task manager, it will grow and not release memory until the app exits.

'****** Console application BEGINS.

Module Main

    Const DefaultTestFilePath As String = "D:\Test.xps"
    Const DefaultLoopRuns As Integer = 1000

    Public Sub Main(ByVal Args As String())
        Dim PathToTestXps As String = DefaultTestFilePath
        Dim NumberOfLoops As Integer = DefaultLoopRuns

        If (Args.Count >= 1) Then PathToTestXps = Args(0)
        If (Args.Count >= 2) Then NumberOfLoops = CInt(Args(1))

        Console.Clear()
        Console.WriteLine("Start - {0}", GC.GetTotalMemory(True))
        For LoopCount As Integer = 1 To NumberOfLoops

            Console.CursorLeft = 0
            Console.Write("Loop {0:d5}", LoopCount)

            ' The more complex the XPS document and the more loops, the more memory is lost.
            Using XPSItem As New Windows.Xps.Packaging.XpsDocument(PathToTestXps, System.IO.FileAccess.Read)
                Dim FixedDocSequence As Windows.Documents.FixedDocumentSequence

                ' This line leaks a chunk of memory each time, when commented out it does not.
                FixedDocSequence = XPSItem.GetFixedDocumentSequence
            End Using
        Next
        Console.WriteLine()
        GC.Collect() ' This line has no effect, I think the memory that has leaked is unmanaged (C++ XPS internals).
        Console.WriteLine("Complete - {0}", GC.GetTotalMemory(True))

        Console.WriteLine("Loop complete but memory not released, will release when app exits (press a key to exit).")
        Console.ReadKey()

    End Sub

End Module

'****** Console application ENDS.

The reason it loops a thousand times is because my code processes lots of files and leaks memory quickly forcing an OutOfMemoryException. Forcing Garbage Collection does not work (I suspect it is an unmanaged chunk of memory in the XPS internals).

The code was originally in another thread and class but has been simplified to this.

Any help greatly appreciated.

Ryan

Answer 1

Well, I found it. It IS a bug in the framework and to work around it you add a call to UpdateLayout. Using statement can be changed to the following to provide a fix;

        Using XPSItem As New Windows.Xps.Packaging.XpsDocument(PathToTestXps, System.IO.FileAccess.Read)
            Dim FixedDocSequence As Windows.Documents.FixedDocumentSequence
            Dim DocPager As Windows.Documents.DocumentPaginator

            FixedDocSequence = XPSItem.GetFixedDocumentSequence
            DocPager = FixedDocSequence.DocumentPaginator
            DocPager.ComputePageCount()

            ' This is the fix, each page must be laid out otherwise resources are never released.'
            For PageIndex As Integer = 0 To DocPager.PageCount - 1
                DirectCast(DocPager.GetPage(PageIndex).Visual, Windows.Documents.FixedPage).UpdateLayout()
            Next
            FixedDocSequence = Nothing
        End Using

Answer 2

Ran into this today. Interestingly, when I gazed into things using Reflector.NET, I found the fix involved calling UpdateLayout() on the ContextLayoutManager associated with the current Dispatcher. (read: no need to iterate over pages).

Basically, the code to be called (use reflection here) is:

ContextLayoutManager.From(Dispatcher.CurrentDispatcher).UpdateLayout();

Definitely feels like a small oversight by MS.

For the lazy or unfamiliar, this code works:

Assembly presentationCoreAssembly = Assembly.GetAssembly(typeof (System.Windows.UIElement));
Type contextLayoutManagerType = presentationCoreAssembly.GetType("System.Windows.ContextLayoutManager");
object contextLayoutManager = contextLayoutManagerType.InvokeMember("From",
BindingFlags.InvokeMethod | BindingFlags.Static | BindingFlags.NonPublic, null, null, new[] {dispatcher});
contextLayoutManagerType.InvokeMember("UpdateLayout", BindingFlags.InvokeMethod | BindingFlags.NonPublic | BindingFlags.Instance, null, contextLayoutManager, null);

FxCop will complain, but maybe it's fixed in the next framework version. The code posted by the author seems to be "safer" if you would prefer not to use reflection.

HTH!

Answer 3

I can't give you any authoritative advice, but I did have a few thoughts:

• If you want to watch your memory inside the loop, you need to be collecting memory inside the loop as well. Otherwise you will appear to leak memory by design, since it's more efficient to collect larger blocks less frequently (as needed) rather than constantly be collecting small amounts. In this case the scope block creating the using statement should be enough, but your use of GC.Collect indicates that maybe something else is going on.
• Even GC.Collect is only a suggestion (okay, very strong suggestion, but still a suggestion): it doesn't guarantee that all outstanding memory is collected.
• If the internal XPS code really is leaking memory, the only way to force the OS to collect it is to trick the OS into thinking the application has ended. To do that you could perhaps create a dummy application that handles your xps code and is called from the main app, or moving the xps code into it's own AppDomain inside your main code may be enough as well.

Answer 4

Add UpdateLayout cannot solve the issue. According to http://support.microsoft.com/kb/942443, "preload the PresentationCore.dll file or the PresentationFramework.dll file in the primary application domain" is needed.

Answer 5

Interesting. The problem is still present in .net framework 4.0. My code was leaking ferociously.

The proposed fix -- where UpdateLayout is called in a loop immediately after creation of the FixedDocumentSequence did NOT fix the problem for me on a 400 page test document.

However, the following solution DID fix the problem for me. As in previous fixes, I moved the call to GetFixedDocumentSequence() outside the for-each-page loop. The "using" clause... fair warning that I'm still not sure it's correct. But it's not hurting. The document is subsequently re-used to generate page previews on-screen. So it doesn't seem to hurt.

DocumentPaginator paginator 
     =  document.GetFixedDocumentSequence().DocumentPaginator;
int numberOfPages = paginator.ComputePageCount();


for (int i = 0; i < NumberOfPages; ++i)
{
    DocumentPage docPage = paginator.GetPage(nPage);
    using (docPage)   // using is *probably* correct.
    {
        //  VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

        ((FixedPage)(docPage.Visual)).UpdateLayout();

        //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        //  Adding THAT line cured my leak.

        RenderTargetBitmap bitmap = GetXpsPageAsBitmap(docPage, dpi);

        .... etc...
    }

}

In reality, the fix line goes inside my GetXpsPageAsBitmap routine (ommited for clarity), which is pretty much identical to previously posted code.

Thanks to all who contributed.