Winsock module breaks WSL2 #4177
Comments
|
Thanks for providing a trace, I will take a look. |
|
I took a look at the trace and I'm not seeing any relevant events in the service etl. If possible could you do the following? wsl.exe --shutdown |
Steps I take (In a Chinese environment) |
|
same question,proxifier winsock installation,wsl2 can not work. |
|
Same issue of WSL 2 on my Win10 laptop. |
|
Sorry for a useless comment. |
|
The same issue. After running a game speedup VPN (https://uu.163.com), WSL2 cannot running. Build 18922.1000. |
Librazy
changed the title
I encounter this problem and use this method to solve. But my proxifier can't be used. |
|
So the problem is, after using any kinds of vpn (such as shadowsocks or whatever), wsl2 will crash when users try to start it. So I think it needs to be compatible with vpns in the future. |
|
Still reproducible on recent insider versions |
|
|
|
Still relevant. 10.0.18945.1001 |
|
The problem exists on build 18950.1000. |
|
still 18956 |
|
windows10 18956.1000，this problem is still not fixed。 |
|
reproducible in 18963 |
|
18963.1000，this problem is still not fixed。 |
|
I don't think it makes any sense to keep reporting the bug is still not fixed, because there hasn't been any claim from Microsoft that it's fixed. It's pretty obvious that the issue is universal and easily reproducible, and it's very likely that Microsoft is already aware of it. So such comments only spam this issue and and the email inbox of those who have subscribed to this issue. |
|
I took a look at the traces and unfortunately there really isn't much to go on other than WSAEOPNOTSUPP being returned when trying to call into the Service com interface. There are no errors originating from our service itself, so I suspect something outside of WSL components is causing the issue. For people that are hitting this issue, I would suggest looking in the Windows event log or using https://docs.microsoft.com/en-us/sysinternals/downloads/procmon to help track down what is returning the error. Honestly this seems like an error in https://www.proxifier.com/ |
|
As many other winsock modules breaks wsl2, I think it is not Proxifier's fault. It is likely that the communication between wsl2 and other components (likely hyperv?) is broken. I captured events from wsl.exe using procmon when reproducing the issue And there are the windows event logs (system) |
|
@Librazy - Thanks for the additional logs. Unfortunately as I mentioned before, wsl.exe is not where the errors are coming from. I suspect proxifier and other winsock modules are not correctly handling the Hyper-V socket address family (AF_HYPERV). I would strongly suggest reporting the issue to them. |
|
If you're still seeing this error, could you help us diagnose it by collecting networking logs? Instructions on how to do so are here. Thanks! |
|
@craigloewen-msft Thanks for the instructions and here is the log! https://aka.ms/AA5zzk7 |
|
@craigloewen-msft - I am not seeing logs attached to @Librazy's feedback hub issue. Can you investigate? |
|
@benhillis Yup! I'll look into it. |
|
Instead of (I am not sure all of these are needed. I just add all paths I found in task manager) If you don't want to reboot, use |
|
How I managed to solve the problem: |
I have Windows 11 21H2 and added the following to registry and it doesn't work :( Two entries are created: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters\AppId_Catalog\04C4CA21 and Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters\AppId_Catalog\0E1558B0 both with PermittedLspCategories 80000000 |
|
The store version path of For 1.0.3.0: |
|
can confirm that the solution @lingsamuel posted #4177 (comment) |
|
Thank you! This is very important. My previous reg file also didn't work because of the version change |
don't work still |
|
There are some caveats for NoLsp.exe.
So I created this script to run on boot. I have tested and now it works without issue. (Please remember to kill #Requires -RunAsAdministrator
# Fix for https://github.com/microsoft/WSL/issues/4177
$MethodDefinition = @'
[DllImport("ws2_32.dll", CharSet = CharSet.Unicode)]
public static extern int WSCSetApplicationCategory([MarshalAs(UnmanagedType.LPWStr)] string Path, uint PathLength, [MarshalAs(UnmanagedType.LPWStr)] string Extra, uint ExtraLength, uint PermittedLspCategories, out uint pPrevPermLspCat, out int lpErrno);
'@
$Ws2Spi = Add-Type -MemberDefinition $MethodDefinition -Name 'Ws2Spi' -PassThru
$WslLocation = Get-AppxPackage MicrosoftCorporationII.WindowsSubsystemForLinux | Select-Object -expand InstallLocation
$Executables = ("wsl.exe", "wslservice.exe");
foreach ($Exe in $Executables) {
$ExePath = "${WslLocation}\${Exe}";
$ExePathLength = $ExePath.Length;
$PrevCat = $null;
$ErrNo = $null;
if ($Ws2Spi::WSCSetApplicationCategory($ExePath, $ExePathLength, $null, 0, [uint32]"0x80000000", [ref] $PrevCat, [ref] $ErrNo) -eq 0) {
Write-Output "Added $ExePath!";
}
} |
|
@mariotaku Out of curiosity, how do you run this script as an Administrator on boot up? |
Windows Task Scheduler |
When I add it to the task scheduler, I configured it to use the highest privilege. |
如果应用商店安装了
|
原来是自动的，我之前还费劲去手动添加注册表呢。如果termit报错0x8007273d 还需要这样。 |
|
Still reproducable in year 2023. The solution is already provided in comments, not sure why its still not fixed. |
This workaround must be applied every time after the wsl app (app store version) updated, since the versioned path keeps changing. But it's hard to tell when or even whether the app was updated. So ... still quite a mess. |
|
@pnck Alternatively, you could try downloading and installing a different Linux distribution from the Microsoft Store, such as Ubuntu 22.04 LTS. I have tried this myself and it also works. |
|
heroes who are digging to this issue, let me summarize the problem for you:
but if you're curious about how the appid catagory hash is decided (as i do), here's a demo to show how the hash is calculated，so you can write code to do the job for yourself, completely independent to ws2_32.dll, here's some note for the demo:
case close, studied this for a week. |
|
My computer updated to WSL 2.0.9.0 today and this broke again. I had previously set up the Powershell script mentioned in #4177 (comment) but that wasn't fixing it this time. I had to use NoLsp.exe again and run the following commands to get it working again: |
|
@RichardDavies Thank you, worked for me. Here is a adjusted script, that first executes the NoLsp.exe and afterwards the registry fix: #Requires -RunAsAdministrator
# Fix for https://github.com/microsoft/WSL/issues/4177
$MethodDefinition = @'
[DllImport("ws2_32.dll", CharSet = CharSet.Unicode)]
public static extern int WSCSetApplicationCategory([MarshalAs(UnmanagedType.LPWStr)] string Path, uint PathLength, [MarshalAs(UnmanagedType.LPWStr)] string Extra, uint ExtraLength, uint PermittedLspCategories, out uint pPrevPermLspCat, out int lpErrno);
'@
$Ws2Spi = Add-Type -MemberDefinition $MethodDefinition -Name 'Ws2Spi' -PassThru
$WslLocation = Get-AppxPackage MicrosoftCorporationII.WindowsSubsystemForLinux | Select-Object -expand InstallLocation
# Specify paths to all wsl locations
#since WSL Version 2.X.Y.Z also neccessary to execute fix in the "Program Files" locations https://github.com/microsoft/WSL/issues/4177#issuecomment-1817216126
$WslLocations = @(
(Get-AppxPackage MicrosoftCorporationII.WindowsSubsystemForLinux | ForEach-Object { $_.InstallLocation }),
"C:\Program Files\WSL"
)
$Executables = ("wsl.exe", "wslservice.exe", "wslg.exe", "wslhost.exe");
foreach ($WslLocation in $WslLocations) {
Write-Output "Looping trough path: $WslLocation";
Write-Output "==========================================";
foreach ($Exe in $Executables) {
$ExePath = Join-Path $WslLocation $Exe
# Test if exe exists in the path (not all exe's are in all locations)
if (-not (Test-Path $ExePath -PathType Leaf)) {
Write-Output "Path not found: $ExePath!";
continue;
}
# First execute NoLsp.exe fix
& ".\NoLsp.exe" $ExePath
# Second execute registry fix
$ExePathLength = $ExePath.Length;
$PrevCat = $null;
$ErrNo = $null;
if ($Ws2Spi::WSCSetApplicationCategory($ExePath, $ExePathLength, $null, 0, [uint32]"0x80000000", [ref] $PrevCat, [ref] $ErrNo) -eq 0) {
Write-Output "Added $ExePath!";
}
}
Write-Output "";
}I'm running this script as suggested above with highest priviliges via the Task Scheduler on every startup. Tested with WSL 2 v2.0.9.0 and ProxyCap 5.38 |
I spent days struggling with it and now it's working again. Thanks! |
|
@craigloewen-msft @OneBlue The summary of this issue (iirc): Then the changed happened, that wsl gets automatically updated from the windows store. To somehow automate this fixes, i've used successfully @mariotaku script (#4177 (comment)) and adjusted it, so that also the NoLsp.exe fix was executed. Since the last WSL Update (2.0.X.Y) i also had to execute the fix at the wsl.exe, that's in "Program Files" Folder, in addition to the Microsoft Store Location. (The script automaticaly find's the path to the wsl.exe's that are updated by the Microsoft Store). Now everything is working again fine. My complete setup is :
tldr: Thanks in advance for your help ! P.S. the new wsl config options (networkingMode, dnsTunneling etc.) didn't helped for this problem. |
|
Can confirm ProxyCap is now working with WSL 2.1.0 without any fixes. |
|
I'm also using a VPN (Citrix Secure Access). And now with the automatic enablement auf DNS tunneling in 2.1.0, i now don't have internet/intranet access inside the wsl. And internet/intranet access works again. P.S. i need to use the wsl-vpnkit for that. |
and others
For an workaround provided by Proxifier, see #4177 (comment)
Please fill out the below information:
Your Windows build number: 10.0.18917.1000
What you're doing and what's happening:
After updating from 1903 to 18917, I upgraded to WSL2 and it works fine. Later, I enabled https://www.proxifier.com/'s winsock module in its "System Setting 64-bit" app, and WSL2 starting to fail with
The attempted operation is not supported for the type of object referenced..After uninstalling the winsock module, WSL2 launches again. And installing the winsock module won't cause running WSL2 console to fail.
WSL2 should work even if there are other winsock modules installed.
Strace of the failing command, if applicable: N/A
For WSL launch issues, please collect detailed logs.
lxcore.zip
The text was updated successfully, but these errors were encountered: