Slow WSL startup when network drive unreachable

[capnader]

Version

Microsoft Windows [Version 10.0.22621.963]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.15.79.1

Distro Version

Ubuntu 22.04

Other Software

No response

Repro Steps

1- Define some network drive
2- Shutdown WS to which network drive is linked to.
3- Run WSL distro and it will take about 2mn and more for startup.

Expected Behavior

Actual Behavior

Diagnostic Logs

WslLogs-2022-12-17_22-41-51.zip

[Catofes]

Same issue. Everything works fine after disconnect SMB disks.

[LeosBitto]

I see the same slowness of WSL2 start with some unreachable network drives, see the attached log.
dmesg.txt

[LeosBitto]

This issue is still present in the WSL2 version 1.1.3.
dmesg-1.1.3.txt

[tilenkranjc]

I can confirm, that disconnecting SMB drives solved my extremely slow startup issue. I'm using WSL for more than a year, and this became an issue only recently, so it was introduced in one of the updates.

[oomek]

Can this be finally fixed please? I cannot unmap my drives. WSL should launch immediately even when mapped network drives are inaccessible. This almost 1 minute delay is very annoying.

[oomek]

Ok, this is INSANE!
4 minutes and 17 seconds of delay in WSL session start with 6 inactive mapped drives.
Fixing this should have the highest priority.

[oomek]

Please try the following workaround and let me know if it worked for you.
It actually helped on my machine.

Add ProviderFlags DWORD and set it to 1 inside each mapped drive letter you find in the registry under
Computer\HKEY_CURRENT_USER\Network\ and restart your PC

Mentions:
#9377
#8569
#6765

[capnader]

Please try the following workaround and let me know if it worked for you. It actually helped on my machine.

Add ProviderFlags DWORD and set it to 1 inside each mapped drive letter you find in the registry under Computer\HKEY_CURRENT_USER\Network\ and restart your PC

Mentions: #9377 #8569 #6765

Have tried the workaround but still having the same issue. WSL startup took about 2mn for having only one network drive unreachable.

[bitekas]

Same issue here. I'm glad that I found the problem after a few hours of googling, because I had to wait for 4+ minutes for every WSL instance start. This is insane.

[KonstantinKhabarlak]

Same issue. Likely introduced with an update, WSL startup was much faster before even with unavailable network drives.

[dm9bbadd4]

Also having the same issue, how is this not fixed yet?

[otaolafranc]

Hello, same issue here, without much luck in searching for a solution.

[Barsonax]

Same issue here, so weird this has been a issue for so long. Was searching for ages for the cause of slow wsl startups until I found this.

[ak2]

I triggered this problem by mapping drive letter U: to the WSL Ubuntu drive (i.e. \\wsl.localhost\Ubuntu). Even disabling automounting in the wsl.conf didn't help.

[blami]

I have mostly inaccessible SMB drive on my laptop that only works when connected to company VPN. WSL startup goes from seconds to 5 minutes when this drive is mapped. Unfortunately I can't unmap it as I am not privileged enough to do so.

[Erw1n]

As soon as I removed all unreachable network drives, startup time dramatically increased.

[MahdiGhiasi]

I'm having the same problem on WSL2 v2.0.x as well (I tested up to 2.0.11). It took ~5 minutes for wsl to startup, but it got fixed once I removed my unreachable mapped network drives.

[andreas-thoren]

Also having the same issue. I tried to use these settings in wsl.conf

[automount]
enabled=false

and mount the drives that are always present in /etc/fstab but that doesnt help. Same issue with really slow startup time anyway. Only thing that works is to umount the drives in windows (no drive letter attached) and everything works fine but this shouldn't be needed.

Please fix!

[AlexanderSalge]

Does WSL have a way to inject a script that temporarily disables networking during startup? Unmounting network shares is not an option for me as well

[borjamunozf]

It started to fail for me this week with 3 network locations connected, WSL become almost useless overall:

• ~10 minutes startup time.
• Build times for projects extended dramatically (could take 1 hour to build only 1-2 files)
• I could not even run succesfully df -h because it just hanged forever.

WSL version was 1.2.5

The dmesg log messages were pointing to this issue:

[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2
[Wed Mar  6 09:35:34 2024] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2

I unmounted/disconnected the Windows network locations & updated WSL to latest ver: 2.1.4
Created again the network locations, started WSL & now it works smooth as before.

[AlexanderSalge]

I unmounted/disconnected the Windows network locations & updated WSL to latest ver: 2.1.4 Created again the network locations, started WSL & now it works smooth as before.

So re-adding mainly offline network locations to an updated WSL works also when restarting WSL/host and network locations are still offline?

[LeosBitto]

After upgrading to the WSL version 2.2.4 I do not have this problem anymore.

[grische]

Upgrading from

WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2

to

WSL version: 2.3.24.0
Kernel version: 5.15.153.1-2

fixed the problem for me as well.