Repository navigation
App silently crashes with local WPF assemblies #12933
Description
Activity
- changed the title
[-]App silently crashes[/-][+]App silently crashes with local WPF assemblies[/+]on Jun 20, 2019 cc @vitek-karas
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
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 thePresentationFramework.dllanywhere, so I would not be surprised if that's the problem - we simply can't find it in the TPA.When I look at the
.deps.jsonforMicrosoft.WindowsDesktop.Appframework (Preview5), it does have an asset record forPresentationFramework.dll. So my first guess would be that there's something wrong with how this app was built.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.Appinstall 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... ;)
Ok i think i figured it out, as @vitek-karas mentioned this is a
.deps.jsongeneration 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
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).
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?
I just tried it and it doesn't help - although I don't know why - it should have... looking into it
So the reason deleting just the
.deps.jsondoesn't help is that it triggers this super old mode calledsplit_fx- which is on when the app has no.deps.json, but it does have.runtimeconfig.jsonand theapp.dllexists and it hascoreclr.dllin 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.dllto run.To make it work, delete both the
.deps.jsonand.runtimeconfig.json- then it will run inapphostmode and will treat all.dllfiles 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.
This is just all kinds of weird - if only the
.deps.jsonfile is deleted, we behave the same way as if one runsdotnet.exewithout 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.
I was finally able to get it to report the actual error. The trick is to run the app like
WpfNetCore.exe 2>err.logThen 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.
@vitek-karas This also matches the error I was seeing in the event viewer
Let's keep this bug to figure out why the runtime silently crashes...
This is a duplicate of dotnet/core-setup#6412
Closing
- ghost locked as resolved and limited conversation to collaborators
on Dec 12, 2020
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
.\build.cmd -packdotnet new wpfExpected
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)
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