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

WSL2 distros fail on start with Error 0xffffffff. (Exit code 4294967295 if launched from Windows Terminal) #4929

Open
trbenning opened this issue Feb 25, 2020 · 115 comments

Comments

@trbenning
Copy link

trbenning commented Feb 25, 2020

  • Your Windows build number: (Type ver at a Windows Command Prompt)
    Microsoft Windows [Version 10.0.19041.84]

  • What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)
    Problem occurrs anytime I try to launch a WSL2 distro.

C:\Users\10057871> wsl -d Ubuntu
Error: 0xffffffff
  • What's wrong / what should be happening instead:
    All WSL2 distros crash on start. WSL1 distros work fine.
    My current set:
C:\Users\10057871> wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu                 Stopped         2
  Alpine                 Stopped         1
  docker-desktop-data    Stopped         2
  docker-desktop         Stopped         2
  • Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).
    N/A

  • For WSL launch issues, please collect detailed logs.
    wsl_logs.zip

  • Additional info:

I recently got a new laptop. Before configuring WSL or Docker, I upgraded to insiders version 2004 (full version above). I then enabled WSL, installed Ubuntu, & set the version to 2. Later I installed Docker for Windows, and configure that to use WSL2 as well.

Everything worked great for a while, until my group policy forced me to enable Bitlocker. After that, I started seeing the errors mentioned above. While searching for a solution, I came across this reply on another issue. After executing those 2 commands and rebooting, I was able to install Ubuntu again & upgrade it to WSL2. I then reinstalled Docker, and configured it for WSL2 again as well. This worked great for almost 2 days, until my laptop Green Screened and rebooted (I have the minidump if you'd like me to send it). After the reboot, my WSL2 instances no longer work, and I'm unable to get them working again. I even executed the fsutil commands again just in case they got reset, but to no avail.

Is this behavior caused by Bitlocker, or is the timing merely coincidental?

@privacyguy123
Copy link

I'm currently experiencing the same issue, minus Docker & Bitlocker. My Debian was working perfectly in WSL 2 up until today - now it hangs which causes Windows Terminal to hang also, I've tried remove/readding features etc to no avail.

@privacyguy123
Copy link

Update: today when I booted into Windows WSL said it had no distro installed despite having Debian installed up until until last night.

@slecorvaisier
Copy link

Same issue here with my WSL2 distro (ubuntu 18.04)

@Biswa96
Copy link

Biswa96 commented Feb 26, 2020

Do you have latest Windows 10 insider build?

@privacyguy123
Copy link

Do you have latest Windows 10 insider build?

Who would put themselves through that? I'm on Slow ring atm.

@trbenning
Copy link
Author

I'm on the slow ring as well. Interestingly enough, today I was able to create a new instance of Alpine, and upgrade it to WSL2 (I couldn't do this yesterday). Nothing about my system has changed that I'm aware of, aside from an additional reboot.

That gave me the confidence to enable WSL2 on my Docker install, which worked as well.

I just got my Ubuntu dev environment setup again, so I'm hesitant to upgrade that one, but I'll update this thread if my Alpine or Docker instances start crashing again.

@privacyguy123
Copy link

I think the most puzzling part of all this is that there are no steps to reproduce in my case - it just happened by itself overnight.

@trbenning
Copy link
Author

My experience was more or less the same. I work primarily out of the WSL Ubuntu instance, and everything was going great until suddenly it wasn't. No idea what caused the green screen, but after rebooting I couldn't get anything to work with WSL2. I rebooted a couple of times, and reinstalled the WSL distros but was unable to upgrade them to v2. Then today, on a whim, I tried again and everything just worked. 🤷‍♂️

@privacyguy123
Copy link

This post fixed it for me!

https://www.surfacetablethelp.com/2018/10/fix-hyper-v-not-working-after-windows-10-v1809-upgraded.html

Still couldn't tell you how those options got set in the first place.

@slecorvaisier
Copy link

The post shared by @privacyguy123 solved my issue too, it just requires an additional reboot.

@pnunn
Copy link

pnunn commented Feb 28, 2020

I'm really bummed out by this.. I needed to use traceroute and couldn't under version 1 so followed the bouncing ball to upgarade to V2 and my ubuntu machine took ages to migrate.

Now nothing works.

I tried the post shared by @privacygui123 as well, but when I try and change the settings for vmcompute I get an error

Unexpected error. Sorry, we ran into a problem. Please try again.

But, try as I might... I can't get anything working.

ver returns Version 10.0.19041.113

wsl -l -v returns
Ubuntu-18.04 Stopped 2

Any ideas please.. I'm stuck without wsl working.

I just managed to install Alpine (which is running as version 1) so atleast I can still do stuff.. BUT... what the??

@Biswa96
Copy link

Biswa96 commented Feb 28, 2020

Try to install Ubuntu in WSL2 from scratch without migrating from v1. wsl.exe --set-default-version 2 will set WSL2 as default. Also make a backup of existing WSL user home folder and installed packages.

@pnunn
Copy link

pnunn commented Feb 28, 2020

Thanks Biswa96, how do I backup the home and installed packages? Sorry, new to wsl.

@pnunn
Copy link

pnunn commented Feb 28, 2020

I tried install openSuse-Leap-15-1 after setting the default version but it won't work either.

wsl --distribution openSuse-Leap-15-1 --user root The attempted operation is not supported for the type of object referenced.

Running it as a normal user, started, set up the new user, then crashed with a screen full of the same messages.

@trbenning
Copy link
Author

It happened again today. None of my WSL2 instances will start due to the same error. This time, I believe it was caused by me messing with Hyper-V. I needed to reserve some ports that Hyper-V was hogging, so I performed the following steps:

  1. Opened Windows Features dialog, and disabled Hyper-V
  2. Restarted
  3. Opened PowerShell, and ran the following:
netsh int ipv4 add excludedportrange tcp 8000 100 persistent
netsh int ipv4 add excludedportrange tcp 8800 100 persistent
  1. Opened Windows Features dialog, and enabled Hyper-V
  2. Restarted
  3. After booting, all of my WSL2 instances crash with the above-mentioned error.

@pnunn
Copy link

pnunn commented Feb 29, 2020

Is there a fix for this or do I blow windows away and install a proper OS? This is crazy.

OK, I've converted my main machine back to v1 so I can atleast do some work.

@privacyguy123
Copy link

Still no official response for this?

Are you guys on Slow or Fast ring, can we confirm the problem exists in both?

@pnunn
Copy link

pnunn commented Feb 29, 2020

I'm on slow.

@trbenning
Copy link
Author

trbenning commented Mar 2, 2020

Is there a fix for this or do I blow windows away and install a proper OS? This is crazy.

OK, I've converted my main machine back to v1 so I can atleast do some work.

@pnunn If this is your attitude, maybe you shouldn't be on the insider builds at all. The point of us using these builds is to find issues like these so they can fix them before the GA release.

Incidentally, I'm able to get WSL2 instances working again, after deleting all of them and rebooting a couple of times. I have no idea if either of those was required though. This time I'll keep a WSL2 instance installed to see if it ever comes back without having to delete & reinstall it.

@craigloewen-msft
Copy link
Member

The error 0xffffffff indicates that the virtual network could not be created. We've identified a possible bug fix for this that is on Windows version 19555 and higher.

For an immediate fix for this error, please consider moving to the fast ring (and understand that this means you'll get updates quicker but could experience more technical issues) otherwise eventually a build will be released to the slow ring that includes this fix!

As well, please let us know if the update does fix your error, we want to make sure that the fix targets this specific use case since the fix was lower in the stack.

For more context check out this Github issue where we are tracking the progress: #4364

Thanks for helping report this!

@pnunn
Copy link

pnunn commented Mar 2, 2020

Thanks @craigloewen-msft atleast we know what it is now... I don't think I can risk the fast ring breaking more than already is. Will we know when this fix is pushed down to the slow ring? Can you let us know here perhaps so we can try wsl2 again?

Ta
Peter.

@craigloewen-msft
Copy link
Member

Yup! I will ping here or on the linked thread when this fix becomes available on the slow ring.

@pnunn
Copy link

pnunn commented Mar 10, 2020

Any news on this one @craigloewen-msft? Still chugging away on WSL1 at this point.

@craigloewen-msft
Copy link
Member

It's not in slow ring yet!

@daviholandas
Copy link

for me was solved like this:
1 - Uninstall docker;
2 - Uninstall / install Hyper-v;
3 - Uninstall / install subsystem;

started working again!

@pnunn
Copy link

pnunn commented Mar 12, 2020

That didn't work for me. I tired installing a new Debian machine and it won't accept the username that it asks for during startup.

The attempted operation is not supported for the type of object referenced.

is the error.

@pnunn
Copy link

pnunn commented Mar 14, 2020

Why are Microsoft putting out blog posts like this
https://devblogs.microsoft.com/commandline/wsl2-will-be-generally-available-in-windows-10-version-2004/
when wsl2 is not working?

@pnunn
Copy link

pnunn commented Mar 17, 2020

Hello.. is any one home?

@LFBernardo
Copy link

The latest version of Docker desktop decimates WSL. The only way to fix it is to remove any WSL apps and remove the entire Windows subsystem for linux. Reboot and re-install everything. I am on the latest version of everything.

@Ragarnoy
Copy link

Ragarnoy commented Nov 12, 2021

It honestly came out of nowhere, one day it worked, the next it didn't, it wasn't any major update that broke it, maybe a minor?
I tried reinstalling the distro, and when I did the only error code I'd get from then on would be WslRegisterDistribution failed with error: 0x8007000d
I tried everything that was mentionned and more, I just reinstalled Hyper-V and WSL and it still wont let me install any new distro

@dcharlespyle
Copy link

Are you using an Insider Preview version of Windows? If so, if it expires WSL will generate this error. It will appear out of the blue. The other potential cause is a damaged file. Check your hard drive for filesystem errors, including bad sectors.

Check the filesystem for corrupted files. Check the system's image store for corruption. Make sure that Windows Hypervisor Platform and Virtual Machine Platform are installed properly in addition to Hyper-V. Also Containers.

image
image

Sometimes an update will cause the above three Optional Features not to be installed properly. The only way to fix them, if they are the cause. is to disable them, reboot, and then enable them all again.

@jordantrizz
Copy link

For what it is worth, I noticed the Acrylic DNS Server situation above and I stopped my Technitium DNS Server and all of a suddden everything started working.

Eeeeesh!

Thanks for the help folks

+1 for Stopping/Removing Technitium DNS Server. Conversion of a WSL 1 Ubuntu instance to WSL2 worked.

@svonjoi
Copy link

svonjoi commented Feb 11, 2022

Solution to my particular case. windows 10 build 19043.1237
wsl ~ -d debian in my case is working. To solve this error I found that by default in windows terminal settings for debian, starting directory was set as ~ and I just changed it to windows format path, for example C:\Users\User\Desktop and this did the trick

@fedemarco
Copy link

My only solution so far was #5092 (comment)

I found that the tool detailed in that comment (sorry, not sure what is actually doing), finds and fixes a lot of errors in my git repositories.

At the same time, the git repositories are broken once I fix the disk.

It is clearly caused by that, but not sure the cause.

@kpnmn99
Copy link

kpnmn99 commented May 26, 2022

I had the same issue previously after using Docker Desktop. I wipe the system and re-imaged after an earlier attempt to repair WSL hung and corrupted the system. Today I had the issue again. I tried the fixed listed above, but none worked. I ended up copying my Kali Linux distro from another drive that was also configured with WSL2. After copying the vhdx file, I restarted the computer, and my WSL Kali is working again with no issues. Not officially a backup, but it worked.

@baerla
Copy link

baerla commented Jun 30, 2022

I had the same issue that Kali couldn't start.

My solution was:
I started Docker Desktop and was then able to login to Kali again

@tangruixun
Copy link

tangruixun commented Aug 12, 2022

Thanks, it is indeed a DNS issue, after stopping the Acrylic DNS service, not only WSL issue solved but also Windows Sandbox 0xffffffff problems disappears... 😅

@Leo137
Copy link

Leo137 commented Aug 12, 2022

Yes, in my case i installed Technitium DNS Manager which operated in port 53. Which is a port apparently WSL needs to set up his network adapter.

Removing the program and restarting the system worked for me.

@ikamran
Copy link

ikamran commented Oct 12, 2022

I had the same issue it took lot of my time, simply check which app is using port 53 and kill it
try the following:
Go to System Tools => Resource Monitor GUI for windows
Check which service is using port 53,
Once you identify it, kill the process as follows: taskkill /f /pid [PID].

Go to Users/[youruser]/AppData/Local/Packages/ and look for a folder called CanonicalGroupLimitedUbuntu... then right click on it, go to Properties => Advanced Options and disable compression for the folder, then click accept and also apply this change for subfolders.

Please try the following:

Go to System Tools => Resource Monitor GUI for windows
Check which service is using port 53,
Once you identify it, kill the process as follows: taskkill /f /pid [PID].
Go to Users/[youruser]/AppData/Local/Packages/ and look for a folder called CanonicalGroupLimitedUbuntu... then right click on it, go to Properties => Advanced Options and disable compression for the folder, then click accept and also apply this change for subfolders.
[Note] Windows uses Compression for the installation folders so is not possible to run it.

Once this is done, try to run your installation and should be working.

Hope it helps. Regards

@kpnmn99
Copy link

kpnmn99 commented Oct 12, 2022 via email

@epenflow
Copy link

I had the same issue it took lot of my time, simply check which app is using port 53 and kill it try the following: Go to System Tools => Resource Monitor GUI for windows Check which service is using port 53, Once you identify it, kill the process as follows: taskkill /f /pid [PID].

Go to Users/[youruser]/AppData/Local/Packages/ and look for a folder called CanonicalGroupLimitedUbuntu... then right click on it, go to Properties => Advanced Options and disable compression for the folder, then click accept and also apply this change for subfolders.

Please try the following:

Go to System Tools => Resource Monitor GUI for windows Check which service is using port 53, Once you identify it, kill the process as follows: taskkill /f /pid [PID]. Go to Users/[youruser]/AppData/Local/Packages/ and look for a folder called CanonicalGroupLimitedUbuntu... then right click on it, go to Properties => Advanced Options and disable compression for the folder, then click accept and also apply this change for subfolders. [Note] Windows uses Compression for the installation folders so is not possible to run it.

Once this is done, try to run your installation and should be working.

Hope it helps. Regards

ive same issue so far i can fix it with this, i think my problem is acrylicservice.exe that running on port 53. if you're using valet php on windows just type in cmd valet stop to kill acrlicservice.exe that running on port 53. WSL2 distros fail because of Acrylic DNS Proxy (microsoft/wsl#4929). Use valet stop, start WSL2 then valet start.

https://packagist.org/packages/cretueusebiu/valet-windows

@dgendill
Copy link

I've been running into this issue when using podman. If my computer doesn't shut down gracefully, the next time I start I get this error.

Downloading VM image: fedora-podman-amd64-v37.0.5.tar.xz: d…
Extracting compressed file
Importing operating system into WSL (this may take a few minutes on a new WSL install)...
A distribution with the supplied name already exists.

Error: the WSL import of guest OS failed: exit status 0xffffffff

Last time it happened, I had to completely uninstall podman, delete the podman-machine-default virtual machine, and reinstall podman. Still looking for a better solution.

@nishantkyal
Copy link

Once you identify it, kill the process as follows: taskkill /f /pid [PID].

this worked for me. thanks

@Uj947nXmRqV2nRaWshKtHzTvckUUpD
Copy link

Uj947nXmRqV2nRaWshKtHzTvckUUpD commented May 7, 2023

Stopped Acrylic DNS service, and the WSL worked again

Is there a way to still use Acrylic DNS as the DNS server for windows host while allowing wsl distro installation?

I saw AcrylicDNS has a config: LocalIPv4BindingPort=53 which can be changed to listen on a different port, thus freeing port 53 needed for wsl. Problem is that, afaik, Windows cannot use a DNS server running on 127.0.0.1 on a non-standard port (other than 53). I couldn't find a way to force Windows use a non standard DNS server. Does anyone know a way to do that?

@Kandeel4411
Copy link

Going to post my solution in case anyone had the same problem (This should also work as a guide for corrupted/broken filesystem); basically I installed a new GLIBC version in the WSL distro that resulted in it being non-compatible with WSL and could no longer boot into the distro as it resulted in Catastrophic Failure error and well, libc was broken :D!

Steps:

  1. First of all, create another WSL distribution (Add another new ubuntu for example) that will be used to help us mount the files to recover/debug

  2. Navigate to faulty distro C:\Users\[user]\AppData\Local\Packages\[distro]\LocalState\[distroPackageName] and copy the vhdx file there (it contains the broken filesystem) somewhere else like C:\ext4.vhdx

  3. This step is optional but this will help you know if WSL is running and that if you need to shut it down or view errors

    • Go to C:\Users\[user]
    • Edit or create a file if not present called .wslconfig and add the following to the [wsl2] section:
    [wsl2]
    debugConsole=true
    
  4. Mount the copied vhdx to windows

    • Open an admin powershell/cmd instance
    • Run diskpart then run the following
    select vdisk file="C:\ext4.vhdx"
    attach vdisk
    exit
    

    image

    Cool now we can run some recovery tools or mount the system in order to perform edits/fixes. In case of filesystem corruption, there is a magical tool called TestDisk which we will be using to check if there are any errors.

    • Download TestDisk then run it, you should see something like the following:

    image

    \\.\PhsyicalDrive2 here was my attached vdisk, in your case it might be different

    • Press Proceed then None and you should see something like the following:

    image
    You can press List and navigate to the files there in case you want to copy or check if its readable but in my case it was damaged (Even if it wasn't I suggest following the steps needed to perform repair by clicking Superblock)

    image

    As you can see, we need to run the fsck.ext4 -p -b superblock -B blocksize device command per superblock and to be able to run it, we need to mount it in a linux system (Thats where the 2nd new ubuntu distro comes in)

  5. Mount the vdisk into WSL by running wsl --mount \\.\PhysicalDrive2 --bare in an admin ps/cmd (Might need to change vdisk name depending on your case)

  6. Open your new linux distro and download TestDisk on it so that we can differentiate which was our mounted vdisk. Run the downloaded TestDisk by running in the testdisk directory sudo ./testdisk_static, you should see something like:

    image

    • Now we can try to repair the filesystem, using the suggested fsck command per superblock, run the command and it should look something like:
    fsck -p -b 0, -B 4096 /dev/sdd
    fsck -p -b 32768, -B 4096 /dev/sdd
    fsck -p -b 98304, -B 4096 /dev/sdd
    fsck -p -b 163840, -B 4096 /dev/sdd
    fsck -p -b 229376, -B 4096 /dev/sdd
    fsck -p -b 294912, -B 4096 /dev/sdd
    fsck -p -b 819200, -B 4096 /dev/sdd
    fsck -p -b 884736, -B 4096 /dev/sdd
    fsck -p -b 1605632, -B 4096 /dev/sdd
    fsck -p -b 2654208, -B 4096 /dev/sdd

    You should run TestDisk again to try to list files and see if its able to, if it works then great! now we will actually mount the vdisk into WSL

  7. This step is optional, its for the case if you want to remove the offending files (In which case it was the custom installed glibc for me ). Unmount the mounted vdisk by running wsl --unmount and mount it again but this time without the --bare flag like wsl --mount \\.\PhysicalDrive2

    • Open the new linux distro and cd to /mnt/wsl and you should see something like PhsyicalDrive2 there, this is the mounted vdisk
    • In my case I had to go to /mnt/wsl/PhsyicalDrive2/usr/local/lib +bin + sbin and remove all the offending libc files there so that my system will use the default libc. Your cases may vary so do as you wish as you already have access to the files
  8. Final step, now we shall replace our old faulty ext4.vhdx with our newly modified one

    • Navigate to faulty distro C:\Users\[user]\AppData\Local\Packages\[distro]\LocalState\[distroPackageName] and copy the vhdx file there (it contains the broken filesystem) somewhere else for backup (IGNORE AT YOUR OWN RISK)
    • Copy the ext4.vhdx that we fixed previously (e.g somewhere like C:\ext4.vhdx) and replace the one in the navigated distro with it
      • If an access or in use error pops up, you need to first stop the faulty wsl instance if it was running by running wsl --shutdown and try again (If WSL continues to pop open then thats because of the annoying windows explorer triggering it, in that case, close the explorer and copy and replace using purely cmd/ps console)

    Run the faulty distro again and it should work as expected

  9. Clean up

    • Remove debugConsole=true from .wslconfig if you ran this step
    • Detach vdisk from diskpart
      • Open an admin powershell/cmd instance
      • Run diskpart then run the following
      select vdisk file="C:\ext4.vhdx"
      detach vdisk
      exit
      

I hope this was able to help someone or helped be a reference on how to debug / recover from such an issue! Best regards

@Uj947nXmRqV2nRaWshKtHzTvckUUpD

Stopped Acrylic DNS service, and the WSL worked again

Is there a way to still use Acrylic DNS as the DNS server for windows host while allowing wsl distro installation?

I saw AcrylicDNS has a config: LocalIPv4BindingPort=53 which can be changed to listen on a different port, thus freeing port 53 needed for wsl. Problem is that, afaik, Windows cannot use a DNS server running on 127.0.0.1 on a non-standard port (other than 53). I couldn't find a way to force Windows use a non standard DNS server. Does anyone know a way to do that?

for those interested, i was able to use acrylicDNS on host and also have wsl working, by setting:
LocalIPv4BindingAddress=127.0.0.1 # instead of 0.0.0.0
LocalIPv4BindingPort=53
on wsl, leave dns on auto, don't set it manually
=> this way the dns requests are resolved on the go without the host listening permanently keeping the port 53 blocked at all times.

@kpnmn99
Copy link

kpnmn99 commented May 29, 2023 via email

@ByZain
Copy link

ByZain commented Nov 16, 2023

my solution is run the following command with administrator:
netsh winsock reset

@kpnmn99
Copy link

kpnmn99 commented Nov 16, 2023 via email

@bolens
Copy link

bolens commented Apr 9, 2024

The fix for me with this same issue was this:

  1. I checked my wsl machines by running wsl -l -v and noticed that the docker-desktop machine was stuck uninstalling
  NAME                    STATE           VERSION
* Ubuntu                  Stopped         2
  docker-desktop          Uninstalling    2
  rancher-desktop         Stopped         2
  docker-desktop-data     Stopped         2
  kali-linux              Stopped         2
  podman-machine          Stopped         2
  rancher-desktop-data    Stopped         2
  Debian                  Stopped         2
  1. I then ran the following to remove the stuck machine state wsl --unregister docker-desktop
Unregistering.
The operation completed successfully.
  1. Ran Docker Desktop again which will recreate the machine

@kpnmn99
Copy link

kpnmn99 commented Apr 9, 2024 via email

@redhatted
Copy link

I then ran the following to remove the stuck machine state wsl --unregister docker-desktop

This worked for me after a day of trying different things! Thank you so much @bolens

@wasifferoze
Copy link

The fix for me with this same issue was this:

  1. I checked my wsl machines by running wsl -l -v and noticed that the docker-desktop machine was stuck uninstalling
  NAME                    STATE           VERSION
* Ubuntu                  Stopped         2
  docker-desktop          Uninstalling    2
  rancher-desktop         Stopped         2
  docker-desktop-data     Stopped         2
  kali-linux              Stopped         2
  podman-machine          Stopped         2
  rancher-desktop-data    Stopped         2
  Debian                  Stopped         2
  1. I then ran the following to remove the stuck machine state wsl --unregister docker-desktop
Unregistering.
The operation completed successfully.
  1. Ran Docker Desktop again which will recreate the machine

This works.

@OfficiallyCrazy
Copy link

for me was solved like this: 1 - Uninstall docker; 2 - Uninstall / install Hyper-v; 3 - Uninstall / install subsystem;

started working again!

To me this works until i restart my pc 2-3 times. then it stops working again. everytime i lose my dockers

@vurso
Copy link

vurso commented Jul 4, 2024

The fix for me with this same issue was this:

  1. I checked my wsl machines by running wsl -l -v and noticed that the docker-desktop machine was stuck uninstalling
  NAME                    STATE           VERSION
* Ubuntu                  Stopped         2
  docker-desktop          Uninstalling    2
  rancher-desktop         Stopped         2
  docker-desktop-data     Stopped         2
  kali-linux              Stopped         2
  podman-machine          Stopped         2
  rancher-desktop-data    Stopped         2
  Debian                  Stopped         2
  1. I then ran the following to remove the stuck machine state wsl --unregister docker-desktop
Unregistering.
The operation completed successfully.
  1. Ran Docker Desktop again which will recreate the machine

This works.

This worked for me on the latest Docker Desktop in Windows 11 I had to also unregister the docker-desktop-data image then restarted Docker Desktop which recreated those VM's and then made sure Docker Desktop is using Ubuntu as the backing distro.

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

No branches or pull requests