WPF program crashes with the nightly build sdk #1183

Berrysoft · 2019-07-06T08:25:36Z

.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

The text was updated successfully, but these errors were encountered:

rladuca · 2019-07-07T03:39:05Z

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.

Berrysoft · 2019-07-07T03:55:47Z

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

Lakritzator · 2019-07-08T09:14:55Z

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?

vatsan-madhavan · 2019-07-08T18:39:39Z

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

We need to port Move XamlAccessLevel to System.Windows.Extensions.dll 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 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 40a9561, 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 · 2019-07-08T18:46:36Z

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 · 2019-07-08T18:46:48Z

/cc @mmitche, @wtgodbe

vatsan-madhavan · 2019-07-08T19:02:57Z

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

ericstj · 2019-07-09T03:54:55Z

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.

vatsan-madhavan · 2019-07-10T20:27:21Z

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

Lakritzator · 2019-07-10T20:40:25Z

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

Berrysoft · 2019-07-11T06:07:17Z

It works, thanks!

Berrysoft changed the title ~~WPF program crashes in the nightly build~~ WPF program crashes with the nightly build sdk Jul 6, 2019

grubioe assigned ojhad and vatsan-madhavan Jul 8, 2019

grubioe added the urgent status: This issue needs immediate attention label Jul 8, 2019

grubioe added this to the 3.0 milestone Jul 8, 2019

grubioe added the Bug Product bug (most likely) label Jul 8, 2019

vatsan-madhavan mentioned this issue Jul 8, 2019

dotnet/wpf and dotnet-wpf-int consume different versions of CoreFx packages during build #1191

Closed

ojhad mentioned this issue Jul 8, 2019

Add PackageReference to account for XamlAccessLevel move #1192

Merged

Lakritzator mentioned this issue Jul 9, 2019

Linked issues preventing providing previews of Greenshot or going live greenshot/greenshot#135

Open

Nukepayload2 mentioned this issue Jul 9, 2019

RichTextBox throws XamlParseException in its constructor #1178

Closed

vatsan-madhavan mentioned this issue Jul 9, 2019

[master] Update dependencies from dotnet/core-setup dotnet/winforms#1307

Merged

Lakritzator mentioned this issue Jul 9, 2019

Using Snoop in other applications snoopwpf/snoopwpf#136

Open

vatsan-madhavan closed this as completed Jul 10, 2019

vatsan-madhavan added the regression status: This issue is a regression from a previous build or release label Jul 10, 2019

vatsan-madhavan unassigned ojhad Jul 10, 2019

ghost locked as resolved and limited conversation to collaborators Apr 16, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WPF program crashes with the nightly build sdk #1183

WPF program crashes with the nightly build sdk #1183

Berrysoft commented Jul 6, 2019

rladuca commented Jul 7, 2019 •

edited

Loading

Berrysoft commented Jul 7, 2019

Lakritzator commented Jul 8, 2019

vatsan-madhavan commented Jul 8, 2019 •

edited

Loading

vatsan-madhavan commented Jul 8, 2019

vatsan-madhavan commented Jul 8, 2019 •

edited

Loading

vatsan-madhavan commented Jul 8, 2019

ericstj commented Jul 9, 2019

vatsan-madhavan commented Jul 10, 2019

Lakritzator commented Jul 10, 2019

Berrysoft commented Jul 11, 2019

WPF program crashes with the nightly build sdk #1183

WPF program crashes with the nightly build sdk #1183

Comments

Berrysoft commented Jul 6, 2019

rladuca commented Jul 7, 2019 • edited Loading

Berrysoft commented Jul 7, 2019

Lakritzator commented Jul 8, 2019

vatsan-madhavan commented Jul 8, 2019 • edited Loading

vatsan-madhavan commented Jul 8, 2019

vatsan-madhavan commented Jul 8, 2019 • edited Loading

vatsan-madhavan commented Jul 8, 2019

ericstj commented Jul 9, 2019

vatsan-madhavan commented Jul 10, 2019

Lakritzator commented Jul 10, 2019

Berrysoft commented Jul 11, 2019

rladuca commented Jul 7, 2019 •

edited

Loading

vatsan-madhavan commented Jul 8, 2019 •

edited

Loading

vatsan-madhavan commented Jul 8, 2019 •

edited

Loading