Installing .NET 4.8 breaks some WPF applications

[jpapp05]

We have installed the released version of .NET 4.8 on a bunch of Windows 10 machines and VMs as part of our internal testing to make sure there are no compatibility issues with newer versions of the framework and our software. During this testing we discovered that 4.8 is breaking a bunch of 4.7.2 WPF .NET Framework software.

Uninstalling the 4.8 .NET update fixes the issue.

I tried investigating the issue further under the debugger but strangely everything seems to run correctly (no exceptions caught by the debugger), but all of the popup windows are black with no interactivity possible. In some cases, the windows are completely invisible, making it look like the application is hung but it seems to be processing messages fine, just locked in a modal state.

We also noticed that it impacts other applications too; for example, Snoop (which is an old WPF diagnostic tool) runs into the same blank/black window issue.

Here is an example of what it looks like:

Finally, it does not impact all of our applications, only some; not sure why.

The one that is the most concerning to us is an Excel add-in. If our customers install the .NET update, we are currently out of luck; though, most of them are in the financial/corporate sector and they typically don’t install anything without extensive testing and a complex certification process, so at least we should have some time.

I’m not sure who I need to contact but this is a serious problem for us as it has the potential of impacting software that we license commercially. I have no problem with a solution that either requires us to change our software or applying a fix to and/or update .NET 4.8, but we need something.

Any help or direction to head in would be greatly appreciated.

Thanks,
James

[jpapp05]

I was able to narrow this down a bit.

It is only affecting our software that runs under Excel. This includes all versions of Office we support (2010, 2013, 2016 and 2019), both 32-bit and 64-bit (where applicable). Running with or without admin rights makes no difference.

Snoop actually seems fine; the issue is that, if you try to use it to snoop one of our applications with a blank window, it ends up creating a blank window as well.

In fact, when I tried to use the WPF tree visualizer from within Visual Studio, it is only able to find the top-level window or dialog and shows no children.

Interestingly, everything is allocated and accessible from within the debugger, and if you work through some of the properties you can find the correct children in the right places. It seems like the visual tree is missing as if it was not able to apply templates or instantiate.

The blank window issue impacts everything we display including both popups and UI we show within Excel COM panels. Stuff that Excel draws works fine, like the ribbon as well as non-WPF components (WIN32).

I tried enabling all WPF diagnostic trace messages and nothing out of the ordinary is flagged or shown.

We can repro this on any machine that we install .NET 4.8, including VMs. We only support 64-bit operating systems and only have tested Windows 10 from build 1709 and up. We have not yet tested to see if this impacts Windows 7.

Thanks,
James

[jpapp05]

Sorry, I did not mean to close the issue...

[Alois-xx]

Could it be that the enumerator of WeakHashSet/WeakDictionary<TKey,TValue> is now wrongly implemented. If I am not wrong and the decompiler was doing its thing correctly the Enumerator always will try to enumerate a null local value:

  public IEnumerator<T> GetEnumerator()
        {
            WeakHashSet<T> ts = null;
            foreach (object key in ts._hashTable.Keys)  // how can that work when ts is null?
            {

I do not find usages of this one in .NET 4.7.2 but perhaps it is now used in 4.8?

[matthew-a-thomas]

@Alois-xx I'm not seeing that issue in the source for either WeakHashSet or WeakDictionary:
https://referencesource.microsoft.com/#PresentationFramework/src/Framework/MS/Internal/WeakHashSet.cs,99
https://referencesource.microsoft.com/#PresentationFramework/src/Framework/MS/Internal/WeakDictionary.cs,345

[GisliEiriksson]

We have the exact same issue:

Going back to .Net 4,7.2 also fixes it for us.

Our application is a Winforms application, but we have som WPF dialogs which all seems to break by updating to .Net 4.8, the dialogs are shown using System.Windows.ShowDialog().

If you need more information please let me know.

[SamBent]

@GisliEiriksson - can you provide a minimal app that repros the problem?

[vatsan-madhavan]

What happens when you switch Excel's display settings to compatibility mode ?

Many Excel/Office addins use a framework that uses WinForms as the root of the UI tree to transition from native to managed layer, and then uses WindowsFormsIntegration to layer addition controls udder the WinForms ElementHost. The structure you are observing seems in line with that kind of design.

Snoop, Visual Studio's Live Visual Tree feature etc. stop being able to follow a WPF UI tree when the chain - so to speak - breaks due to a transition from WPF to a non-WPF technology. Depending on the exact scenario, it might sometimes work.

[vatsan-madhavan]

One more thought - we took some fixes in .NET 4.8 for WPF all the way close to release and even some scheduled for immediately after released.

When you tried this in April '19, was it on the final version of .NET 4.8 or was it on a pre-release version? Either way, would you mind trying again on latest .NET 4.8 just to be sure that this problem indeed reproduces for you?

[GisliEiriksson]

We located the problem, we had some code that attempted to ensure we used a specific windows theme:

string themeName = "Aero";
string themeColor = "normalcolor";

Type themeWrapper = Type.GetType("MS.Win32.UxThemeWrapper, PresentationFramework, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35");

FieldInfo themeNameField = themeWrapper.GetField("_themeName", BindingFlags.NonPublic | BindingFlags.Static);

themeNameField.SetValue(null, themeName);

FieldInfo themeColorField = themeWrapper.GetField("_themeColor", BindingFlags.NonPublic | BindingFlags.Static);

themeColorField.SetValue(null, themeColor);

Removing that solved the issue for us.

[GisliEiriksson]

We have a small example program here:
BlackWindow.zip

[jpapp05]

If it helps, this was our exact problem as well. We restricted the WPF theme to a single version to make testing, maintenance and compatibility easier (during the days of many OSes). We did this by making a copy of a single theme (Aero) across all controls and storing it internally. Interestingly, this only impacted our add-in to Excel and not our desktop applications. Our theory was that in Excel we could not change or tweak the manifest and configurations files for the exe (like we do on the desktop) as we were not the owner. Or it was how we configured our DPI support in our desktop apps, something we could not change in Excel. Unfortunately, we never determined the actual reason.

Further testing seemed to point that the issue was introduced when additional high-DPI capabilities where added to .NET 4.8. If we took our blank screen app and change the DPI settings for the system, moved it across different monitors, etc., randomly, would could sometime get the application to pop, and render correctly.

Once this happened, switching back to the default screen/display configuration and DPI settings would not revert it back to a black screen. It was as if the new control templates or the functions they invoked where changed in some way, that they were required for internal initialization; without this, it was as if the window was being rendered off screen or with invalid sizes.

In any case, we just disabled our internal themes, which are no longer really needed given we only support a single OS, that being Windows 10 1809 or greater. It was more of an issue when we supported XP, 7, 8, 8.1, and 10; not to mention the various server editions where admins tend to use the classic theme (or worse disable the theming service altogether).

It was unfortunate that this was a breaking change for us between 4.7.2 and 4.8. Since, 4.8 installs on top of 4.7.2, users would brick the add-in, simply by running Windows update.

We hope our conversion to .NET Core will help us isolate these issues going forward.

James

[SamBent]

Does anyone have a repro that doesn't use private reflection to spoof the theme? If not, I'm going to close the issue - theme-spoofing is not supported (a special case of the general rule that anything that depends on private reflection is not supported).

It sounds like the Aero (Win7) theme does something that doesn't work in high-DPI (or per-monitor aware) situations introduced in Win10. We don't test that combination, as it can't arise using public API.

[SamBent]

Closing this issue, as it involves an unsupported scenario (using private reflection).

[YasminJahid]

Can anybody tell me the solution for setting up a theme in 4.8 framework ?

I am trying to set the aero theme for my wpf application but during runtime controls are growing in size. What could be the solution for this issue ?