XPS documents memory leak (System.Windows.ContextLayoutManager+LayoutQueue+Request and XpsDocument.GetFixedDocumentSequence())

[wstaelens]

Description

Situation: we have a windows service running in .net 6 with an admin panel in asp.net core 6 (+ blazor + pri nt drivers etc...)

(complex solution, but for the memory leak mainly does this:)

PDF files dumped in hotfolder 
--> opened by our code and converted to XPS 
--> modifications to XPS file (e.g. adding barcode) 
--> converting back to PDF the single (or merged) modified XPS documents.
--> dumping the resulting PDF files to a folder

When processing 5 documents, we see an increase of memory with ±1.5MB memory because System.Windows.ContextLayoutManager+LayoutQueue+Request and this is because of being called by XpsDocument.GetFixedDocumentSequence() are never released or GC'd.

Eventually when our service runs for a time, it just runs out of memory.

Reproduction Steps

unable to create a minimal repro-solution, our software should be run and configured to reproduce (if needed somebody can get in contact with me in PM).

I guess these code in stackoverflow topics will demonstrate a similar issue:
https://stackoverflow.com/questions/218681/opening-xps-document-in-net-causes-a-memory-leak
https://stackoverflow.com/questions/51463348/c-sharp-reading-xps-causing-memory-leak
https://stackoverflow.com/questions/12703796/creating-fixed-document-causes-memory-leak
https://social.msdn.microsoft.com/Forums/en-US/becc0d42-908a-435c-a4ff-175843b83ad8/memory-leak-while-opening-the-xps-document-in-documentviewer
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b7fec24a-138b-4d3b-bdb3-cd4f0785e4ac/populating-collection-with-rendertargetbitmap-via-thread-causes-memory-leak

Expected behavior

Processing XPS documents should release memory.

Actual behavior

When processing XPS documents the memory increases, after processing 5.000 - 10.000 documents, our service crashes due to OutOfMemory. (depending on the hardware and type of documents this number can be higher/lower...)

Regression?

We've seen this issue in every version of .net core, seen it last in .net 5 and after upgrading to .net 6 it is still present.

This memory leak and the issues have been out there already for a while (also in .NET Framework).
see:

https://stackoverflow.com/questions/218681/opening-xps-document-in-net-causes-a-memory-leak
https://stackoverflow.com/questions/51463348/c-sharp-reading-xps-causing-memory-leak
https://stackoverflow.com/questions/12703796/creating-fixed-document-causes-memory-leak
https://social.msdn.microsoft.com/Forums/en-US/becc0d42-908a-435c-a4ff-175843b83ad8/memory-leak-while-opening-the-xps-document-in-documentviewer
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b7fec24a-138b-4d3b-bdb3-cd4f0785e4ac/populating-collection-with-rendertargetbitmap-via-thread-causes-memory-leak

Known Workarounds

No working workaround for us... :sad

Configuration

VS 2019 Pro 16.11.11
VS 2022 17.2.0 Preview 2.0
Issue occurred in every version we've been using .net 5, .net 6

Windows 10 21H1
Windows 11 21H2

Other information

suggested fixes as preloading PresentationCore and/or PresentationFramework don't work (https://web.archive.org/web/20110404040352/http://support.microsoft.com/kb/942443)

Calling updatelayout as suggested in stackoverflow also doesn't seem to work:
https://stackoverflow.com/questions/218681/opening-xps-document-in-net-causes-a-memory-leak
https://stackoverflow.com/questions/51463348/c-sharp-reading-xps-causing-memory-leak
https://stackoverflow.com/questions/12703796/creating-fixed-document-causes-memory-leak
https://stackoverflow.com/questions/50560580/memory-leak-at-xpsdocument-getfixeddocumentsequence
https://social.msdn.microsoft.com/Forums/en-US/becc0d42-908a-435c-a4ff-175843b83ad8/memory-leak-while-opening-the-xps-document-in-documentviewer
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b7fec24a-138b-4d3b-bdb3-cd4f0785e4ac/populating-collection-with-rendertargetbitmap-via-thread-causes-memory-leak

We really hope the team investigates some time in XPS as it is really terrible, and it always being updated to "Future", "Future", "Future" 😠 .
See also:

• XPS documents from print driver are terribly slow #51930

• XPS documents in .NET Core can't be opened wpf#3546

• XPS documents in .NET Core can't be opened #51929 (comment)

• .NET 5 - Printing - XPS requires STA Threads wpf#4000

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[filipnavara]

Since this issue is about WPF it may be more appropriate to file it at https://github.com/dotnet/wpf.

[wstaelens]

Since this issue is about WPF it may be more appropriate to file it at https://github.com/dotnet/wpf.

well i've created a ticket in the past in wpf and it was redirected to runtime because the root cause was in another library. So I really don't know anymore where XPS belongs. We just want to see it fixed after all these years.

[ghost]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Situation: we have a windows service running in .net 6 with an admin panel in asp.net core 6 (+ blazor + pri nt drivers etc...)

(complex solution, but for the memory leak mainly does this:)

PDF files dumped in hotfolder 
--> opened by our code and converted to XPS 
--> modifications to XPS file (e.g. adding barcode) 
--> converting back to PDF the single (or merged) modified XPS documents.
--> dumping the resulting PDF files to a folder

When processing 5 documents, we see an increase of memory with ±1.5MB memory because System.Windows.ContextLayoutManager+LayoutQueue+Request and this is because of being called by XpsDocument.GetFixedDocumentSequence() are never released or GC'd.

Eventually when our service runs for a time, it just runs out of memory.

Reproduction Steps

unable to create a minimal repro-solution, our software should be run and configured to reproduce (if needed somebody can get in contact with me in PM).

I guess these code in stackoverflow topics will demonstrate a similar issue:
https://stackoverflow.com/questions/218681/opening-xps-document-in-net-causes-a-memory-leak
https://stackoverflow.com/questions/51463348/c-sharp-reading-xps-causing-memory-leak
https://stackoverflow.com/questions/12703796/creating-fixed-document-causes-memory-leak
https://social.msdn.microsoft.com/Forums/en-US/becc0d42-908a-435c-a4ff-175843b83ad8/memory-leak-while-opening-the-xps-document-in-documentviewer
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b7fec24a-138b-4d3b-bdb3-cd4f0785e4ac/populating-collection-with-rendertargetbitmap-via-thread-causes-memory-leak

Expected behavior

Processing XPS documents should release memory.

Actual behavior

When processing XPS documents the memory increases, after processing 5.000 - 10.000 documents, our service crashes due to OutOfMemory. (depending on the hardware and type of documents this number can be higher/lower...)

Regression?

We've seen this issue in every version of .net core, seen it last in .net 5 and after upgrading to .net 6 it is still present.

This memory leak and the issues have been out there already for a while (also in .NET Framework).
see:

https://stackoverflow.com/questions/218681/opening-xps-document-in-net-causes-a-memory-leak
https://stackoverflow.com/questions/51463348/c-sharp-reading-xps-causing-memory-leak
https://stackoverflow.com/questions/12703796/creating-fixed-document-causes-memory-leak
https://social.msdn.microsoft.com/Forums/en-US/becc0d42-908a-435c-a4ff-175843b83ad8/memory-leak-while-opening-the-xps-document-in-documentviewer
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b7fec24a-138b-4d3b-bdb3-cd4f0785e4ac/populating-collection-with-rendertargetbitmap-via-thread-causes-memory-leak

Known Workarounds

No working workaround for us... :sad

Configuration

VS 2019 Pro 16.11.11
VS 2022 17.2.0 Preview 2.0
Issue occurred in every version we've been using .net 5, .net 6

Windows 10 21H1
Windows 11 21H2

Other information

suggested fixes as preloading PresentationCore and/or PresentationFramework don't work (https://web.archive.org/web/20110404040352/http://support.microsoft.com/kb/942443)

Calling updatelayout as suggested in stackoverflow also doesn't seem to work:
https://stackoverflow.com/questions/218681/opening-xps-document-in-net-causes-a-memory-leak
https://stackoverflow.com/questions/51463348/c-sharp-reading-xps-causing-memory-leak
https://stackoverflow.com/questions/12703796/creating-fixed-document-causes-memory-leak
https://stackoverflow.com/questions/50560580/memory-leak-at-xpsdocument-getfixeddocumentsequence
https://social.msdn.microsoft.com/Forums/en-US/becc0d42-908a-435c-a4ff-175843b83ad8/memory-leak-while-opening-the-xps-document-in-documentviewer
https://social.msdn.microsoft.com/Forums/vstudio/en-US/b7fec24a-138b-4d3b-bdb3-cd4f0785e4ac/populating-collection-with-rendertargetbitmap-via-thread-causes-memory-leak

We really hope the team investigates some time in XPS as it is really terrible, and it always being updated to "Future", "Future", "Future" 😠 .
See also:

• XPS documents from print driver are terribly slow #51930

• XPS documents in .NET Core can't be opened wpf#3546

• XPS documents in .NET Core can't be opened #51929 (comment)

• .NET 5 - Printing - XPS requires STA Threads wpf#4000

Author:	wstaelens
Assignees:	-
Labels:	area-Meta, untriaged
Milestone:	-

[danmoseley]

This does indeed appear to be in WPF code. @singhashish-wpf this seems to be an issue with widespread impact - is there someone on your team able to investigate?

[ericstj]

@wstaelens it does look like this is a WPF issue due to the types being leaked and the backing information shared. I see you've opened an issue in WPF. I'm going to close this one.

well i've created a ticket in the past in wpf and it was redirected to runtime because the root cause was in another library.

Sometimes this happens and it's no fault of yours. As we triage issues, we learn more about the root cause and sometimes need to transfer the issue to another area. If you're ever lacking traction on issues in dotnet/runtime you can reach out to the owners we define in https://github.com/dotnet/runtime/blob/main/docs/area-owners.md