Skip to content
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

Cannot install WSL on latest Windows Insider dev build #11327

Open
2 tasks done
MatthewL246 opened this issue Mar 19, 2024 · 24 comments
Open
2 tasks done

Cannot install WSL on latest Windows Insider dev build #11327

MatthewL246 opened this issue Mar 19, 2024 · 24 comments
Assignees

Comments

@MatthewL246
Copy link

MatthewL246 commented Mar 19, 2024

Windows Version

Microsoft Windows [Version 10.0.26080.1400]

WSL Version

2.1.5

Are you using WSL 1 or WSL 2?

  • WSL 2
  • WSL 1

Kernel Version

N/A

Distro Version

N/A

Other Software

Docker Desktop (Docker version 25.0.3, build 4debf41)

Repro Steps

I recently updated to the latest Windows Insider dev build, which is Windows 11 Insider Preview 10.0.26080.1201 (ge_release_upr). After updating Windows, I ran wsl --update, which caused the "Catastrophic failure" error and completely broke my WSL setup. It seems like the failed update uninstalled WSL and I can't reinstall it.

Expected Behavior

I expected WSL to install successfully.

Actual Behavior

Running any WSL command produces the following output.

Windows Subsystem for Linux must be updated to the latest version to proceed. You can update by running 'wsl.exe --update'.
For more information please visit https://aka.ms/wslinstall

Press any key to install Windows Subsystem for Linux.
Press CTRL-C or close this window to cancel.
This prompt will time out in 60 seconds.
Operation aborted

Running wsl --update or wsl --install produces the following output.

Downloading: Windows Subsystem for Linux 2.1.5
Installing: Windows Subsystem for Linux 2.1.5
Catastrophic failure

Manually downloading the MSI from the GitHub releases shows these error messages.
image
image
image

Diagnostic Logs

Logs from running wsl --install: WslLogs-2024-03-19_19-06-02.zip
WSL install logs from temp folder: wsl-install-logs.txt and MSI65cb2.LOG

Copy link

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

@MatthewL246
Copy link
Author

This seems more similar to #11319

@pmartincic
Copy link
Collaborator

Are you able to get more logs using the instructions from here? https://learn.microsoft.com/en-us/windows/win32/appxpkg/troubleshooting?redirectedfrom=MSDN

@pmartincic
Copy link
Collaborator

This seems more similar to #11319

I agree, I think they're probably the same.

@MatthewL246
Copy link
Author

MatthewL246 commented Mar 20, 2024

Here's the result of Get-AppxLog after trying the update again: appxlog.txt
Here are the AppXDeployment-Server logs from Event Viewer: AppXDeployment-Server.zip

Similarly to the other issue, it looks like the installer is trying to install the appx into my D: drive, which is failing.

Here's a screenshot of searching my PC for "windowssubsystemforlinux". It looks like I have a few older versions hanging around, and it does seem like version 2.1.5.0 is trying to be installed into D:.
image

The D:\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3 directory has some contents in it but does not show up in Get-AppxPackage.
image

@pmartincic
Copy link
Collaborator

pmartincic commented Mar 20, 2024

Thank-you for the logs, much appreciated. I assume you also have vanilla settings for this?
image

@MatthewL246
Copy link
Author

MatthewL246 commented Mar 20, 2024

Yes, my settings look exactly the same.

I should add that my D: drive is an internal SSD, so I can't easily remove it to test if that fixes it.

@github-actions github-actions bot mentioned this issue Mar 25, 2024
2 tasks
@pmartincic
Copy link
Collaborator

Sorry for the hangup. I'm testing a fix that I think will avoid us getting in this state, but I'm not sure about getting out of it.

If you still have this environment can you collect logs via the below script that github won't let me add as an attachment?

#
# GetDeploymentLogs-Desktop.ps1 is a PowerShell script designed to collect
# various logs and system information to diagnose App deployment problems. 
# To run this script from Explorer, right-click on its icon and choose "Run with PowerShell".
#
# All command line parameters are reserved for use internally by the script.
# Users should launch this script from Explorer.
#

param(
    [switch]$Force = $false,
    [switch]$EnableTracing = $false
    )

function PrintMessageAndExit($ErrorMessage, $ReturnCode)
{
    Write-Host $ErrorMessage
    if (!$Force)
    {
        Pause
    }
    exit $ReturnCode
}

$ScriptPath = $null
try
{
    $ScriptPath = (Get-Variable MyInvocation).Value.MyCommand.Path
    $ScriptDir = Split-Path -Parent $ScriptPath
}
catch {}

# Get the ID and security principal of the current user account
$myWindowsID=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal=new-object System.Security.Principal.WindowsPrincipal($myWindowsID)
  
# Get the security principal for the Administrator role
$adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator
  
 # Check to see if we are currently running "as Administrator"
 if ($myWindowsPrincipal.IsInRole($adminRole))
 {
    # We are running "as Administrator" - so change the title and background color to indicate this
    $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)"
    clear-host
 }
 else
 {
    # We are not running "as Administrator" - so relaunch as administrator
    
    # Create a new process object that starts PowerShell
    $newProcess = new-object System.Diagnostics.ProcessStartInfo "PowerShell";
    
    # Specify the current script path and name as a parameter
    $newProcess.Arguments = $myInvocation.MyCommand.Definition + ' -ExecutionPolicy Unrestricted'
    
    # Indicate that the process should be elevated
    $newProcess.Verb = "runas";
    
    # Start the new process
    [System.Diagnostics.Process]::Start($newProcess) > $null;
    
    # Exit from the current, unelevated, process
    exit
 }
  
$LogsFolderName = 'AppxLogs' + (get-date -uformat %s)
$LogsDestinationPath = $env:TEMP + '\' + $LogsFolderName
$CabPath = $LogsDestinationPath + '.zip'

$SystemEventLogsPath = $env:windir + '\System32\winevt\Logs\'
$WULogsPath = $env:windir + '\Logs\windowsupdate\'
$UpgradeLogs = $env:windir + '\Panther\'

$SystemEventLogFileList = 
    @(
        "Microsoft-Windows-AppXDeployment%4Operational.evtx",
        "Microsoft-Windows-AppXDeploymentServer%4Operational.evtx",
        "Microsoft-Windows-AppxPackaging%4Operational.evtx",
        "Microsoft-Windows-StateRepository%4Operational.evtx",
        "Microsoft-Windows-AppReadiness%4Admin.evtx",
        "Microsoft-Windows-AppReadiness%4Operational.evtx",
        "Microsoft-Windows-TWinUI%4Operational.evtx",
        "Microsoft-Windows-AppModel-Runtime%4Admin.evtx",
        "Microsoft-Windows-AppHost%4Admin.evtx",
        "Microsoft-Windows-ApplicationResourceManagementSystem%4Operational.evtx",
        "Microsoft-Windows-CoreApplication%4Operational.evtx",
        "Microsoft-Windows-AppID%4Operational.evtx",
        "Microsoft-Windows-AppLocker%4EXE and DLL.evtx",
        "Microsoft-Windows-AppLocker%4Packaged app-Execution.evtx",
        "Microsoft-Windows-AppLocker%4Packaged app-Deployment.evtx",
        "Microsoft-Windows-AppLocker%4MSI and Script.evtx",

        "Microsoft-Windows-CodeIntegrity%4Operational.evtx",
        "Microsoft-Windows-Kernel-StoreMgr%4Operational.evtx",
        "Microsoft-Windows-Store%4Operational.evtx",
        "Microsoft-Client-Licensing-Platform%4Admin.evtx",
        "Microsoft-WS-Licensing%4Admin.evtx",

        "Microsoft-Windows-PackageStateRoaming%4Operational.evtx",
        "Microsoft-Windows-DeviceSync%4Operational.evtx",
        "Microsoft-Windows-SettingSync%4Debug.evtx",
        "Microsoft-Windows-SettingSync%4Operational.evtx",
        "Microsoft-Windows-SettingSync-Azure%4Debug.evtx",
        "Microsoft-Windows-SettingSync-Azure%4Operational.evtx",

        "System.evtx",
        "Application.evtx",
        "Microsoft-Windows-WER-Diag%4Operational.evtx",
        "Microsoft-Windows-AppID%4Operational.evtx",
        "Microsoft-Windows-ApplicabilityEngine%4Operational.evtx",
        "Microsoft-Windows-WindowsUpdateClient%4Operational.evtx",
        "Microsoft-Windows-Winlogon%4Operational.evtx",

        "Microsoft-Windows-Shell-Core%4ActionCenter.evtx",
        "Microsoft-Windows-Shell-Core%4Operational.evtx",

        "Microsoft-Windows-User Profile Service%4Operational.evtx"
    )

$SourceDestinationPairs = 
        (
            (($UpgradeLogs + 'setup*.log'), ($LogsDestinationPath + '\Panther\')),
            (($WULogsPath + '*.etl'), ($LogsDestinationPath + '\WindowsUpdate\')),
            (($env:windir + '\Logs\CBS\CBS.log'), ($LogsDestinationPath + '\CBS\')),
            (($env:windir + '\Logs\DISM\DISM.log'), ($LogsDestinationPath + '\DISM\')),
            (($env:ProgramData + '\Microsoft\Windows\AppxProvisioning.xml'), ($LogsDestinationPath + '\')),
            (($env:ProgramData + '\Microsoft\Windows\AppRepository\StateRepository*'), ($LogsDestinationPath + '\StateRepository\')),
            (($env:ProgramData + '\Microsoft\Windows\WER\*'), ($LogsDestinationPath + '\WER\'))
        )

$RegExportsDestinationPath = $LogsDestinationPath + '\RegistryExports\'
New-Item -ItemType Directory -Force -Path $RegExportsDestinationPath > $null

$RegistrySourceDestinationPairs = 
        (
            (("HKEY_LOCAL_MACHINE\System\SetUp\Upgrade\AppX"), ($RegExportsDestinationPath + '\UpgradeAppx.reg')),
            (("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateRepository"), ($RegExportsDestinationPath + '\StateRepository.reg')),
            (("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OOBE"), ($RegExportsDestinationPath + '\OOBE.reg')),
            (("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MUI\UILanguages"), ($RegExportsDestinationPath + '\UILanguages.reg')),
            (("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FastCache"), ($RegExportsDestinationPath + '\Fastcache.reg')),
            (("HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Appx"), ($RegExportsDestinationPath + '\AppxPolicies.reg')),
            (("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx"), ($RegExportsDestinationPath + '\Appx.reg')),
            (("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppReadiness"), ($RegExportsDestinationPath + '\AppReadiness.reg')),
            (("HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel"), ($RegExportsDestinationPath + '\AppModelSettings.reg')),
            (("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel"), ($RegExportsDestinationPath + '\AppModel.reg'))
        )

Write-Host 'Creating Destination Folder and Gathering Logs ' $LogsDestinationPath
New-Item -ItemType Directory -Force -Path $LogsDestinationPath > $null

Write-Progress -Activity 'Collecting Logs' -Id 10041

$EventLogsFolderPath = ($LogsDestinationPath + '\EventLogs\')
New-Item -ItemType Directory -Force -Path $EventLogsFolderPath > $null

# Copy Event Logs
foreach ($EventLogFile in $SystemEventLogFileList)
{
    $EventLogFilePath = ($SystemEventLogsPath + $EventLogFile)
    Copy-Item -Path $EventLogFilePath -Destination $EventLogsFolderPath -Force
}

foreach ($SDPair in $SourceDestinationPairs)
{
    New-Item -ItemType Directory -Force -Path $SDPair[1] > $null
    Copy-Item -Path $SDPair[0] -Destination $SDPair[1] -Recurse -Force > $null
}

foreach ($RegistrySDPair in $RegistrySourceDestinationPairs)
{
    reg export $RegistrySDPair[0] $RegistrySDPair[1] /y > $null
}

$AppDataPath = $env:LOCALAPPDATA + '\Packages'
$WindowsAppPath = $env:ProgramFiles + '\WindowsApps'
$AppRepositoryPath = $env:ProgramData + '\Microsoft\Windows\AppRepository'

Get-AppxPackage -AllUsers > ($LogsDestinationPath + '\GetAppxPackageAllUsersOutput.txt')
dir -Path $AppDataPath -Recurse -Force -ErrorAction SilentlyContinue > ($LogsDestinationPath + '\AppDataFolderList.txt')
dir -Path $WindowsAppPath -Force -ErrorAction SilentlyContinue > ($LogsDestinationPath + '\WindowsAppFolderList.txt')
dir -Path $AppRepositoryPath -Force -ErrorAction SilentlyContinue > ($LogsDestinationPath + '\AppRepositoryFileList.txt')

Write-Progress -Activity 'Creating Zip Archive' -Id 10041
Add-Type -Assembly "System.IO.Compression.FileSystem";
[System.IO.Compression.ZipFile]::CreateFromDirectory($LogsDestinationPath, $CabPath);

Write-Progress -Activity 'Done' -Completed -Id 10041
Write-Warning "Note: Below Zip file contains system, app and user information useful for diagnosing Application Installation Issues."
Write-Host 'Please upload zip and share a link : '
Write-Host $CabPath
Pause

@MatthewL246
Copy link
Author

Here are the files generated by that script after reproducing the issue again. I split it into multiple parts due to GitHub's file upload size limit, just remove the second .zip extension to extract them.
AppxLogs1711469913.86496.zip.001.zip
AppxLogs1711469913.86496.zip.002.zip

@MatthewL246
Copy link
Author

MatthewL246 commented Mar 27, 2024

After some messing around, I found a workaround for this issue. I installed the old v1.2.5 version using the MSIX bundle, and then I updated through several in-between releases (using the MSIX bundles only, I don't remember the exact order) until I got to the latest v2.1.5. Everything seems to be working fine now. Attempting to reinstall v2.1.5 through the MSI instead of the MSIX bundle still breaks everything for me, though, so it does not look like the core issue here is resolved.

WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.26085.1

@pmartincic
Copy link
Collaborator

Thanks for the clue on msi vs msix installation. Fwiw, no changes have been released yet.

@MatthewL246
Copy link
Author

Just curious, will there be any differences in my WSL installation from using the MSIX instead of the MSI? Also, why does wsl --update use the MSI by default?

@pmartincic
Copy link
Collaborator

Just curious, will there be any differences in my WSL installation from using the MSIX instead of the MSI? Also, why does wsl --update use the MSI by default?

Unfortunately yes, they take different code paths under the hood. Even if I explained it, it wouldn't make sense to a rational human.

@MatthewL246
Copy link
Author

MatthewL246 commented Mar 29, 2024

Some additional notes:

  1. To get back into the broken state of WSL not being installed (i.e. where I was when I created this issue), I can run msiexec /uninstall wsl.2.1.5.0.x64.msi, which fully uninstalls WSL.
  2. From this state, if I install wsl.2.1.5.0.x64.msi, it fails to install. The installer creates C:\Program Files\WSL and D:\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3d8bbwe\. After clicking the OK button on the error dialog, it deletes C:\Program Files\WSL but the WindowsApps directory sticks around.
  3. Now, if I try to install Microsoft.WSL_2.1.5.0_x64_ARM64.msixbundle, it shows the error "App installation failed with error message: Deployment of package MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3d8bbwe was blocked because the provided package has the same identity as an already-installed package but the contents are different. Increment the version number of the package to be installed, or remove the old package for every user on the system before installing this package. (0x80073cfb)." Presumably, this is because of the failed installation in step 2.
  4. I manually delete D:\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3d8bbwe\ as TrustedInstaller to revert this failed installation.
  5. I try to install Microsoft.WSL_2.1.5.0_x64_ARM64.msixbundle and it installs successfully, creating D:\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3d8bbwe\ (but nothing in Program Files). However, running WSL shows the error "Class not registered. Error code: Wsl/CallMsi/Install/REGDB_E_CLASSNOTREG".
  6. I uninstall the MSIX with Remove-AppxPackage -AllUsers MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3d8bbwe.
  7. I install it again, and it installs successfully. This time, it creates both D:\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3d8bbwe\ and C:\Program Files\WSL.
  8. WSL is now working correctly.
  9. Running wsl.2.1.5.0.x64.msi does nothing.
  10. Running Remove-AppxPackage -AllUsers MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3d8bbwe deletes D:\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3d8bbwe\, but C:\Program Files\WSL still remains. WSL continues working correctly.

All of these possible broken states are really confusing me, but I hope this helps.

@pmartincic
Copy link
Collaborator

pmartincic commented Mar 29, 2024

That lines up with what I've observed, though I'd be reluctant to delete those directories without using the inbox commands such as (add|remove)-appxpackage. I've ended up with sadness a few times when I do that.

Untill we ship a fix I think you'll want to stick to using this as a workaround:

Remove-AppxPackage MicrosoftCorporationII.WindowsSubsystemForLinux_2.2.0.0_x64__8wekyb3d8bbwe -AllUsers
Remove-AppxPackage MicrosoftCorporationII.WindowsSubsystemForLinux_2.2.0.0_x64__8wekyb3d8bbwe
add-appxpackage NAMEHERE

@MatthewL246
Copy link
Author

I'd be reluctant to delete those directories without using the inbox commands such as (add|remove)-appxpackage

I absolutely agree. The problem was that these directories were created in step 2, but the msix was not fully installed so it didn't show up in get-appxpackage.

@Uldiniad
Copy link

Uldiniad commented Apr 4, 2024

I'm getting the same error code 0x80073CFB for updates for WSL via the store (I'm on the latest stable 11 update). I think it started occurring after I manually updated via wsl --update recently. I can't afford to uninstall my environment so would like to know if there are alternative workarounds or fixes

@pmartincic
Copy link
Collaborator

pmartincic commented Apr 10, 2024

This is not an official build, if you still see issues when trying this build, please get back to me with more logs from this post, in addition to our logs. #11319 (comment)
https://1drv.ms/u/s!ApJY8OVsSSJ-gQn_I1D8e4y45kJq?e=yJEOlc

@MatthewL246
Copy link
Author

That build causes a new error.
image

However, it does seem to fix something because, after attempting to install that build, wsl --update successfully installs version 2.5.1.
Here are the WSL logs that record attempting to install your build unsuccessfully and then WSL automatically installing version 2.5.1 successfully: WslLogs-2024-04-10_15-38-45.zip
And here are the AppxLogs: AppxLogs1712778190.zip.001.zip AppxLogs1712778190.zip.002.zip

Copy link

Diagnostic information
Multiple log files found

@pmartincic
Copy link
Collaborator

@MatthewL246, thank-you for the logs and sorry for the slow response. I missed your message. I'm having a look

@konavivekramakrishna
Copy link

I had the same issue, and nothing worked. However, running the following command fixed it:

Remove-AppxPackage -AllUsers MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3d8bbwe

@Sherry520
Copy link

I had the same issue, and nothing worked. However, running the following command fixed it:

Remove-AppxPackage -AllUsers MicrosoftCorporationII.WindowsSubsystemForLinux_2.1.5.0_x64__8wekyb3d8bbwe

It also applies if wsl does not work properly after the "wsl --update "update to 2.2.4
Remove-AppxPackage -AllUsers MicrosoftCorporationII.WindowsSubsystemForLinux_2.2.4.0_x64__8wekyb3d8bbwe

@oliver-kk
Copy link

To whom it may concern:
I ran into the same error but for Corporate reasons, Appx is not available on my machine.

I tried all steps available on Microsoft's WSL troubleshooting site, which did not fix the issue. Finally, downloading the latest MSI from the releases here and thus re-installing WSL did work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants