-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Application crash on customer machine (Fluent Theme?) #10609
Comments
Would you have a repro? It might be challenging to figure this out from a crash dump. I am assuming you are confident there isn't a layout recursion or a tree too deep. Does it crash for the customer without using the Fluent theme? Please also note that the Fluent theme is experimental and I wouldn't advise to use it in stable releases yet. |
There is also an Out of Memory Exception in the stack trace, yet a screenshot from the customers task manager shows that only 50% of the physical memory of the machine is in use (48 GB total physical memory).
Well not isolated from our app. It occurs on this customers machine.
No, this is the first time I've heard the term "layout recursion". I do not know how to detect those issues.
When we look at the documentation, to us it looks like it is only the |
An example of layout recursion would be if an element is a child of itself (though I don't think you can do that directly), or if template tries to instantiate something that also uses that template, etc. I agree the What's new page did not make it too clear. A bit stronger wording was added to https://github.com/dotnet/wpf/blob/main/Documentation/docs/using-fluent.md. You can also see the list of open theme related issues: https://github.com/dotnet/wpf/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22Win%2011%20Theming%22. Yours might be another. There might be other reasons for OOM other than directly memory, such as running out of GDI handles. If your app is running as 32-bit, it runs out of memory at a few GB. If your customer is running into the issue pretty reliably, it might be worth trying to see if it repros for them for the same version of the app without the fluent theme enabled. Otherwise, when you see the whole stack, you should be able to follow your XAML design and see which element it dives into. |
Thanks for the assistance, Jan. Yes indeed, on that page there is a note that says the entire Fluent theme is experimental. We haven't seen that note before, maybe because it wasn't referenced in the release notes.
The app is 64 bit.
The new app version only supports the Fluent theme, that is the main feature of it. We would have to make some code changes to even make it possible to test without Fluent theme. We will try to make an experiment to untangle Fluent theme from the app. For example we probably need the text styles and colors to still be defined (which are referenced in XAML and in code). We will then send this to the customer to try out, then we should get a definite determination of whether this is Fluent theme related. In any event, a crash should not happen, Fluent theme or not. I guess the question now is whether Fluent theme will be stable in .NET 10, if there are any promises from Microsoft to that effect, or if we should change course. We are fine with some future API changes but expect every version to work "In the wild". We can't wait until .NET 11 to have a stable product. |
This note was made after the release of Fluent theme: Somewhat unsatisfactory expectation management, I would say. Will this issue be closed without a minimal repro? (We would object to that). As mentioned in the original post, we have a crash dump that we can share privately with Microsoft. |
You are right Jan, it is layout recursion!
|
Right, I think it is critical to identify which controls in the stack correspond to which elements in your UI. You might be able to do that from a crash dump. Check that the heap does not in fact contain 2k different controls. If it doesn't help, time-travel trace might be more helpful. I am afraid I don't think there is much that can be done without a repro. You might need to open a support case. You could also probably add some telemetry in the app to guide you in diagnosing the issue. |
Description
Our company is now at the point where we want to release our app, built with the new Fluent theme. However, we get a customer reporting a crash on the preview release of our app. The application itself targets .NET 9.0.1.
I asked the customer for the crash dump file and can share it privately with a Microsoft employee.
There appears to be a stackoverflow involved, as can be seen by dumping exceptions via the
dumpexceptions
command indotnet dump
:Note the last exception:
The CLR stack trace is enormous:
Reproduction Steps
N/A
Expected behavior
Crash 💥Actual behavior
Crash 💥
Regression?
We think this may be related to the new Fluent Theme, as we have not had this kind of crash before. Well, at least not with WPF...
Known Workarounds
None
Impact
The customer cannot use our application since it often crashes or freezes for them. We are unsure how many customers this affects, since we have not shipped the next major version with the Fluent Theme version yet - only a preview version.
We instructed the customer to update to the latest Windows version and update graphics drivers, since we have had issues with that before. The customer has done so but it has not resolved the issue.
Configuration
From the customer:
Other information
No response
The text was updated successfully, but these errors were encountered: