Crash on start (the ApplicationModel::IPackageStatics_::Current / XamlControlsResources thread)
#15583
Comments
|
Tried to uninstall the updates which had been installed the same day, unfortunately even though they provide an uninstall option it appears to do nothing, after rebooting the are still in the installed list and the uninstall list. Ended up doing a system restore from the point just before the updates were installed. This fixed terminal but broke WSL, which needed a repair from advanced options to address. So it seems that the issue is related to one of the updates I listed, but can't determine which one. |
|
possibly related? #15526 |
|
Looks like a different issue, as this was a crashing no matter what and a different faulting module too. |
|
same on |
|
Very interesting. That first failure bucket above ( The second one has more hits ( For internal folks, MSFT-44828510 |
|
All the hits so far are on Windows 11 22621, and all of them are using XAML 2.8. Interesting. Oh, the 1.17 ones aren't. That's interesting too. |
|
Would more event viewer crash report details help, or would they all just be duplicates? |
|
They'd probably all just be duplicates, unfortunately. Would you be willing or able to install the new WinDbg and capture a Time Travel Trace when you start Terminal? I'd be happy to write up steps if so! 😄 |
|
I'm guessing that would require me to replicate the issue, by reinstalling the offending updates? If so unfortunately take would prevent me for working for pretty much an entire day, as it requires restoring from a system restore point to recover from which in itself takes many hours, but after that requires fixing WSL as it gets corrupted by the restore. If the KB uninstall process worked it wouldn't be a problem. I could try to repo on an old machine, but that's Windows 10 not Windows 11. If someone has access to a sacrificial Windows 11 box, installing the mentioned KB's should be enough to trigger it. |
|
I'm experiencing this on Windows 10 2020 H2. Just updated from 1.13 or 1.14 (can't remember which--and unfortunately, through the Windows Store, no way to revert to a last known good version! Boo!). Current version is 1.18.2305.26002. |
|
I also tried the non-preview version: 1.17.2305.26001, and it too, crashes. Now, I open my terminal with the Run as Administrator option. So, I just tried opening it without that, and the non-preview version works. I will try the preview version and report my findings. |
|
Hmm, somehow, I made it so that Windows Terminal Preview would always open in Administrator mode, and I cannot seem to find how I did that. I checked the usual suspects, RIGHT+CLICK the tile in the Start Menu/Task bar, unable to access it there. Dig on the HDD to find the executable location and check the properties--no such luck, yet, it always attempts to open as Admin... |
|
OK, found it, I had set it in the settings.json, which, if Windows Terminal is not opening, you will not be able to get to unless you happen to know where MSFT BURIED the file. Why are these files in such an obtuse location, difficult to find? This should be much simpler, like how Linux does it. In any event, after setting my default terminal profile's So, there's some bug with elevating processes. |
|
This may be related to #9452. I say this because 1) My permissions don't match the permissions listed (I added myself as Full Control because "reasons" that I needed at the time I did this; 2) In the Application Event Viewer, I see an error message and it references v1.17 of Windows Terminal Preview even though I'm trying to launch the newly installed 1.18. So, most likely, at least in my case, it's because of the above-referenced issue. |
|
@stevenh it's been a couple months now - any chance you've taken a subsequent update that fixed this for you? MSFT:44828510 is pointing at failure Stackwhich blames Interestingly, this looks very similar to Stack from #15745Dang both of those look exactly the same. NOTABLY, they hit on basically all OS versions, but also exclusively on 1.17. Maybe this was fixed in the giant process model re-write for 1.18? 1.18 crash:
1.18 version of the stack
@fourpastmidnight if what you're seeing is related to running elevated, then it might also be #15576. But if you messed with the permissions on WindowsApps, well, honestly that could be anything. I've literally never seen that work out for someone 😑 I'm gonna collapse your comments as off-topic though, to try and narrow this down to the root cause OP is seeing. |
|
From a 1.18 dump |
|
Oh dear. Now I remember where I've seen this. #14961 mentioned a similar crash on start, and we pegged that down to an ACLs issue. Combining notes:
Now, perhaps it's time for some big picture questions. We've gotten a bunch of these since 1.16. Often as admin, but not exclusively. Did we become more susceptible to this in recent releases? The move to the MUX framework package comes to mind as a possible cause. Maybe we're relying on loading that (rather than out of our package), and a badly-permissioned MUX package causes us to explode. Often, we find these reports after someone messed with permissions manually, but not always. I sure hope there's not a bug in the FWP installer that leaves a MUX with bad permissions. I idly wonder if we can easily whip up a powershell script that could detect the bad permissions. Looks like if that theory is correct, then a whole bunch of apps would be affected - Maps, Camera, Feedback Hub, the WSA app, the print queue app... holy butts I found a bug that had meaningful info in it: MSFT:45128013. that's fixed in os.2020!8470532 (feb 6, 2023) (and is a cherry pick of !8469169, which links MSFT:32005359 and MSFT:32005359). It was also duped to MSFT:44757004, which was fixed in os2020!9113385 (Jul 12, 2023) |
|
We might also be able to glean something from the output of the following script: $results = @()
$allPackages = Get-AppxPackage
# First, dump all the XAML packages
$allPackages | Where-Object { $_.PackageFullName -like "*xaml*" }
write-output "----------------------------------------"
# Iterate over all regkeys that start with "AppX" in HKEY_CURRENT_USER\Software\Classes
$keys = Get-ChildItem HKCU:\Software\Classes | Where-Object { (Get-ItemProperty $_.PSPath) -like "*AppX*" }
foreach ($key in $keys) {
# if the name is LITERALLY "HKEY_CURRENT_USER\Software\Classes\*", skip it
if ($key.Name -eq "HKEY_CURRENT_USER\Software\Classes\*") {
continue
}
# Does the key have a "Shell/open" subkey?
if (Test-Path "$($key.PSPath)\Shell\open") {
# Look for "PackageId" under the shell/open subkey
$packageId = (Get-ItemProperty "$($key.PSPath)\Shell\open").PackageId
# Is the package installed?
$package = $allPackages | Where-Object { $_.PackageFullName -eq $packageId }
if ($package) {
# Uncomment to list installed packages in Classes. Left commented out for privacy.
# Write-Host "`e[32m$packageId`e[m -> $($package.PackageFullName)"
continue
}
Write-Host "$key -> `e[31m$packageId`e[m wasn't found"
$results += [PSCustomObject]@{
Key = $key.Name
PackageId = $packageId
}
}
else{
write-output "didn't find 'Shell\open' under `e[33m$key`e[m"
}
}
write-output "----------------------------------------"
write-output "Summary: These we couldn't find`n"
write-output $resultsThat'll list off all the "XAML" apps you might have (presumably, mostly Microsoft.UI.XAML ones). The second part finds some reg keys that might be stale - I'm gonna be honest I don't totally understand the root cause of the bug that spawned that script. But if Microsoft.UI.Xaml shows up in the summary at the end, well, that'd be unexpected for sure. |
|
LASTLY: There's a running theory amongst some other folks that issues like this were caused by updates-in-progress. Like, Terminal tried to use a MUX that was partially installed, and got stuck, until the next reboot. Something like that. That might explain why at least one of these failures had a whole bunch of hits right after we released 1.18, but nearly none since. It sounded like a reboot would fix it, or at least kick things to get them going (which is annoying but not the end of the world). I was also given a BIG HAMMER script1 that would collect a boatload of diagnostics. I believe it'll only work on Insiders builds, and will almost certainly have PII in it. If anyone else is hitting this and we can't get to the root cause, then email me (then @ me here so I make sure to check the spam filter) and we can use that script privately to try and get those logs. Footnotes
|
I ended up reverting all the Windows updates that had been applied recently and have not had it happen since thankfully. It was a very painful process as the uninstall option never works so had to do full system rollback which also has issues, requiring repairs after. Sorry can't be more helpful. |
|
If it helps, on my system Update: Current main branch works on my system (10.0.19045.3324). When WT was not working (in April'23), it seemed to me that my Windows instance did not have some updated component (MUX). Now everything works. |
That's so weird. The subsequent commit is 7a2e4f8, and that doesn't look like it should cause anything like this... Heck, there's not a ton of commits around https://github.com/microsoft/terminal/commits/main?after=3830c62a814e0d55d8899243d0fd48891cc2d93f+264&branch=main&qualified_name=refs%2Fheads%2Fmain that look like what's reported here. |
|
Indeed it is. Apparently I then rolled back to earlier commits after WT started crashing, it seems due to the lack of MUX 2.8 in my system. Apparently WT stopped working after the following commit: |
|
Yea, but we didn't upgrade to MUX 2.8 till 17cf44f, like, 26 commits later: 2acdc9d...17cf44f That does seem like a reasonable explanation though. That might explain why |
|
Oh hey look at that, we posted at the same time. THAT looks like the commit I'd blame too. |
|
@o-sdn-o can you run the PWSH script in #15583 (comment) and share the output? That might be enlightening? |
|
|
MUX 2.8 (if I understood correctly) came to my system with some recent updates. I didn't install it specifically. It wasn't there in the spring (April'23). This seems to be an update from June'2023: |
This comment was marked as off-topic.
This comment was marked as off-topic.
ApplicationModel::IPackageStatics_::Current / XamlControlsResources thread)
|
Hey folks in this thread - is this still happening/? Weird that we got like, a lot of reports of this right after the original 1.19pre/1.18 releases, and then like, none after that. And seemingly none for the 1.20pre/1.19 release. I'm wondering if it was in fact, just a torn state on the MUX package, that maybe got resolved by the OS in the meantime? |
Looks like this was resolved by the OS and doesn't happen anymore. |
|
It happened to me a few weeks ago. But then I had a thought. I had recently rebooted and hadn't started up any WSL session yet. Maybe the underlying VM was slow to boot/become ready? So I closed the non-working Ubuntu terminal tab and opened a new one. It came right up with no issues. 😕 But at least it worked! 🙂 |
|
Well, I'm gonna close this out then. Undoubtably, we'll get some reports in the future about weird torn packaging state crashes again, but I'm not sure there's much we can do on our side to mitigate them 🤷 |
Windows Terminal version
1.18.2305.26002
Windows build number
10.0.22621.1848
Other Software
Seemed to start after installing windows 11 updates:
2023-06 Cumulative Update for Windows 11 Version 22H2 for x64-based Systems (KB5027231)
2023-05 Cumulative Update Preview for Windows 11 Version 22H2 for x64-based Systems (KB5026446)
2023-06 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Windows 11, version 22H2 for x64 (KB5027119)
Windows Malicious Software Removal Tool x64 - v5.114 (KB890830)
Steps to reproduce
Try to start Windows Terminal.
I have uninstalled, reinstalled tried the latest dev build 1.18.2305.26002 as well as 1.17.2305.26001 both just crash on start up.
Expected Behavior
Terminal runs
Actual Behavior
Crash to desktop.
From the event logs
The text was updated successfully, but these errors were encountered: