The I/O operation has been aborted because of either a thread exit or an application request

Environment

Windows build number:  Microsoft Windows NT 10.0.20175.0
Your Distribution version:  Ubuntu (can't run because failed to run the bash)
Whether the issue is on WSL 2 and/or WSL 1: WSL1

Steps to reproduce

Just opening the WSL (Ubuntu) after a windows update (insider build).

lxcore details logs -

lxcore-files.zip

Expected behavior

Should work

Actual behavior

Error:
The I/O operation has been aborted because of either a thread exit or an application request

I'm hitting the same issue, and am on the same Windows build with WSL1.
Even just trying to list distributions hangs and fails like this: wsl --list --all

Yonatan Bitton (@bityob)

Yonatan Bitton (@bityob) - Interesting, I'm able to repro this but this didn't hit in our automated testing. I'll figure out what's going on. In the meantime I'd suggest rolling back to the previous version or using WSL2. Looks like conversion is working ok.

Ok... this issue seems to be related to when the init daemon receives a larger than expected message from our service and has to resize our buffer. You may be able to work around this by temporarily reducing the length of your windows %PATH% variable.

Alright, I've fixed this and written a test so this kind of thing won't happen again.

Sorry about the disruption this caused... I'll try to get the fix into an Insider Fast build ASAP.

nathpete-msft

nathpete-msft - the list issue you mention looks different. Can you file a new issue with more details, please?

Ben Hillis (@benhillis)

Ben Hillis (@benhillis)

You may be able to work around this by temporarily reducing the length of your windows %PATH% variable.

Thanks, this did solve the issue -

set PATH=
C:\Windows\System32\wsl.exe

or

set PATH=C:\Windows\System32
wsl

Yep. I'm definitely affected by this bug. I started shortening my %PATH%, one program path string at a time until I got down to 989 characters, including spaces (so, assuming a limit of 1024 characters or just below). Once I got it pared down to 989 characters, WSL started working again as normally. But my machine where I test preview builds also has Windows Kits, developer environments, multimedia software, diagnostics, and so forth, all of which need to be in the path to work properly. Why was WSL limited to a certain path length? Any way to work around this without shortening the path in a cmd prompt before running WSL? I have use it to run Linux software side-by-side with Windows on the fly. Haven't been able to do this since updating to Windows 10 build 20175.

Temporary workaround I started using today is to launch terminal from PowerShell:

c:\windows\system32\cmd.exe /c "path %SystemRoot%\System32; && %USERPROFILE%\AppData\Local\Microsoft\WindowsApps\wt"

Alternatively, a shortcut can be created with the following:

C:\WINDOWS\system32\cmd.exe /c "path %SystemRoot%\System32; && %USERPROFILE%\AppData\Local\Microsoft\WindowsApps\wt"

Or, you can use:

C:\Windows\System32\cmd.exe /c "path C:\Windows\system32; && %USERPROFILE%\AppData\Local\Microsoft\WindowsApps\wt.exe"

Set the "Run:" property on the Shortcut tab to Minimized and click apply. So, until the above bug is fixed, this is what I have started doing for the time being. Similar can be done with individual Linux apps, but with the wt.exe line replaced with the path to your Linux program.

Note: If you also use PowerShell through Windows Terminal, you'll also have to add the path to your PowerShell installation in addition, like this:

C:\Windows\System32\cmd.exe /c "path C:\Windows\system32;C:\WINDOWS\System32\WindowsPowerShell\v1.0\; && %USERPROFILE%\AppData\Local\Microsoft\WindowsApps\wt.exe"

dcharlespyle

dcharlespyle

I started shortening my %PATH%, one program path string at a time until I got down to 989 characters, including spaces (so, assuming a limit of 1024 characters or just below). Once I got it pared down to 989 characters, WSL started working again as normally

I wrote a simple python script to check the limit in my machine.

In my case the limit was not always the same (805/817/878 characters).

The script needs Python 3.6+ to run.

import os
from subprocess import STDOUT, check_output
import platform

# Get the path to the wsl executable, it's different if python is 32bit or 64bit
# See here - https://stackoverflow.com/a/41631476
system32 = 'SysNative' if platform.architecture()[0] == '32bit' else 'System32'
wsl_command = os.path.join(os.environ['SystemRoot'], system32, 'wsl.exe')

min_num = 800
max_num = 2000
path = ""

try:
    for i in range(min_num, max_num):
        path = "A" * i

        curr_command = f"set PATH={path} && {wsl_command} uptime"

        print(f"Length of path: {len(path)}") 
        
        # Raise exception in case of error
        output = check_output(curr_command, stderr=STDOUT, timeout=60, shell=True)
        
        print(output.decode('utf8').strip())
except Exception as ex:
    print(f"FAILED. Output: {ex.output.decode('utf8')}")

I've shorten my PATH to 770 characters, but still can not start WSL with extractly same error.

If you're running into the issue with too long of a PATH and you're using Windows Terminal, you can set up a profile with the following commandline property to automatically clear your PATH before running WSL. This will leave PATH in tact for other shells.

"commandline": "cmd.exe /C \"set PATH= && \"C:\\WINDOWS\\System32\\wsl.exe\"\"",

If you're using VSCode, you can resolve this by using the following settings:

  "terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\wsl.exe",
  "terminal.integrated.env.windows": {
    "PATH": ""
  },

and the locale in Ubuntu? I have LANG="C.UTF-8"
Yep this is mysterious.

and the locale in Ubuntu? I have LANG="C.UTF-8"
Yep this is mysterious.

Here is what I get:

$ locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=

I have 100% same.. I really think that this workaround might have revealed a new issue. Maybe worth a new ticket.

I agree that this is mysterious. Another fellow who has posted here has had not one workaround work for him on build 20175. That is when my problems began, but I am holding out from rolling back this time around. I almost rolled back when I started noticing the problem with WSL on this build.

All of the workarounds above used to work for me, but now they do not.

I don't know how to make a poll here, but are the effected all WSL1, or is WSL2 the same thing?
Myself I cannot use WSL2 as I need VMWare.

dcharlespyle

dcharlespyle FYI, WSL2 works ok on my 20175. I just not want to use it, it doesn't make sense to me

Unregistering (using wsl command-line) and reinstalling Ubuntu WSL from the app store fixed the problem for me. Caveat: I had forgotten that unregistering a WSL distrib completely deletes the file system so I lost all my files in the process, ouch! It would have been wiser for me to first backup the file system using wsl --export and then reimport it using wsl --import or make a copy of the .vhdx file.

Unregistering (using wsl command-line) and reinstalling Ubuntu WSL from the app store fixed the problem for me. Caveat: I had forgotten that unregistering a WSL distrib completely deletes the file system so I lost all my files in the process, ouch! It would have been wiser for me to first backup the file system using wsl --export and then reimport it using wsl --import or make a copy of the .vhdx file.

I have no .vhdx file that I am aware of. Went searching for it, too, but turned up nothing.

Use the path workaround, WSL2, or roll back to previous insider build. Fix is inbound.

/fixed 20190.

Navigation Menu

Repository navigation

The I/O operation has been aborted because of either a thread exit or an application request #5633

Environment

Steps to reproduce

Expected behavior

Actual behavior

34 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The I/O operation has been aborted because of either a thread exit or an application request #5633

Description

Environment

Steps to reproduce

Expected behavior

Actual behavior

Activity

nathpete-msft commented on Jul 22, 2020

benhillis commented on Jul 22, 2020

benhillis commented on Jul 22, 2020

benhillis commented on Jul 23, 2020

benhillis commented on Jul 23, 2020

bityob commented on Jul 23, 2020

dcharlespyle commented on Jul 24, 2020

dcharlespyle commented on Jul 24, 2020

bityob commented on Jul 25, 2020

iccfish commented on Jul 26, 2020

jonnyasmar commented on Jul 26, 2020

34 remaining items

henris42 commented on Jul 29, 2020

dcharlespyle commented on Jul 29, 2020

henris42 commented on Jul 29, 2020

dcharlespyle commented on Jul 29, 2020

carolinaisslaying commented on Jul 29, 2020

henris42 commented on Jul 29, 2020

iccfish commented on Jul 29, 2020

blumu commented on Jul 29, 2020

dcharlespyle commented on Jul 30, 2020

benhillis commented on Jul 30, 2020

benhillis commented on Aug 12, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions