Multiple components silently fail to detect WSL version

[MarioLiebisch]

Actual Behavior

I was confused about not seeing the update offer to 1.10, then checked the logs and noticed multiple of them fail the version check since I've installed WSL2 version 2.0.0 (currently in pre-release).

Steps to Reproduce

• Update WSL2 to the latest pre-release using wsl --update --pre-release.
• Activate a non-English language pack in Windows.
• Verify the version output of wsl --version doesn't look English WSL Version: ….
• Start or restart Rancher Desktop.
• Observe no visible error message.

Result

• Multiple sub-processes like the update fail, since the program is unable to properly read the WSL version.
• These issues are logged in multiple log files, but not shown in the regular UI.
• Diagnostics reports "No problems detected".

Expected Behavior

Ideally the version detection should just work. I'd at least expect a notice under "Diagnostics" without me digging through log files.

Additional Information

update.log as example:

2023-09-20T10:25:58.026Z: Error: Error: failed to find WSL version from stdout "WSL-Version: 2.0.0.0
Kernelversion: 5.15.123.1-1
WSLg-Version: 1.0.57
MSRDC-Version: 1.2.4485
Direct3D-Version: 1.608.2-61064218
DXCore-Version: 10.0.25880.1000-230602-1350.main
Windows-Version: 10.0.22621.2283
"
    at C:\Program Files\Rancher Desktop\resources\app.asar\dist\app\background.js:43:106731
    at process.processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async so (C:\Program Files\Rancher Desktop\resources\app.asar\dist\app\background.js:43:106467)
    at async oo.checkForUpdates (C:\Program Files\Rancher Desktop\resources\app.asar\dist\app\background.js:43:107928)
    at async oo.getLatestVersion (C:\Program Files\Rancher Desktop\resources\app.asar\dist\app\background.js:43:109424)
    at async lo.getUpdateInfoAndProvider (C:\Program Files\Rancher Desktop\resources\app.asar\node_modules\electron-updater\out\AppUpdater.js:319:19)
    at async lo.doCheckForUpdates (C:\Program Files\Rancher Desktop\resources\app.asar\node_modules\electron-updater\out\AppUpdater.js:333:24)
    at async ko (C:\Program Files\Rancher Desktop\resources\app.asar\dist\app\background.js:43:116257)

Rancher Desktop Version

1.10.0

Rancher Desktop K8s Version

1.25.6

Which container engine are you using?

containerd (nerdctl)

What operating system are you using?

Windows

Operating System / Build Version

Windows 11 22H2 22621.2283

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

None

Windows User Only

N/A

[morsok]

Same issue here with the latest wsl2 pre-release, rancher desktop is stuck in the initializing phase

[mook-as]

Ah, we're doing a bad thing and parsing a string that's meant to be user-visible.

On English Windows:

> wsl --version
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3448

So in our code, we look for a line that starts with WSL (with the space). However, on German Windows:

> wsl --version
WSL-Version: 2.0.0.0
Kernelversion: 5.15.123.1-1
WSLg-Version: 1.0.57
MSRDC-Version: 1.2.4485
Direct3D-Version: 1.608.2-61064218
DXCore-Version: 10.0.25880.1000-230602-1350.main
Windows-Version: 10.0.22621.2283

So we fail to find the version. And there's an additional issue where failing to find the version blows up in our face completely.
(I realize that two different versions of Windows are involved, but the actual issue is the same.)

[jandubois]

Maybe we can check Store versions with

PS C:\Users\SUSE> (Get-AppxPackage | ? Name -eq "MicrosoftCorporationII.WindowsSubsystemforLinux").Version
1.2.5.0

And only if that fails fall back to check the in-box version

PS C:\Users\SUSE> (get-item $env:SystemRoot\system32\wsl.exe).VersionInfo.ProductVersion
10.0.22621.1

[MarioLiebisch]

I think it's safe/reasonable enough to simply parse the version number in the first line of output.

While I don't have any other languages installed right now, I could imagine a French version printing Versión WSL.

Maybe it's best to just match something like \bWSL\b.*?: (\d[\d.]+).

This should avoid matching the wrong line, like the WSLg version number.

[morsok]

Here you go for the french output :

[jandubois]

I think it's safe/reasonable enough to simply parse the version number in the first line of output.

I think it is always preferable to get the information you want from an API instead of scraping output meant for human consumption.

Checking some European languages using the Roman alphabet and left-to-right parsing is one thing, but what about Hebrew, Chinese etc? And Microsoft can change the output of wsl --version with any update.

[mook-as]

Yeah, you can actually get Windows to download language packs in Settings (I think?); I checked Chinese and German, since I'm mostly going by menu item position :)

I'm hoping to get something using GetPackagesByPackageFamily and then GetPackageInfo. Spending a bit more time on it because it'll be useful later for the installer too.

[jandubois]

Yeah, you can actually get Windows to download language packs

This may be sufficient in this case because WSL comes from the store, but in general installing a language pack is not quite the same as having the language specific version of Windows installed, which is fully localized instead of just using different message catalogs for system components.

[MarioLiebisch]

but in general installing a language pack is not quite the same as having the language specific version of Windows installed

That part is – as far as I know – no longer true. There's no difference anymore. There's only one installation medium/master and the UI language is indeed defined by installed language packs only (which also determine what should be loaded alongside store downloads).

I think it is always preferable to get the information you want from an API instead of scraping output meant for human consumption.

Yep, true, but is there an universal API way to get the version? I just checked and the standalone version comes within an MSIX Package, so I guess it would work in either case? Even for self-compiled/installed?