Wpf: WPF program crashes with the nightly build sdk

Created on 6 Jul 2019 · 11Comments · Source: dotnet/wpf

.NET Core Version: 3.0.100-preview8-012893
Windows version: 10.0.18392.1000
Does the bug reproduce also in WPF for .NET Framework 4.8?: No

Problem description:
The program just crashes.
Actual behavior:
```
System.TypeLoadException
HResult=0x80131522
Message=Could not load type 'System.Xaml.Permissions.XamlAccessLevel' from assembly 'System.Security.Permissions, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
Source=PresentationFramework
StackTrace:
at System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream)
at System.Windows.Application.LoadBamlStreamWithSyncInfo(Stream stream, ParserContext pc)
at System.Windows.Application.LoadComponent(Uri resourceLocator, Boolean bSkipJournaledProperties)
at System.Windows.Application.DoStartup()
at System.Windows.Application.<.ctor>b__1_0(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(Object obj)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
at System.Windows.Threading.Dispatcher.Run()
at System.Windows.Application.RunDispatcher(Object ignore)
at System.Windows.Application.RunInternal(Window window)
at System.Windows.Application.Run()
at CoreWPFPreview8CrashTest.App.Main()

 **Expected behavior:**
 It shouldn't crash.
 **Minimal repro:**

dotnet new wpf
dotnet run
```

hot issue-type-bug regression

Source

Berrysoft

Most helpful comment

I can confirm it working with 3.0.100-preview8-012985, hanks for fixing this!!

Lakritzator on 10 Jul 2019

👍2

All 11 comments

Thanks for reporting this. This is due to a change made in CoreFX (by us) to move the XamlAccessLevel type out of System.Security.Permissions and into System.Windows.Extensions.

Unfortunately, this causes breaks in WPF as we have yet to update to the new location. Normally this would cause a failed DARC dependency push, but we have currently disabled our DRTs from running during PR builds because of issues with builds taking longer than an hour to complete due to the Helix infrastructure taking a long time to spin up VMs for test purposes.

This change causes all DARC PRs to succeed and be merged. So this break made it to the daily build when it otherwise would not have without the companion fix in WPF. We're working on getting these changes synced up and fixing the daily build.

rladuca on 7 Jul 2019

👍1

Thanks for your reply! I'll wait for the fix.

Berrysoft on 7 Jul 2019

I came here to report the same issue, I only noticed it today after upgrading to 3.0.100-preview8-012929
Thanks @Berrysoft for reporting this!

@rladuca Thanks for explaining this, and even on a sunday.

P.S.
I'm still having a hard time to detect what changes. not just for WPF, are in a certain dotnet core SDK build. How will we know with what version this issue is fixed? Will you tell use the SDK version when closing this issue or do we just try every build?

Lakritzator on 8 Jul 2019

So there are a couple of things that are interesting to note.

We need to port https://github.com/dotnet/corefx/pull/38908 to release/3.0 branch, _then_ wait for that to flow into dotnet/wpf, _then_ (a) change our references for XamlAccessLevel from System.Security.Permissions to System.Windows.Extensions and (b) change the [TypeForwardedToAttribute] for XamlAccessLevel to point to System.Windows.Extensions.
- This outstanding work is not what is causing this crash.
core-setup does the composition for Microsoft.WindowsDesktop.App.
- I took at look at the latest core-sdk bits - 3.0.0-preview8-27908-02. It contains -
- System.Xaml: 4.8.0-preview8.19356.4+40a95619a41ea2c14e4d3c4ba14c5e1acd9f8301
- System.Security.Permissions: 3.0.0-preview8.19357.5
- System.Windows.Extensions: 3.0.0-preview8.19357.5

Looking at https://github.com/dotnet/wpf/commit/40a95619a41ea2c14e4d3c4ba14c5e1acd9f8301, WPF was built with System.Security.Permissions and System.Windows.Extensions version 4.6.0-preview7.19320.1.

The problems seems to be that Microsoft.WindowsDesktop.App is not packaging 4.6.0-preview7.19320.1 - it is instead packaging a newer version 4.8.0-preview8.19356.4.

These newer versions of System.Security.Permissions and System.Windows.Extensions have XamlAccessLevel type moved already - which is the cause for the crash.

If Microsoft.WindowsDesktop.App had been packaged with 4.6.0-preview7.19320.1, we'd not have seen any crashes.

/cc @ericstj, @dagood

vatsan-madhavan on 8 Jul 2019

I'm looking at PresentationFramework.Aero from the same SDK (4.8.0-preview8.19357.3+f48db94ae9617a7105ec3f2f3446eb86182ccdaf) which was built out of dotnet-wpf-int repo.

This is what I see in its Version.Details.xml:

System.Security.Permissions: NA
System.Windows.Extensions: 4.6.0-preview8.19355.7

I think we need to modify the CoherentParentDependency attributes in Version.Details.xml in this repo to ensure that it tracks dotnet/wpf rather than act indepdently.

This is what I see in master now:

<?xml version="1.0" encoding="utf-8"?>
<Dependencies>
  <ProductDependencies>
    <!-- 
      Don't add CoherentParentDependency for Microsoft.DotNet.Wpf.GitHub. We'd like to have the latest
      from dotnet/wpf
    -->
    <Dependency Name="Microsoft.DotNet.Wpf.GitHub" Version="4.8.0-preview8.19357.3">
      <Uri>https://github.com/dotnet/wpf</Uri>
      <Sha>0cb1317b122f502f88b976dd91cadecc38136ee4</Sha>
    </Dependency>
    <Dependency Name="Microsoft.Private.Winforms" Version="4.8.0-preview8.19353.4" CoherentParentDependency="Microsoft.DotNet.Wpf.GitHub">
      <Uri>https://github.com/dotnet/winforms</Uri>
      <Sha>522215c10ccdc2ae74ab265296ce288f29e892eb</Sha>
    </Dependency>
  </ProductDependencies>
  <ToolsetDependencies>
    <Dependency Name="Microsoft.Win32.Registry" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.Configuration.ConfigurationManager" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.Diagnostics.EventLog" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.DirectoryServices" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.Drawing.Common" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.IO.Packaging" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.Reflection.Emit" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.Reflection.MetadataLoadContext" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.Security.AccessControl" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.Security.Cryptography.Xml" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.Security.Principal.Windows" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="System.Windows.Extensions" Version="4.6.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="Microsoft.DotNet.Arcade.Sdk" Version="1.0.0-beta.19327.39">
      <Uri>https://github.com/dotnet/arcade</Uri>
      <Sha>247c0290c554a68dd3e560dd88fb0da26353d9d7</Sha>
      <SourceBuildId>6006</SourceBuildId>
    </Dependency>
    <!-- 
      Don't add CoherentParentDependency for Microsoft.DotNet.Arcade.Wpf.Sdk. We'd like to have the latest build props/targets
      from dotnet/wpf. Adding CoherentParentDependency="Microsoft.NETCore.App" will ensure that Microsoft.DotNet.Arcade.Wpf.Sdk
      will track the version of Microsoft.DotNet.Arcade.Wpf.Sdk.
    -->
    <Dependency Name="Microsoft.DotNet.Arcade.Wpf.Sdk" Version="4.8.0-preview8.19357.3">
      <SourceBuildId>6037</SourceBuildId>
      <Uri>https://github.com/dotnet/wpf</Uri>
      <Sha>0cb1317b122f502f88b976dd91cadecc38136ee4</Sha>
    </Dependency>
    <!-- 
      Don't add CoherentParentDependency for Microsoft.NET.Sdk.WindowsDesktop. We'd like to have the latest
      from dotnet/wpf.
    -->
    <Dependency Name="Microsoft.NET.Sdk.WindowsDesktop" Version="3.0.0-preview8.19357.3">
      <Uri>https://github.com/dotnet/wpf</Uri>
      <Sha>0cb1317b122f502f88b976dd91cadecc38136ee4</Sha>
    </Dependency>
    <Dependency Name="Microsoft.DotNet.CodeAnalysis" Version="1.0.0-beta.19356.1" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/arcade</Uri>
      <Sha>a65d0966dc28861394ce78cfdcb9d5dff370957c</Sha>
    </Dependency>
    <Dependency Name="Microsoft.NETCore.Platforms" Version="3.0.0-preview8.19357.5" CoherentParentDependency="Microsoft.NETCore.App">
      <Uri>https://github.com/dotnet/corefx</Uri>
      <Sha>3b426f78a3aab1a45f797ac22e70fd203165d810</Sha>
    </Dependency>
    <Dependency Name="Microsoft.NETCore.App" Version="3.0.0-preview8-27907-09">
      <Uri>https://github.com/dotnet/core-setup</Uri>
      <Sha>fc924dc319cde4a8c2f8c6cc715772a0eac933a1</Sha>
    </Dependency>
    <Dependency Name="Microsoft.DotNet.ApiCompat" Version="1.0.0-beta.19327.39">
      <Uri>https://github.com/dotnet/arcade</Uri>
      <Sha>247c0290c554a68dd3e560dd88fb0da26353d9d7</Sha>
    </Dependency>
    <Dependency Name="Microsoft.DotNet.GenAPI" Version="1.0.0-beta.19327.39">
      <Uri>https://github.com/dotnet/arcade</Uri>
      <Sha>247c0290c554a68dd3e560dd88fb0da26353d9d7</Sha>
    </Dependency>
  </ToolsetDependencies>
</Dependencies>

vatsan-madhavan on 8 Jul 2019

/cc @mmitche, @wtgodbe

vatsan-madhavan on 8 Jul 2019

I have an internal PR out to fix the mismatch in CoreFx package versions that are being consumed by the build in dotnet/wpf and dotnet-wpf-int.

https://dev.azure.com/dnceng/internal/_git/dotnet-wpf-int/pullrequest/2009

vatsan-madhavan on 8 Jul 2019

We need to port dotnet/corefx#38908 to release/3.0 branch, then wait for that to flow into dotnet/wpf, then (a) change our references for XamlAccessLevel from System.Security.Permissions to System.Windows.Extensions and (b) change the [TypeForwardedToAttribute] for XamlAccessLevel to point to System.Windows.Extensions.

This change is for preview8, not preview7. All you need to do is make sure you that you're picking up preview8 corefx bits in your preview8 branches. This problem will fix itself on recompile since you should get the transitive reference when picking up the new package. You can clean up the package-reference to use only System.Windows.Extensions at your leisure.

This type of hiccup is always going to happen so long as core-setup is responsible for packaging WPF, since it permits core-setup to get "ahead" of WPF WRT corefx dependencies. Typically it "fixes" itself by letting the bits flow into WPF and back into core-setup.

ericstj on 9 Jul 2019

👍1

This is now fixed in the latest build available at https://github.com/dotnet/core-sdk.

The current version which I just I checked is:

fc226794a12bfcfc18bac269bc57c7900e4a1e5d
3.0.100-preview8-012990

vatsan-madhavan on 10 Jul 2019

👍2

I can confirm it working with 3.0.100-preview8-012985, hanks for fixing this!!

Lakritzator on 10 Jul 2019

👍2

It works, thanks!

Berrysoft on 11 Jul 2019

Was this page helpful?

0 / 5 - 0 ratings

Related issues

Add license headers to test code

stevenbrix · 3Comments

WindowChrome causes flickering on resize

bugproof · 3Comments

Binding to ExpandoObject Properties throws Binding Exception

pocki · 3Comments

Cross platform support for XPS

poke · 3Comments

[Question] Relationship with AvaloniaUI

Pzixel · 3Comments