Cannot reconnect. Please reload the window

[abdullahiphys]

Issue Type: Bug

When I hibernate my laptop while there is an open vs code window which is connected to WSL and then later when the laptop is turned on and I try to maximum my vs code window, then I got the error "Cannot reconnect. Please reload the window"

Extension version: 0.44.2
VS Code version: Code 1.45.1 (5763d909d5f12fe19f215cbfdd29a91c0fa9208a, 2020-05-14T08:27:35.169Z)
OS version: Windows_NT x64 10.0.19041
Remote OS version: Linux x64 4.19.104-microsoft-standard

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12 x 2208)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: enabled rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off_ok webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.72GB (0.54GB free)
Process Argv
Screen Reader	no
VM	0%

Item	Value
Remote	WSL: Ubuntu
OS	Linux x64 4.19.104-microsoft-standard
CPUs	Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12 x 2208)
Memory (System)	12.27GB (9.93GB free)
VM	0%

[tiptronic85]

And not only when you hibernate...
I get this issue when i start my laptop that was switched off and i open vscode

[ghost]

A temporary workaround I do is restarting WSL by running Get-Service LxssManager | Restart-Service in an Administrator PowerShell.

[drkvogel]

Is this perhaps related to microsoft/WSL#5324 ?

[kevin-he-01]

This is very annoying. I have to reopen the window and possibly lose everything in my terminal every day.
I am using WSL 1 so this is not just a WSL 2 issue. It could be an issue with the extension rather than WSL itself.

My output of uname -s -r -v -m -p -i -o on WSL 1:

Linux 4.4.0-18362-Microsoft #1049-Microsoft Thu Aug 14 12:01:00 PST 2020 x86_64 x86_64 x86_64 GNU/Linux

Update: I frequently lose the content of my integrated terminal sessions. This confirmed that data loss is possible and the need to increase priority for this bug. I'm very sad that this isn't even labeled a bug which means that either it can't reproduce or be confirmed on other machines.

[aia]

Same issue. WSL 1:

$ uname -s -r -v -m -p -i -o
Linux 4.4.0-18362-Microsoft #1049-Microsoft Thu Aug 14 12:01:00 PST 2020 x86_64 x86_64 x86_64 GNU/Linux

[WustlRob]

Same issue here on WSL 1.

11:00 $ uname -s -r -v -m -p -i -o
Linux 4.4.0-18362-Microsoft #1049-Microsoft Thu Aug 14 12:01:00 PST 2020 x86_64 x86_64 x86_64 GNU/Linux

[paulalex]

This has recently started happening to me and it seems when it starts it just goes round in the "Cannot reconnect" cycle, for that reason I am switching to using a mac for development.

[elasticdotventures]

My issue was that the underlying path to the project had moved and it couldn't reopen in that directory.

[kevin-he-01]

The VSCode team should be merging several possible duplicates (#4686 and possibly #3454) into one to ease tracking. Everyone reported this issue in a different way due to their habit of using the computer (whether one enables hibernate/hybrid sleep and how long they keep the computer sleeping). So for those reporting that it only occurs with hybrid sleep or modern standby try performing the same steps except with regular sleep (for at least 10 hours if you have the time, if you need to do work on one computer try letting another computer/Virtual Machine sleep for 10 hours).

For me, the issue (Cannot reconnect. Please reload the window) only occurs when I sleep the computer overnight. Not sure if it is due to the day incrementation, the length of the sleep (I suspect this is more likely based on the logs), or my network adaptor going to a deeper sleep state with longer sleeps. Here's my logs for both my WSL 1 and WSL 2 machine after the "Cannot reconnect" error occurs. I obtained the logs by pressing Cancel in the dialog and go to the Output tab in the bottom pane and select "Log (Window)" in the dropdown:

wsl1.log
wsl2.log

It seems that there is some timeout in the log (and that timeout includes the sleeping time) so that explains why putting the computer to sleep long enough causes the issue:

[2021-03-25 08:01:41.304] [renderer5] [error] [remote-connection][ExtensionHost][42985…][reconnect] An error occurred while reconnecting, but it will be treated as a permanent error because the reconnection grace time has expired! Will give up now! Error:
[2021-03-25 08:01:41.305] [renderer5] [error] Error: WebSocket close with status code 1006
    at WebSocket.<anonymous> (file:///C:/Users/REDACTED/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:631:112912)

Note that issue does not occur every time I put my computer to sleep. If the sleep period is brief and during the day, I may still get the dialog but I press "Reconnect Now" and the remote windows will reconnect. Compared to this issue that is considerably less annoying. The logs of such "expected behavior" is also attached below:

wsl2-successful.log

System Information:

• Network Adaptor - Intel (R) Dual Band Wireless-AC 8265
  • Driver version: 20.70.19.1
• Windows build (Version 1909): 18363.1440

[drkvogel]

I've been experiencing this for... well, ever since I started using VS Code with WSL!

When I see vmmem.exe is using a lot of CPU in the Windows Task Manager (actually Process Hacker 2 which I find more useful for tracking down and exterminating rogue processes), I run htop in WSL and see many processes and their threads (shown in green in htop) of process node /home/user/.vscode-server/bin/2b9aebd5354a3629c3aba0a5f5df49f43d6689f8/out/bootstrap-fork --type=watcherService.

2b9aebd5354a3629c3aba0a5f5df49f43d6689f8 is I believe the commit SHA of the current VS Code version.

One of the processes (there seems to be one for each VS Code window open (I usually have several) is using roughly %150 CPU, i.e. 1.5 times the CPU of one of the four CPUs in my machine (an HP Elitebook 840 G3).

I use htop to kill each process (k, enter), and as each one is killed, the next starts using 150% CPU, and I carry on until there are no more processes using excessive CPU, and the ones that are left (which maybe aren't needed either) are using a reasonable amount (< 2%) of CPU.

This happens always and I think only after a long (e.g. overnight) period of hibernation. My laptop does not support Modern Standby.

Having killed these seemingly rogue processes (and thus their threads, of which there are about 10 per process), VS Code seems to function entirely as normal - so I wonder what these processes are doing?

uname -a: Linux machine-name 4.19.104-microsoft-standard #1 SMP Wed Feb 19 06:37:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[eternaldensity]

This problem started happening to me maybe a month or two ago with WSL 1 and now it's still happening with WSL 2. It definitely happens when hibernating overnight, but when I tried hibernating and booting immediately it did not happen.

After reloading the window it seems to get a new WSL instance while still leaving the old one running but unreachable. This is because I'm running a few Python servers (on localhost for development and testing) and they're still operational and accessible from my web browser, but I cannot see any of the python processes via ps. I had to wsl --shutdown to get rid of all the old processes so I could spin up new ones without port conflicts.

uname -s -r -v -m -p -i -o:
Linux 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[drkvogel]

Following instructions from https://stackoverflow.com/a/48214059/535071, I profiled a rogue bootstrap-fork --type=watcherService and recorded a CPU profile: CPU-20210331T105942.zip

The top 8 rows by CPU time:

Self Time   Total Time  File
9,064.72ms  9,064.72ms  _addPathCloser /home/kvogel/.vscode-server/bin/2b9aebd5354a3629c3aba0a5f5df49f43d6689f8/node_modules/chokidar/index.js:922
591.25ms    591.25ms    (garbage collector)
92.40ms     92.40ms     (program)
73.56ms     73.56ms     lstat
27.94ms     35.31ms     resolve path.js:972
19.97ms     69.24ms     LOOP fs.js:1723
19.86ms     19.86ms     FSReqCallback
17.34ms     17.34ms     stat

chokidar - npm
paulmillr/chokidar: Minimal and efficient cross-platform file watching library

[drkvogel]

excessive CPU

The excessive CPU was caused by a symlink loop in one of my repos, and the file watcher (https://github.com/paulmillr/chokidar) not handling that situation, I removed the offending symlinks and that problem has gone away - however, I am still getting "Cannot Reconnect" - so that was a separate, but linked, issue.

As noted by @kevin-he-01, the length of time in hibernation seems to be a factor, an hour or so of hibernation causes the "Reconnect Now" dialog and it successfully reconnects, often without user intervention, but overnight hibernation causes "Cannot Reconnect".

It's worth adding that I tend to have multiple VS Code windows open - currently 5.

I recently upgraded WSL on the Windows Insider channel, so am now running Linux kernel 5.x:

❯ uname -a
Linux 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

which fixes microsoft/WSL#5324, but this problem is still occurring.

Is there any investigation into this problem ongoing?

[taikulawo]

Everytime I waked from sleep, I have to reconnect vscode wsl2 all the time, which causes losing everything I already have ;(

[tebeco]

I'm not expert, please don't double check what I said in case of doubt I'm might just be wrong, nothing else

Issue

There's a error with no detail given to the user.
the current UX of that error should probably be improuved

Reason

probably TLS handshake (or something related to that because i'm no expert) failing during connect
In order to properly do that handshake, clock of both side need to have a very small gap in time.
It's done on purpose to avoid attacker toying around with clock system to workaround other security check

Workaround

• open WSL2 in a terminal
• sudo hwclock --hctosys
• go to VsCode > click reload / reconnect

Why

Because WSL and hibernate (or other factor) don't play well and sort of "sleep the clock too"
man hwclock:
https://linux.die.net/man/8/hwclock

hwclock sets the kernel timezone to the value indicated by TZ and/or /usr/share/zoneinfo when you set the System Time using the --hctosys option.
It is good to do a hwclock --adjust just before the hwclock --hctosys at system startup time, and maybe periodically while the system is running via cron.

[lucasbasquerotto]

For me the worst thing about this issue is losing all opened files and the state of vscode when reopening.

A better fix IMO is to never lose the information about the opened files and terminals (although the process running in them could be lost; actually they were already lost, probably), unless the user explicitly choose to discard the previous state (so as to take care of cases in which vscode cannot reopen due to some problem in the state of opened files, like a huge file causing error to load and closing vscode, but at the same time not losing the state otherwise).

This would be a more universal approach independent of WSL1, WSL2, SSH or something of the sort, that would probably require a fix for each individual case, like you can see at #4686 and #3454. Also, there could be cases in which the connection was really lost, but if you reopen the window, it should be opened as it was before.

This might not fix the need to reload the window, tough, but at least for me the main issue would already be fixed.

Edit: It seems this is already being tracked at microsoft/vscode#110062

[kevin-he-01]

Just bought a new laptop (Surface Laptop 4) with modern standby. Can no longer reproduce this exact bug anymore (on either WSL 1 or WSL 2, though on WSL 2 another similar issue is bugging me, though that one at least has a workaround)

In contrast, my old laptop uses the outdated S3/S4 power model (no modern standby). My best guess is that those old laptops are not longer supported or tested by this extension anymore, so Microsoft don't have a lot of incentives in investigating an issue that only reproduces on those devices.

At least now I know this issue could possibly be caused by something specific to S3/S4 devices. I even verified this with logs in the OUTPUT tab by selecting "Log (Window)" as the dropdown. When using WSL 1, I see no disconnection at all on a device with Modern Standby, but an a traditional S3/S4 device (tested on my old laptopt) I will certainly see tons of reconnection attempts on every wake-up (even when the bug does not occur):

[renderer3] [info] [remote-connection][ExtensionHost][xxxxx…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ).
[renderer3] [error] {"isTrusted":true}
[renderer3] [info] [remote-connection][ExtensionHost][xxxxx…][reconnect] starting reconnecting loop. You can get more information with the trace log level.
[renderer3] [info] [remote-connection][ExtensionHost][xxxxx…][reconnect] resolving connection...

Feel free to correct me if I am wrong. If you have a S3/S4 only device and is not able to reproduce this issue (that is, leaving it sleep overnight or at least 8 hours or so and not getting the error), please comment here. I believe some laptops even allow you to switch between traditional and modern standby in BIOS/UEFI settings which may help reproducing the issue.

To check whether you have Modern Standby enter this command into Powershell/cmd

powercfg /a

If you see

The following sleep states are available on this system:
    Standby (S0 Low Power Idle) Network Connected
...

then you have modern standby currently on.

[nwilleyltk]

@kevin-he-01 - My computer is only a few months old and has modern standby. I am still having the Cannot Reconnect issue after leaving my computer overnight. I also see the issue 'Reconnecting' message if away from my desk, but in that case it successfully reconnects and nothing is lost. I often have large datasets loaded in memory and this 'Cannot Reconnect' issue is a big problem. I've changed my 'power plan' settings to disable putting the computer to sleep when plugged in to see if that will help.

[ayon06]

@kevin-he-01 I have checked my Surface Pro X. It has modern Standby, but still runs into this issue every single time the computer sleeps for a long enough time

It will continue to try to reconnect for a good 5-10 minutes before the issue is finally resolved (sometimes)

[sjpb]

In case it helps diagnose it (@kevin-he-01 thanks for your post) I'm on a Win10 laptop with WSL1. In trying to fix this issue I disabled "sleeping" entirely thro the Windows power & sleep settings GUI. powercfg now shows:

The following sleep states are available on this system:
    Standby (S0 Low Power Idle) Network Disconnected
    Hibernate

but I still hit this issue sometimes :-(.

[aeschli]

duplicate of #3158