{StaticResource} references are broken for XPS Paths after December2022 security patch

[ezolenko]

• Windows version: (22H2 19045.2364)
• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes

Problem description:

{StaticResource} references on Path elements are not loaded in FixedPage after recent security patch.

Actual behavior:

FixedPage fails to load Path elements that have static resource references. Path data is set to null so those elements are not rendered with RenderTargetBitmap for example.

Expected behavior:

Path references are loaded.

Minimal repro:

• Make sure December 13, 2022, security updates for .NET Framework is installed
• Load attached xps file: p1.zip

var filePath = "<path>";
var doc = new XpsDocument(filePath, FileAccess.Read);
var seq = doc.GetFixedDocumentSequence();

foreach (var docRef in seq.References)
{
	var fixedDoc = docRef.GetDocument(false);
	foreach (var page in fixedDoc.Pages)
	{
		var fixedPage = page.GetPageRoot(false);
		foreach (var element in fixedPage.Children)
		{
			Debug.Assert(((System.Windows.Shapes.Path)element).Data != null);
		}
	}
}

You can probably reproduce this by printing most PDF files with some text to Microsoft XPS Document Writer and then trying to present it in a WPF app (that is not Windows XPS Viewer).

Workaround:

Alternate Workaround from kb5022083 (allowing all XPS types) works. I haven't figured out which type needs to be specifically allowed for this particular case. The script they have in the first part to allow certain types explicitly doesn't work.

https://support.microsoft.com/en-au/topic/kb5022083-change-in-how-wpf-based-applications-render-xps-documents-a4ae4fa4-bc58-4c37-acdd-5eebc4e34556

[singhashish-wpf]

We are checking this further. Will update soon.

[wstaelens]

https://developercommunity.visualstudio.com/t/KB5022083---Broken-XPS-prinintg-in-WPF-A/10233950?q=xps

[bradleypeet]

We're seeing the same issue and have some very unhappy customers right now.

[pchaurasia14]

We're sorry that the update broke your application. Rest assured, we're working to the fix the issue at top priority.

[gejosdev]

This issue leaves us with lots of customers not just "unhappy" but unable to invoice their work! This is a really money burning problem!!

[pchaurasia14]

@gejosdev - I agree the situation is not ideal and we're doing everything we can to ensure we restore the functionality without resurrecting the vulnerability. For now, you may attempt to use the workaround mentioned in this KB article.

[wstaelens]

@gejosdev this one also: dotnet/runtime#51929, #3546
but still waiting, after years.... it is not fun to get to your customers/clients and to tell them Microsoft didn't fix it yet.... for something that worked in .NET Framework.

We just take this one also.... The fix takes ages, means the team is not really into XPS/Printing...
Wish i could redirect all my phone calls to the WPF team.

[Toemsel]

There is also a second issue with that one: When you merge XPS files with the following method, the final XpsDocument lacks resources. I did extract the .XPS file and investigated the *.fpage files and encountered, that the ResourceDictionary is missing for the FixedPage after using the method below.

        public void MergeXpsDocument(string newFile, List<XpsDocument> sourceDocuments)
        {
            XpsDocument xpsDocument = new XpsDocument(newFile, System.IO.FileAccess.ReadWrite);
            XpsDocumentWriter xpsDocumentWriter = XpsDocument.CreateXpsDocumentWriter(xpsDocument);
            FixedDocumentSequence fixedDocumentSequence = new FixedDocumentSequence();

            foreach (XpsDocument doc in sourceDocuments)
            {
                FixedDocumentSequence sourceSequence = doc.GetFixedDocumentSequence();
                foreach (DocumentReference dr in sourceSequence.References)
                {
                    DocumentReference newDocumentReference = new DocumentReference();
                    newDocumentReference.Source = dr.Source;
                    (newDocumentReference as IUriContext).BaseUri = (dr as IUriContext).BaseUri;
                    FixedDocument fd = newDocumentReference.GetDocument(true);
                    newDocumentReference.SetDocument(fd);
                    fixedDocumentSequence.References.Add(newDocumentReference);
                }
            }
            xpsDocumentWriter.Write(fixedDocumentSequence);
            xpsDocument.Close();
        }

[pchaurasia14]

We've released an OOB package that should address the XPS compatibility issues.
You may refer to this link for more information on installing the fix.

[VikramanKesavan]

Much appreciated! OOB addressed the issue with WPF print/print-preview of generated XPS documents with inline images.

[wstaelens]

Thanks!

[gejosdev]

(When) will this OOB be included in the regular Windows Update rollouts? We tested it as well and can confirm it fixes the broken display of images. We need that rolled out asap - it's no solution to send complex instructions to hundreds of customers, many of whom are inexperienced with computers.

[pchaurasia14]

@gejosdev - We are working to release the fix along with the next security update. We will keep this thread posted.

[gejosdev]

2 more months have passed without release. Do you even realize how URGENT this issue is, how much damage was already done to customers not able to invoice, our customer relationship, our turnaround, our time spent?
Why is this not rolled out?
Does Microsoft want us to move on to other platforms/IDEs?

[pchaurasia14]

@gejosdev - The fix will be rolled out in 5B (mid-May) which should address the issue (without having to rely on OOB fix).

[singhashish-wpf]

There is an unexpected delay in this release. Will keep the thread posted for the updates.

[wstaelens]

What is the status? (powershell fix doesn't work at some customers, only registry fix works).

[gejosdev]

An incredibly faulty "security fix", dumped on all customers, crippling hard work and reputation of developers and companies worldwide, empty promises, no communication - just a too complex manual bugfix that could and should have been rolled out automatically since January. Half a year! This is no environment for serious software development.

[wstaelens]

An incredibly faulty "security fix", dumped on all customers, crippling hard work and reputation of developers and companies worldwide, empty promises, no communication - just a too complex manual bugfix that could and should have been rolled out automatically since January. Half a year! This is no environment for serious software development.

Join the fun @ dotnet/runtime#78629

[pchaurasia14]

We're apologize for the inconvenience caused. However, the reasons for delay in shipping the fix are beyond our immediate control. We're working with our partner teams to get this released as soon as possible.

[wstaelens]

@pchaurasia14 what is the status?....

[pchaurasia14]

Update - The security patch is now available for .NET Framework as well as .NET Core .

This should restore the StaticResource behavior.