App silently crashes with local WPF assemblies

[stevenbrix]

We think there is some issue with how WPF assemblies are being compiled that makes them not work properly, but it's incredibly challenging to try and figure out what is going on. If someone could take a look and help me understand, that would be great. Ideally, these errors had some more actionable information so I can self-diagnose and fix the issue. If there are any tools/tricks that can help me diagnose these issues that would be a big 👍.

Repro steps

1. git clone https://github.com/dotnet/wpf.git
2. cd to directory where repo was cloned and run .\build.cmd -pack
3. Create a sample wpf .netcore app through VS or using dotnet new wpf
4. Follow this step in the developer guide for trying out local wpf assemblies.
5. Open project in VS and F5

Expected

App runs, or we get an actionable exception that will help us diagnose the issue

Actual

App silently crashes with error 0xe0434352. I have all managed exceptions enabled and still nothing gets caught.

Repro steps (continued)

6. Right-click the .csproj and go to Properties->Debug.
7. Enable Native debugging and then F5

Expected

App runs, or we get an actionable exception that will help us diagnose the issue

Actual

Native exception is caught, but still not actionable

If I continue past this I then see a System.ExecutionEngineException, but it still doesn't provide any information.

cc @ericstj

[jkotas]

cc @vitek-karas

[stevenbrix]

I have an app published to an internal share that someone can use to repro this without going through all the steps. You can follow up with me offline if you want to take a look.

I'll post the link here if that's fine, I just wasn't sure if that's an OK thing to do or not

[vitek-karas]

It fails with this callstack:

 	coreclr.dll!EEFileLoadException::Throw(AssemblySpec * pSpec, HRESULT hr, Exception * pInnerException) Line 1911	C++
>	coreclr.dll!AppDomain::BindAssemblySpec(AssemblySpec * pSpec, int fThrowOnFileNotFound, int fUseHostBinderIfAvailable) Line 5142	C++
 	coreclr.dll!PEFile::LoadAssembly(unsigned int kAssemblyRef, IMDInternalImport *) Line 1585	C++
 	coreclr.dll!Module::LoadAssembly(unsigned int kAssemblyRef, const char * szWinRtTypeNamespace, const char * szWinRtTypeClassName) Line 4994	C++
 	coreclr.dll!Assembly::FindModuleByTypeRef(Module * pModule, unsigned int tkType, Loader::LoadFlag loadFlag, int * pfNoResolutionScope) Line 1125	C++
 	coreclr.dll!ClassLoader::LoadTypeDefOrRefThrowing(Module * pModule, unsigned int typeDefOrRef, ClassLoader::NotFoundAction fNotFoundAction, ClassLoader::PermitUninstantiatedFlag fUninstantiated, unsigned int tokenNotToLoad, ClassLoadLevel level) Line 2675	C++
 	coreclr.dll!ClassLoader::LoadApproxTypeThrowing(Module * pModule, unsigned int tok, SigPointer * pSigInst, const SigTypeContext * pClassTypeContext) Line 3080	C++
 	[Inline Frame] coreclr.dll!ClassLoader::LoadApproxParentThrowing(Module *) Line 3134	C++
 	coreclr.dll!ClassLoader::CreateTypeHandleForTypeDefThrowing(Module * pModule, unsigned int cl, Instantiation inst, AllocMemTracker * pamTracker) Line 12071	C++
 	coreclr.dll!ClassLoader::CreateTypeHandleForTypeKey(TypeKey * pKey, AllocMemTracker * pamTracker) Line 3363	C++
 	[Inline Frame] coreclr.dll!ClassLoader::DoIncrementalLoad(TypeKey * typeHnd, TypeHandle) Line 3189	C++
 	coreclr.dll!ClassLoader::LoadTypeHandleForTypeKey_Body(TypeKey * pTypeKey, TypeHandle typeHnd, ClassLoadLevel targetLevel) Line 3951	C++
 	coreclr.dll!ClassLoader::LoadTypeHandleForTypeKey(TypeKey * pTypeKey, TypeHandle typeHnd, ClassLoadLevel targetLevel, const InstantiationContext * pInstContext) Line 3677	C++
 	coreclr.dll!ClassLoader::LoadTypeDefThrowing(Module * pModule, unsigned int typeDef, ClassLoader::NotFoundAction fNotFoundAction, ClassLoader::PermitUninstantiatedFlag fUninstantiated, unsigned int tokenNotToLoad, ClassLoadLevel level, Instantiation * pTargetInstantiation) Line 2565	C++
 	coreclr.dll!ClassLoader::LoadTypeDefOrRefThrowing(Module * pModule, unsigned int typeDefOrRef, ClassLoader::NotFoundAction fNotFoundAction, ClassLoader::PermitUninstantiatedFlag fUninstantiated, unsigned int tokenNotToLoad, ClassLoadLevel level) Line 2737	C++
 	coreclr.dll!Assembly::GetEntryPoint() Line 1782	C++
 	coreclr.dll!Assembly::ExecuteMainMethod(PtrArray * * stringArgs, int) Line 1658	C++
 	coreclr.dll!CorHost2::ExecuteAssembly(unsigned long dwAppDomainId, const wchar_t * pwzAssemblyPath, int argc, const wchar_t * * argv, unsigned long * pReturnValue) Line 462	C++

The assembly spec is for PresentationFramework. It's not yet clear to me if the error comes for that assembly or some of its dependencies... but. Looking at the .deps.json, it doesn't list the PresentationFramework.dll anywhere, so I would not be surprised if that's the problem - we simply can't find it in the TPA.

[vitek-karas]

When I look at the .deps.json for Microsoft.WindowsDesktop.App framework (Preview5), it does have an asset record for PresentationFramework.dll. So my first guess would be that there's something wrong with how this app was built.

[stevenbrix]

So my first guess would be that there's something wrong with how this app was build

@vitek-karas we are trying to use the PresentationFramework.dll that was locally built, and not part of the Microsoft.WindowsDesktop.App install using the pattern described here. My understanding is that this is supported, and I do see the proper assemblies being bundled with the app. The same assemblies work fine if they are copied into the shared runtime, but not in this pattern.

And how did you find that callstack? Asking for a friend who needs help debugging these things... ;)

[stevenbrix]

Ok i think i figured it out, as @vitek-karas mentioned this is a .deps.json generation issue. I fixed it by changing this:

    <Reference Include="$(WpfRepoRoot)\artifacts\packaging\$(WpfConfig)\Microsoft.DotNet.Wpf.GitHub\ref\netcoreapp3.0\*.dll" Private="false" />
    <ReferenceCopyLocalPaths Include="$(WpfRepoRoot)\artifacts\packaging\$(WpfConfig)\Microsoft.DotNet.Wpf.GitHub\lib\netcoreapp3.0\*.dll" />
    <ReferenceCopyLocalPaths Include="$(WpfRepoRoot)\artifacts\packaging\$(WpfConfig)\Microsoft.DotNet.Wpf.GitHub\lib\$(RuntimeIdentifier)\*.dll" />

to

    <Reference Include="$(WpfRepoRoot)\artifacts\packaging\$(WpfConfig)\Microsoft.DotNet.Wpf.GitHub\lib\netcoreapp3.0\*.dll" />
    <ReferenceCopyLocalPaths Include="$(WpfRepoRoot)\artifacts\packaging\$(WpfConfig)\Microsoft.DotNet.Wpf.GitHub\lib\$(RuntimeIdentifier)\*.dll" />

@ericstj for fyi. not sure if this is a bug or by-design

[vitek-karas]

Let's keep this bug to figure out why the runtime silently crashes... as far as I can tell it doesn't even write anything to stderr - let alone the problem that it should probably popup a dialog in this case (since it's a GUI exe).

[ericstj]

I see, that makes sense. Looks like the SDK doesn't have a way of getting split ref/lib into the deps file via items, but it can handle simple references. I wonder if there is a better item to set for libs that would actually make it into the deps. I suppose another option would be to run without a deps file. @vitek-karas would that work?

[vitek-karas]

I just tried it and it doesn't help - although I don't know why - it should have... looking into it

[vitek-karas]

So the reason deleting just the .deps.json doesn't help is that it triggers this super old mode called split_fx - which is on when the app has no .deps.json, but it does have .runtimeconfig.json and the app.dll exists and it has coreclr.dll in the same directory. In that mode, for some reason we expect something similar to muxer behavior and thus fail because the command line doesn't specify the .dll to run.

To make it work, delete both the .deps.json and .runtimeconfig.json - then it will run in apphost mode and will treat all .dll files in the folder as potential managed assemblies and put them all into TPA - the app successfully starts like this.

There are other issues though - for some reason we don't popup a dialog with any of these errors - even though we should.

[vitek-karas]

This is just all kinds of weird - if only the .deps.json file is deleted, we behave the same way as if one runs dotnet.exe without any arguments. This for some reason doesn't print out any errors (to stderr), it just prints out the usage test (listing available arguments and so on). Not sure if we can actually change this behavior as it would affect all installed versions (so 1.* and 2.* as well) and for those it would be technically a breaking change.

The apphost will popup a dialog only if there were actual errors reported, of there are no errors reported we skip that step and simply return the exit code.

[vitek-karas]

I was finally able to get it to report the actual error. The trick is to run the app like
WpfNetCore.exe 2>err.log

Then it will write the stderr to the file and that contains:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.
File name: 'PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

I wonder if there's something we can do here. For some reason when I run a GUI app even from command line both stderr and stdout are not captured by the console, so really only redirecting to file works. AFAIK the app itself can't force the stdout/stderr to be consumed by anything either.

So the only option would be to somehow detect this and instead popup a dialog... which might be very tricky. The error is written by CoreCLR and it will terminate the process right after.

I wonder if .NET Framework had a better behavior in this case.

[dotMorten]

@vitek-karas This also matches the error I was seeing in the event viewer