Possible unmanaged memory leak when running code using Print API(DocumentPaginator) on Windows 10

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

2019-10-11-15-41-58.png

wpfprinttest.zip

Please refer to attached image and solution.

Same code running on different OS have different result,

Windows 7: Did not observe any unmanaged memory leak.

Windows 10: Observed memory keep increasing and checking in memory profiler shows that there is unmanaged memory leak.

---

Original Comments

Feedback Bot on 10/14/2019, 11:13 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Kok Yong Teo on 10/31/2019, 03:37 PM:

Hi,

Any update for this issue?

Feedback Bot on 11/22/2019, 03:09 PM:

I have detected that for the last 35 days, this issue didn't have much product team activity and a very small amount of new votes or comments. Based on this, its severity, and affected area, it’s my experience that this issue is very unlikely to be fixed.

Kok Yong Teo on 6/17/2020, 08:36 AM:

Hi,

I am still facing this issue and I have submitted a sample application which can clearly reproduce this issue.

Please advise.

---

Original Solutions

(no solutions)

[SamBent]

Investigation into the companion .NET Framework servicing request yielded the following:

• The "leaking" objects are COM objects exposing IXpsOMFontResource, owned by the OS print component.
• They're not actually leaking. They accumulate throughout the course of printing the document, but are released and freed at the end. The "leak" affects very long documents.
• The leak has nothing to do with "DocumentPaginator". That's just a convenient way to generate long documents.
• WPF creates (actually, asks the OS to create) the font objects every 4 pages, giving the print spooler the data it needs to actually print the 4 pages. Waiting longer would hobble the spooler.
• The OS exposed a new print stack in Windows 8.1 (or thereabouts), that WPF uses if available. This explains the difference between Win7 and later.
• We discovered one reference that WPF fails to release in a timely way. Fixing this is necessary to fixing the "leak".
• But not sufficient. The OS print component holds other references that aren't released until the document is done. We don't know any way for WPF to encourage their release.

Thus, this bug needs fixes in WPF and in the OS print stack. Either one by itself won't change anything. WPF can add our fix in .NET 6.0. We've opened a bug for the OS print team to do their part.

[wstaelens]

what is the status of this @SamBent ?

[wstaelens]

Any status updates @SamBent ?

[hiteshkrmsft]

This issue was fixed with PR