Faults in Windows.UI.Xaml.dll #10765

@ghost commented on GitHub (Sep 25, 2020):

Hi there!

Can you please send us feedback with the Feedback Hub with this issue and paste the link here so we can more easily find your crash information on the back end?

Thanks!

@ghost commented on GitHub (Sep 25, 2020): Hi there! Can you please send us feedback with the Feedback Hub with this issue and paste the link here so we can more easily find your crash information on the back end? Thanks! ![image](https://user-images.githubusercontent.com/18221333/62478757-b69d0d00-b760-11e9-9626-1fa33c91e7c5.png) ![image](https://user-images.githubusercontent.com/18221333/62478649-6de55400-b760-11e9-806e-5aab7e085a9f.png)

claunia commented

@DHowett commented on GitHub (Sep 25, 2020):

Best way for us to link up crashes is through a Feedback Hub submission 😄

@DHowett commented on GitHub (Sep 25, 2020): Best way for us to link up crashes is through a Feedback Hub submission :smile:

claunia commented

@DHowett commented on GitHub (Sep 25, 2020):

Honestly, otherwise, those logs are as good as exist unless you have a debugger and debug symbols!

@DHowett commented on GitHub (Sep 25, 2020): Honestly, otherwise, those logs are as good as exist unless you have a debugger and debug symbols!

claunia commented

@vefatica commented on GitHub (Sep 25, 2020):

You'll have to coach me on using the feedback hub. I actually have 25 of them, going back to 8/28. Many involve CoreMessaging.dll. And many have a report ID so I imagine they were reported by WER. If it's of any value, here (file) are all 25.
event1000.txt

@vefatica commented on GitHub (Sep 25, 2020): You'll have to coach me on using the feedback hub. I actually have 25 of them, going back to 8/28. Many involve CoreMessaging.dll. And many have a report ID so I imagine they were reported by WER. If it's of any value, here (file) are all 25. [event1000.txt](https://github.com/microsoft/terminal/files/5280026/event1000.txt)

claunia commented

2026-01-31 02:29:43 +00:00

@vefatica commented on GitHub (Sep 25, 2020):

Are you still waiting for me to use the feedback hub? What "category"? I can't make WT crash at will so I have no repro scenario. The best I can do there in post/attach the event log dump as I have done here.

@vefatica commented on GitHub (Sep 25, 2020): Are you still waiting for me to use the feedback hub? What "category"? I can't make WT crash at will so I have no repro scenario. The best I can do there in post/attach the event log dump as I have done here.

claunia commented

@DHowett commented on GitHub (Sep 25, 2020):

So, okay. Here's what I need.

You may not even need to reproduce the bug with the feedback hub open, if you have crash reporting turned on.

Launch Feedback Hub, choose Feedback

this

"Add new feedback"
click next a few times. choose this category:

next, next, submit
you should be offered a link to share your feedback. it should let you copy an aka.ms... link to your clipboard. send it to me.

@DHowett commented on GitHub (Sep 25, 2020): So, okay. Here's what I need. You may not even need to reproduce the bug with the feedback hub open, if you have crash reporting turned on. 1. Launch Feedback Hub, choose `Feedback` ![image](https://user-images.githubusercontent.com/189190/94296634-ffd98e80-ff17-11ea-9a20-3be1425be0b8.png) 2. this ![image](https://user-images.githubusercontent.com/189190/94296650-08ca6000-ff18-11ea-9182-992e6eea43ec.png) 3. "Add new feedback" 4. click next a few times. choose this category: ![image](https://user-images.githubusercontent.com/189190/94296697-1f70b700-ff18-11ea-8216-4d29030dd2f8.png) 5. next, next, submit 6. you should be offered a link to share your feedback. it should let you copy an `aka.ms...` link to your clipboard. send it to me.

claunia commented

2026-01-31 02:29:43 +00:00

@vefatica commented on GitHub (Sep 25, 2020):

I submitted. On this page there's no share offer.

As for crash reporting turned on, I don't know. WERSVC starts now and then. The event log entries have report IDs. Where can I check whether it's turned on?

@vefatica commented on GitHub (Sep 25, 2020): I submitted. On this page there's no share offer. ![image](https://user-images.githubusercontent.com/61856645/94297792-13deb980-ff33-11ea-80c2-24f22c66c8a9.png) As for crash reporting turned on, I don't know. WERSVC starts now and then. The event log entries have report IDs. Where can I check whether it's turned on?

claunia commented

2026-01-31 02:29:43 +00:00

@vefatica commented on GitHub (Sep 25, 2020):

I cleared all yesterday so now I have only these.

Can't you get at all the reports that have already been sent??

@vefatica commented on GitHub (Sep 25, 2020): I cleared all yesterday so now I have only these. ![image](https://user-images.githubusercontent.com/61856645/94298764-ab90d780-ff34-11ea-8ace-04511610e586.png) Can't you get at all the reports that have already been sent??

claunia commented

@DHowett commented on GitHub (Sep 25, 2020):

Yeah, but I can't just type "github user @vefatica" into the search box ;P

Do you have a "My Feedback" section in Feedback?

If you do, you may see your new feedback in there. Click on it.

Under the title, there's a Share link:

@DHowett commented on GitHub (Sep 25, 2020): Yeah, but I can't just type "github user @vefatica" into the search box ;P Do you have a "My Feedback" section in Feedback? ![image](https://user-images.githubusercontent.com/189190/94299011-e76b7300-ff1b-11ea-92ba-066c27bb7150.png) If you do, you may see your new feedback in there. Click on it. Under the title, there's a Share link: ![image](https://user-images.githubusercontent.com/189190/94299066-feaa6080-ff1b-11ea-958f-143d1287c003.png)

claunia commented

@vefatica commented on GitHub (Sep 25, 2020):

https://aka.ms/AA9qfje

@vefatica commented on GitHub (Sep 25, 2020): https://aka.ms/AA9qfje

claunia commented

@DHowett commented on GitHub (Sep 25, 2020):

Thanks!

@DHowett commented on GitHub (Sep 25, 2020): Thanks!

claunia commented

@DHowett commented on GitHub (Sep 25, 2020):

Here's a curious question: If you update to 1.4, is it any better? The update has been out for a few days now, so the store might offer it to you. 😄

@DHowett commented on GitHub (Sep 25, 2020): Here's a curious question: If you update to 1.4, is it any better? The update has been out for a few days now, so the store might offer it to you. :smile:

claunia commented

@vefatica commented on GitHub (Sep 25, 2020):

I did update, late this morning, both stable and preview. I think two of the reports are from one of the updated ones. My app alias is for the preview.

Note that I don't actually see (or experience in any way) a crash. I stumbled on the event log stuff while debugging something else. Last week there were several times when, after working elsewhere, I went to return to WT and it wasn't there! That hasn't happened lately. As I said, it doesn't crash before my very eyes.

@vefatica commented on GitHub (Sep 25, 2020): I did update, late this morning, both stable and preview. I think two of the reports are from one of the updated ones. My app alias is for the preview. Note that I don't actually see (or experience in any way) a crash. I stumbled on the event log stuff while debugging something else. Last week there were several times when, after working elsewhere, I went to return to WT and it wasn't there! That hasn't happened lately. As I said, it doesn't crash before my very eyes.

claunia commented

@vefatica commented on GitHub (Jul 13, 2021):

These continue, all the same, 0xc000041d in Windows.UI.Xaml.dll (fault offsets are consistent for each product version). My event log has 26 of them since 1/18/2021, the two most recent, yesterday and the day before.

Though I haven't yet witnessed a crash, I still occasionally get the feeling that Terminal should be there when it's not.

@vefatica commented on GitHub (Jul 13, 2021): These continue, all the same, 0xc000041d in Windows.UI.Xaml.dll (fault offsets are consistent for each product version). My event log has 26 of them since 1/18/2021, the two most recent, yesterday and the day before. Though I haven't yet witnessed a crash, I still occasionally get the feeling that Terminal should be there when it's not.

claunia commented

@zadjii-msft commented on GitHub (Jul 13, 2021):

This sounds crazy - any chance you're changing the OS theme? There's some crashes I can see that I think root cause to the same thing as #10520, but that would have started after this was originally filed. Hmm.

@zadjii-msft commented on GitHub (Jul 13, 2021): This sounds crazy - any chance you're changing the OS theme? There's some crashes I can see that I think root cause to the same thing as #10520, but that would have started after this was originally filed. Hmm.

claunia commented

2026-01-31 02:29:46 +00:00

@vefatica commented on GitHub (Jul 13, 2021):

If you mean precisely Settings\Personalization\Themes, no, I never go there. I rarely even visit Settings\Personalization at all.

@vefatica commented on GitHub (Jul 13, 2021): If you mean precisely Settings\Personalization\Themes, no, I never go there. I rarely even visit Settings\Personalization at all.

claunia commented

@zadjii-msft commented on GitHub (Nov 8, 2021):

I hate to be that guy, but did this get better in 1.12? That one's got an updated MUX that should have fixed this.

@zadjii-msft commented on GitHub (Nov 8, 2021): I hate to be that guy, but did this get better in 1.12? That one's got an updated MUX that should have fixed this.

claunia commented

2026-01-31 02:29:47 +00:00

@vefatica commented on GitHub (Nov 8, 2021):

It's hard to say. I have these from the 1.12 preview.

v:\> 2>NUL dumpel -t -e 1000 -format dts -l application -m "Application Error" | grep 1\.12\.2110 | cut -d " " -f1,14
10/23/2021  14:37:47    Faulting Windows.UI.Xaml.dll,
11/7/2021   10:21:11    Faulting Windows.UI.Xaml.dll,

@vefatica commented on GitHub (Nov 8, 2021): It's hard to say. I have these from the 1.12 preview. ``` v:\> 2>NUL dumpel -t -e 1000 -format dts -l application -m "Application Error" | grep 1\.12\.2110 | cut -d " " -f1,14 10/23/2021 14:37:47 Faulting Windows.UI.Xaml.dll, 11/7/2021 10:21:11 Faulting Windows.UI.Xaml.dll, ```

claunia commented

2026-01-31 02:29:47 +00:00

@zadjii-msft commented on GitHub (Nov 8, 2021):

Welp, not much I can do with that. The feedback from back in September also has nothing useful in it anymore - possible that Feedback Hub just lost it ¯\_(ツ)_/¯. Nothing I can find in the backend related to that original filing.

Since this is a crash that seemingly happens at random, it'd be hard to get a real trace with the FH. Crazy idea though: can you try following the steps in this post to set up automatic crash dumps? If that works, then you should be able to automatically get a .dmp of the terminal when it crashes. Then, can you zip that dump up and send it to us, so we can investigate?

Alternatively, enabling post-mortem debugging would likely be even more useful. Anything we can do to get a stack.

@zadjii-msft commented on GitHub (Nov 8, 2021): Welp, not much I can do with that. The feedback from back in September also has nothing useful in it anymore - possible that Feedback Hub just lost it ¯\\\_(ツ)_/¯. Nothing I can find in the backend related to that original filing. Since this is a crash that seemingly happens at random, it'd be hard to get a real trace with the FH. Crazy idea though: can you try following the steps in [this post](https://www.meziantou.net/tip-automatically-create-a-crash-dump-file-on-error.htm) to set up automatic crash dumps? If that works, then you should be able to automatically get a `.dmp` of the terminal when it crashes. Then, can you zip that dump up and send it to us, so we can investigate? Alternatively, enabling post-mortem debugging would likely be even more useful. Anything we can do to get a stack.

claunia commented

2026-01-31 02:29:47 +00:00

@vefatica commented on GitHub (Nov 8, 2021):

OK, did the local dumps thing. It's funny ... that local dump stuff came up in another, totally unrelated, forum and for totally unrelated reasons ... just a few days ago. I had never heard of it before (and may not again).

How do you do the post-mortem thing?

@vefatica commented on GitHub (Nov 8, 2021): OK, did the local dumps thing. It's funny ... that local dump stuff came up in another, totally unrelated, forum and for totally unrelated reasons ... just a few days ago. I had never heard of it before (and may not again). How do you do the post-mortem thing?

claunia commented

2026-01-31 02:29:48 +00:00

@zadjii-msft commented on GitHub (Nov 8, 2021):

OK, did the local dumps thing

TBH, no one I've actually asked for that so far has actually responded yet, so I don't totally know if it works. I'm 🤞, because it seems handy.

How do you do the post-mortem thing?

windbgx.exe -I (the -I is case-sensitive)

that's by far one of the most important tools I use for debugging crashes like this. Just automatically attaches itself to anything that crashes, so you can get a stack trace for the moment of the crash. Sometimes, the real error is a little obscured, especially when the error was thrown, caught, and crashed somewhere above the exception handler, but it should narrow down the problem space dramatically.

@zadjii-msft commented on GitHub (Nov 8, 2021): > OK, did the local dumps thing TBH, no one I've actually asked for that so far has actually responded yet, so I don't totally know if it works. I'm 🤞, because it seems handy. > How do you do the post-mortem thing? [`windbgx.exe -I`](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/enabling-postmortem-debugging) (the `-I` is case-sensitive) that's by far one of the most important tools I use for debugging crashes like this. Just automatically attaches itself to anything that crashes, so you can get a stack trace for the moment of the crash. Sometimes, the real error is a little obscured, especially when the error was thrown, caught, and crashed somewhere above the exception handler, but it should narrow down the problem space dramatically.

claunia commented

2026-01-31 02:29:48 +00:00

@vefatica commented on GitHub (Nov 8, 2021):

Hmmm! I have this now.

Debugger : REG_SZ : "C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld

If I do the WinDbg thing, it might get annoying if WinDbg opens up whenever anything crashes (especially if I'm doing the programming). Is that how it works? And how would I undo windbg -I?

@vefatica commented on GitHub (Nov 8, 2021): Hmmm! I have this now. `Debugger : REG_SZ : "C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld` If I do the WinDbg thing, it might get annoying if WinDbg opens up whenever anything crashes (especially if I'm doing the programming). Is that how it works? And how would I undo `windbg -I`?

claunia commented

2026-01-31 02:29:48 +00:00

@zadjii-msft commented on GitHub (Nov 8, 2021):

That looks like Vs is set up as the post-mortem, but I've honestly never used VS as the post-mortem debugger. Someone else might have more tips.

it might get annoying if WinDbg opens up whenever anything crashes (especially if I'm doing the programming)

Meh, it sometimes does, but the annoyance is a helpful tool for writing crash-free code 😄

And how would I undo windbg -I?

Right here in the windbg settings:

@zadjii-msft commented on GitHub (Nov 8, 2021): That _looks_ like Vs is set up as the post-mortem, but I've honestly never used VS as the post-mortem debugger. Someone else might have more tips. > it might get annoying if WinDbg opens up whenever anything crashes (especially if I'm doing the programming) Meh, it sometimes does, but the annoyance is a helpful tool for writing crash-free code 😄 > And how would I undo `windbg -I`? Right here in the windbg settings: ![image](https://user-images.githubusercontent.com/18356694/140793495-da5ed0e1-04ff-41d0-a9a6-d9ceb046df20.png)

claunia commented

@ghost commented on GitHub (Nov 12, 2021):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Nov 12, 2021): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.

claunia commented

@vefatica commented on GitHub (Nov 12, 2021):

Here's a recent (Nov 10) crash dump.
WT_crashdump.zip

@vefatica commented on GitHub (Nov 12, 2021): Here's a recent (Nov 10) crash dump. [WT_crashdump.zip](https://github.com/microsoft/terminal/files/7529967/WT_crashdump.zip)

claunia commented

@vefatica commented on GitHub (Nov 16, 2021):

Here's another.
WT_crashdump1115.zip

Shall I keep posting these?

@vefatica commented on GitHub (Nov 16, 2021): Here's another. [WT_crashdump1115.zip](https://github.com/microsoft/terminal/files/7548782/WT_crashdump1115.zip) Shall I keep posting these?

claunia commented

@zadjii-msft commented on GitHub (Nov 16, 2021):

both those dumps are the same root stack. They're both failure f0877884-1f30-8b0b-45b3-c57661a16a8c, in the stack like:

 # Child-SP          RetAddr               Call Site
00 000000b2`806fe7d0 00007ff9`f828f398     Windows_UI_Xaml!std::pair<void *,ctl::WeakRefPtr>::operator=<std::pair<void *,ctl::WeakRefPtr>,0>+0x6 [onecore\internal\sdk\inc\ucrt\stl120\utility @ 198] 
01 000000b2`806fe800 00007ff9`f828e6f8     Windows_UI_Xaml!std::_Move_unchecked<std::pair<void *,ctl::WeakRefPtr> *,std::pair<void *,ctl::WeakRefPtr> *>+0x28 [onecore\internal\sdk\inc\ucrt\stl120\xutility @ 2086] 
02 (Inline Function) --------`--------     Windows_UI_Xaml!std::vector<std::pair<void *,ctl::WeakRefPtr>,std::allocator<std::pair<void *,ctl::WeakRefPtr> > >::erase+0x9 [onecore\internal\sdk\inc\ucrt\stl120\vector @ 1212] 
03 (Inline Function) --------`--------     Windows_UI_Xaml!containers::detail::vector_tree<containers::detail::map_traits<void *,ctl::WeakRefPtr,std::less<void>,std::allocator<std::pair<void *,ctl::WeakRefPtr> >,0> >::erase+0x9 [onecoreuap\windows\dxaml\xcp\components\base\inc\vector_tree.h @ 306] 
04 000000b2`806fe830 00007ff9`f828e66f     Windows_UI_Xaml!DirectUI::DXamlCore::UnregisterLayoutUpdatedEventSource+0x60 [onecoreuap\windows\dxaml\xcp\dxaml\lib\dxamlcore.cpp @ 1887] 
05 000000b2`806fe860 00007ff9`d8ddc081     Windows_UI_Xaml!DirectUI::FrameworkElement::remove_LayoutUpdated+0x11f [onecoreuap\windows\dxaml\xcp\dxaml\lib\frameworkelement_partial.cpp @ 962] 
06 000000b2`806fe8c0 000001e4`5d766ac0     Microsoft_Terminal_Control!winrt::impl::event_revoker<winrt::Windows::UI::Xaml::IFrameworkElement,&winrt::impl::abi<winrt::Windows::UI::Xaml::IFrameworkElement,void>::type::`vcall'{400}'>::revoke_impl+0x1d [C:\a\_work\1\s\src\cascadia\TerminalControl\Generated Files\winrt\base.h @ 5604] 
07 000000b2`806fe8c8 000000b2`806fe920     0x000001e4`5d766ac0

Unfortunately, there's some 1000 crashes PER DAY for that crash, so I'm gonna bump it's priority.
#11138 has a lot more info in it on that particular stack. (#11138 also looks like the same thing)
These now look different from the ProgressRing::OnForegroundColorPropertyChanged crash that it was when you first posted this

I'm actually going to move discussion into /dup #11366 since that thread has a lot more info in it already. The dumps were quite useful for finding the failure GUID on the backend, actually!

@zadjii-msft commented on GitHub (Nov 16, 2021): * both those dumps are the same root stack. They're both failure `f0877884-1f30-8b0b-45b3-c57661a16a8c`, in the stack like: ``` # Child-SP RetAddr Call Site 00 000000b2`806fe7d0 00007ff9`f828f398 Windows_UI_Xaml!std::pair<void *,ctl::WeakRefPtr>::operator=<std::pair<void *,ctl::WeakRefPtr>,0>+0x6 [onecore\internal\sdk\inc\ucrt\stl120\utility @ 198] 01 000000b2`806fe800 00007ff9`f828e6f8 Windows_UI_Xaml!std::_Move_unchecked<std::pair<void *,ctl::WeakRefPtr> *,std::pair<void *,ctl::WeakRefPtr> *>+0x28 [onecore\internal\sdk\inc\ucrt\stl120\xutility @ 2086] 02 (Inline Function) --------`-------- Windows_UI_Xaml!std::vector<std::pair<void *,ctl::WeakRefPtr>,std::allocator<std::pair<void *,ctl::WeakRefPtr> > >::erase+0x9 [onecore\internal\sdk\inc\ucrt\stl120\vector @ 1212] 03 (Inline Function) --------`-------- Windows_UI_Xaml!containers::detail::vector_tree<containers::detail::map_traits<void *,ctl::WeakRefPtr,std::less<void>,std::allocator<std::pair<void *,ctl::WeakRefPtr> >,0> >::erase+0x9 [onecoreuap\windows\dxaml\xcp\components\base\inc\vector_tree.h @ 306] 04 000000b2`806fe830 00007ff9`f828e66f Windows_UI_Xaml!DirectUI::DXamlCore::UnregisterLayoutUpdatedEventSource+0x60 [onecoreuap\windows\dxaml\xcp\dxaml\lib\dxamlcore.cpp @ 1887] 05 000000b2`806fe860 00007ff9`d8ddc081 Windows_UI_Xaml!DirectUI::FrameworkElement::remove_LayoutUpdated+0x11f [onecoreuap\windows\dxaml\xcp\dxaml\lib\frameworkelement_partial.cpp @ 962] 06 000000b2`806fe8c0 000001e4`5d766ac0 Microsoft_Terminal_Control!winrt::impl::event_revoker<winrt::Windows::UI::Xaml::IFrameworkElement,&winrt::impl::abi<winrt::Windows::UI::Xaml::IFrameworkElement,void>::type::`vcall'{400}'>::revoke_impl+0x1d [C:\a\_work\1\s\src\cascadia\TerminalControl\Generated Files\winrt\base.h @ 5604] 07 000000b2`806fe8c8 000000b2`806fe920 0x000001e4`5d766ac0 ``` * Unfortunately, there's some 1000 crashes PER DAY for that crash, so I'm gonna bump it's priority. * #11138 has a lot more info in it on that particular stack. (#11138 also looks like the same thing) * These now look different from the `ProgressRing::OnForegroundColorPropertyChanged` crash that it was when you first posted this I'm actually going to move discussion into /dup #11366 since that thread has a lot more info in it already. The dumps were quite useful for finding the failure GUID on the backend, actually!

claunia commented