leecow
commented
5 years ago cc @diverdan92
Closed rido-min closed 5 years ago
leecow
commented
5 years ago cc @diverdan92
Lakritzator
commented
5 years ago @diverdan92 This is the same issue I reported via email, somehow my google-fu didn't find it.. sorry. FYI: I am running with 3.0.100-alpha1-009670
My projects also uses MahApps, which has this dependency on ControlzEx. As this issue has a lot of information, and a much better stacktrace, use this! (I'm already subscribed)
Just in case it's still needed, my project (libraries for Greenshot) to reproduce the error is here (the link brings you to the feature/dotnetcore30 branch!): https://github.com/dapplo/Dapplo.CaliburnMicro/tree/feature/dotnetcore30
It's not so restricted yet, as I first wanted to know if the issue was known before putting time in making a simplified version to reproduce the error.
You probably want to unload all projects with “clickonce” in the name… The startup project should be Application.Demo, you should be able to build and run it. There is a trayicon, withs looks like a #, this has a configuration entry, selecting this causes the error.
diverdan92
commented
5 years ago @Lakritzator - thanks for the additional details and extra repro project.
@ericstj @jkotas - any ideas who may be a good person to take a look?
jkotas
commented
5 years ago @ericstj Are you able to reproduce this?
Application.Demo from above fails for me pretty early. Here is what I have done:
git clone https://github.com/dapplo/Dapplo.CaliburnMicro/
cd Dapplo.CaliburnMicro\src\Application.Demo
git checkout feature/dotnetcore30
dotnet restore
msbuild
dotnet bin\Debug\netcoreapp3.0\Application.Demo.dllResult:
Unhandled Exception: System.IO.DirectoryNotFoundException: D:\Application.Demo.Addon\bin\Debug\netcoreapp3.0
at Dapplo.Addons.Bootstrapper.Resolving.AssemblyResolver.ScanForAssemblies()
at Dapplo.Addons.Bootstrapper.Resolving.AssemblyResolver..ctor(ApplicationConfig applicationConfig)
at Dapplo.Addons.Bootstrapper.ApplicationBootstrapper..ctor(ApplicationConfig applicationConfig)
at Dapplo.CaliburnMicro.Dapp.Dapplication..ctor(ApplicationConfig applicationConfig) in D:\Dapplo.CaliburnMicro\src\Dapplo.CaliburnMicro.Dapp\Dapplication.cs:line 57@jkotas I mainly develop from within Visual Studio, never checked how got it runs on the commandline. I will see if I can build a clean fix without "hardcoded" paths, right away.
I still advice to look at the ControlZEx example, as it's probably a much better example which doesn't do as much as I did. Like I said before, I use the ControlZEx NuGet Package and this code is most likely that what my Demo crashes.
jkotas
commented
5 years ago ControlZEx example
I was not able to build that one (I did not spend too much time debugging that). When I use the Build.ps1 script in the root, it fails with:
D:\ControlzEx>powershell .\Build.ps1
Preparing to run build script...
Paket version 5.174.2
Performance:
- Runtime: 1 second
Paket failed with
-> Extracting platforms from path 'netcoreapp3.0' failed
Resolve-Path : Cannot find path 'D:\ControlzEx\packages\cake\Cake' because it does not exist.@jkotas Actually, I think the problem you had is also due to the fact that you build Application.Demo directly. The application doesn't know about what projects it uses, there are no direct references in the code, so the other projects are not build. The demo needs to demonstrate loading addons at runtime to enhance the UI, this is why... 😄
I made some modifications (git pull), and together with the following steps (bold was modified) it should start:
git clone https://github.com/dapplo/Dapplo.CaliburnMicro/
cd Dapplo.CaliburnMicro\src
git checkout feature/dotnetcore30
dotnet restore
msbuild /p:Configuration=Debug /p:Platform="Any CPU"
dotnet Application.Demo\bin\Debug\netcoreapp3.0\Application.Demo.dll(tested this)
Lakritzator
commented
5 years ago On a side-note:
Lakritzator
commented
5 years ago FYI: Now, if you got things working, you will notice that provoking the error is not really a nice experience from the commandline! The application goes berserk, and opens one window after the other.. this is actually some bad error handling, which tries to show a window -> error -> error handler -> show another window -> error etc... etc..
ericstj
commented
5 years ago @jkotas / @Lakritzator I can repro. I'm seeing lots of noise in this repro but I'll try to get to the bottom of the render thread exception. /cc @vatsan-madhavan @rladuca
Lakritzator
commented
5 years ago @ericstj Thanks for the feedback!
Yeah sorry for all the noise... The project is not specifically made to demonstrate the error, it's pretty much a demo of all the accumulated base library (it has a lot of dependencies) for the "backbone" of the next Greenshot.
I didn't know it might have been in the ControlzEx library code, I only had a stacktrace of internal Microsoft code. This made it hard to reduce the code to the causing code, especially when I only have a time in my "free" evenings to work on this. I wish I would get paid for "playing around" with .NET Code & technologies like you guys 😁 (Daytime job I mainly work with Java)
Anyway, it's now already past midnight for me, so time for bed... With a bit more time, I would probably be able to reduce it to a lot less! If you can't isolate it, I will give it a go tomorrow.
Lakritzator
commented
5 years ago As promised, I created a more isolated repository. See here: https://github.com/Lakritzator/RenderThreadFailure
It has the least noisy code I needed to reproduce the error, but it does just Mahapps.Metro to do so. The issue seems to manifest when a MetroWindow has a GlowBrush, enabling a glow around the window, is shown.
I'm not a MahApps expert, you probably need to look there for what is happening.
Lakritzator
commented
5 years ago In the "alternative" branch of the same project I have used ControlzEx (an alpha) to create the same error by attaching a "GlowWindowBehavior".
It's actually just this:
var window = new Window();
var glowWindowBehavior = new GlowWindowBehavior
{
GlowBrush = Brushes.Green
};
glowWindowBehavior.Attach(window);
window.Show();Awesome, it is a much easier repro and I am seeing the same assert in wpfgfx which indicates its likely the root cause:
MIL FAILURE: Unexpected HRESULT 0x80070715 in caller: batch processing errorThis is coming from a failure to FindResource which is looking for resource 0x00000387 (903) in wpfgfx.
00 KERNELBASE!FindResourceW
01 wpfgfx_cor3!CMilEffectDuce::LockResource
02 wpfgfx_cor3!CMilBlurEffectDuce::Initialize
03 wpfgfx_cor3!CMilSlaveHandleTable::CreateEmptyResource
04 wpfgfx_cor3!CComposition::Channel_CreateResource
05 wpfgfx_cor3!CComposition::ProcessCommandBatch
06 wpfgfx_cor3!CComposition::ProcessPartitionCommand
07 wpfgfx_cor3!CCrossThreadComposition::ProcessBatches
08 wpfgfx_cor3!CCrossThreadComposition::OnBeginComposition
09 wpfgfx_cor3!CComposition::ProcessComposition
0a wpfgfx_cor3!CComposition::Compose
0b wpfgfx_cor3!CPartitionThread::RenderPartition
0c wpfgfx_cor3!CPartitionThread::Run
0d wpfgfx_cor3!CPartitionThread::ThreadMain
0e KERNEL32!BaseThreadInitThunk
0f ntdll!RtlUserThreadStart@vatsan-madhavan this appears to be an issue with the native build of WPFGFX. Seems to be missing some native resources.
See
vatsan-madhavan
commented
5 years ago Thanks, taking a look...
Lakritzator
commented
5 years ago Today I will try to workaround the issue, didn't have time for that yet, so I can at least continue with my development for & evaluation of dotnet core 3.0. I still need to mix all my recent changes to the Greenshot repository, where I will add (and thus test) with some of the WinForms functionality.
Still wanted to add a questions to this issue: Is there any information on what wpfgfx_cor3 compared to wpfgfx_v0400 is, and how this is developed? For instance, will this always be developed side by side? How do I see when a new version is supplied, and what changes it has?
Am I correct to assume that wpfgfx it's not open source? Are there any plans on making this more transparent?
ericstj
commented
5 years ago This is a native component in WPF. _v0400 is the one from .net desktop. _cor3 is the one in .net core. It's part of the Microsoft.DesktopUI.App package so you'll see new versions as the SDK updates.
We'll make sure to update this issue with more information about a fix as it is known.
vatsan-madhavan
commented
5 years ago I have a fix that I'm testing right now - should have something out within a day or two.
Lakritzator
commented
5 years ago @ericstj That is pretty much what I understood, was hoping for a bit more 😁
Is the Microsoft.DesktopUI.App open source? Probably not?I think it should be very clearly communicated if not, don't get me wrong: I don't have an issue with it but if dotnet core is open source and it uses closed source components, it might not be received very well if this is not explained.
ericstj
commented
5 years ago I think the latest announcement was @richlander’s comment:
We are investigating that, but haven’t yet made a decision. We’ve been focused on the parts I’ve written about above. We see the value it would have, but don’t have anything to announce yet.
Lakritzator
commented
5 years ago @ericstj thanks for the link, I never thought about going back to that "old" blogpost, and read the comments.
Lakritzator
commented
5 years ago @vatsan-madhavan I'm hesitant to ask, but what is the status on this? Is there anything ) can do, or some kind of workaround? It's no problem if you guys need more time, I am asking so I know where to put my priorities.
For the time being I disabled Mahapps Themes, those trigger the glowbehavior, but the UI is missing some stuff and I am not sure if this is due to the theming or a general UI problem...
vatsan-madhavan
commented
5 years ago @Lakritzator Hmm.. I had fixed this a few days ago, and had hoped that the change would have made it to the SDK by now. I'm enquiring...
ericstj
commented
5 years ago Yeah, coresdk is still on a build that's 8 days old: https://github.com/dotnet/core-sdk/blob/b4fe871ab87f6ddc4561efcc3e510a9b529ad5ce/build/DependencyVersions.props#L41 @livarcocc / @nguerrera / @dsplaisted would be the ones to ask if we can have them pick up a new one (and see about automating that codeflow).
Lakritzator
commented
5 years ago @ericstj thanks for the update, not a big problem. But it does give bring up the question on how we are supposed to know what changes are in what build?
nguerrera
commented
5 years ago I'll be inserting the most recent bits later this afternoon.
nguerrera
commented
5 years ago The insertion has been delayed until tomorrow morning in order to pick up another fix and save some effort while they are still manual. I will post a link to a build when it's done.
Lakritzator
commented
5 years ago I updated to 3.0.100-alpha1-009706 and the bug seems to be solved!!!! The example project doesn't crash, and my bigger project also works.
From my point of view, where there is nothing more to do, you can close this issue.
nguerrera
commented
5 years ago Great, glad the update worked, and sorry for the delay and the difficulty of determining when a fix will land in a build.
Lakritzator
commented
5 years ago No problem with the delay, and thanks for fixing it!
m1l
commented
5 years ago This issue has been plaguing all my WPF software since .NET 4.x. Is it possible to apply the solution to WPF?
karelz
commented
5 years ago @m1l I believe this was specific to .NET Core. I recommend to raise the question with details (like repro) on WPF repo.
WPF crash with UCEERR_RENDERTHREADFAILURE
General
I found this issue when trying to port MahApps to .NET Core 3.0. They have a dependency on ControlzEx to customize Windows.
I've been able to repro the issue on my CotrolzEx fork
and the full call stack from VS:
Runtime environment