Change:
console.warn(connectionToken.message); process.exit(1); } <del> const disposables = new DisposableStore(); const { socketServer, instantiationService } = await setupServerServices(connectionToken, args, REMOTE_DATA_FOLDER, disposables); // Set the unexpected error handler after the services have been initialized, to avoid having // the telemetry service overwrite our handler let didLogAboutSIGPIPE = false; instantiationService.invokeFunction((accessor) => { const logService = accessor.get(ILogService); </del> <ins> // setting up error handlers, first with console.error, then, once available, using the log service function initUnexpectedErrorHandler(handler: (err: any) => void) { </ins> setUnexpectedErrorHandler(err => { // See https://github.com/microsoft/vscode-remote-release/issues/6481 // In some circumstances, console.error will throw an asynchronous error. This asynchronous error

Discussion:
Type: <bBug</bI am trying to connect to a container running on one of our servers. The server is running AlmaLinux release 8.7 (Stone Smilodon). On the server, we use container virtualization using Virtuozzo release 7.5.4 (465). If I try to connect directly to the container using the remote-ssh package, I have no success. This worked before the update to VSC 1.76.0. I found out, that the vscode-server process crashed. I found this log in the container: The first entry in the stack trace corresponds to this line: The cause of this issue is, that Virtuozzo container do not have a valid mac address. They have a loopback network interface with the mac address 00:00:00:00:00:00 and an interface "venet0", which does not have a mac address. This is normal, because the network traffic is handled by the host and not by the container itself. Because of this, the function in throws the exception 'Unable to retrieve mac address (unexpected format)'. The function gets called by the function in There the exception is catched, but the function throws an exception itself, which does not get catched, I guess. After patching this if statement in the minified javascript code on our server, to always evaluate to true, I was able to successfully connect to and use the vscode-server: . This is of course not the solution to this bug, but just a workaround for us, that we will use, until this bug is fixed. VS Code version: Code 1.76.0 (, 2023-03-01T10:22:44.506Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No Connection to 'SSH: ' could not be established WebSocket close with status code 1006 <details<summarySystem Info</summary Connection to 'SSH: ' could not be established WebSocket close with status code 1006 </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Hello there! Similar issue here. I use macOS and also use 1.76.0 Since yesterday I can't connect remotely to one of my vps.

A half years ago everyday used this remote host, but yesterday evening (here in Hungary), all broke down. I can connect, but after I type password, it's ask another password, and another... It is so confusing, 'cause this tool what I use every day. Plese help me with that.
s
Hi Peter, here is the patched file, we currently use as a workaround. You have to rename it to and replace the file with it. If this does not work for you, maybe the folder has a different name on your server, but I don't think so. On all our servers, the folder had that name. If it does not work, you can try to delete the entire directory, try to connect with VSCode, so it creates the directory on your server. You can now look, what name the subfolder of has, because now you will only have one (each subfolder seems to be another version of the VSCode server). Use this folder instead of . I hope I could help :) Best regards, Kai
It works! Thanks , you saved my life.
This worked for me. Was experiencing the exact same issue on a similar environment.
Got the same issue, solved for me as well! Is there a fix to be expected?
I don't see any other changes than that could have caused that
Thanks for the analysis. Here's what I think happend uses if there's a problem. It throws the error in a timeout. The unexpected error handler is only set after the first invocation of : when the telemetry service is initialised again after all the services are set. The change moved the code that evaluates the machine id a few statements up inside a . That must have surfaced that problem. The fix is to set the unexpected error handler as a first thing. First it uses and collects all errors. then it uses the log service, once available
75 candidate fix:
Thanks for the fix
PR LGTM. I verified that remote SSH works, but I'm not sure how to set up a config that triggers the error handler. Edit: looks like I accidentally verified which is related anyway.
It works! Thank you~ ;-)