github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #1191] Client reports "Server Dead" suddenly, Mouse & KB on Server lock up and no longer respond to input other than Ctrl+Alt+Del #961

New issue

Open

opened 2026-05-05 07:20:12 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 07:20:12 -06:00

Owner

Originally created by @liamgconnolly on GitHub (Jun 8, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1191

Describe the bug
Laptop (client, Win 10) connected to Desktop (server, Win 10) and program works as expected until sudden disconnection during cursor move from client to server (client reports "Server Dead" and then attempts to reconnect unsuccessfully until it is stopped manually). Upon this sudden disconnect, mouse/KB of client behave normally, however mouse/KB on server appear "locked up". No cursor is visible. Connecting additional mouse/KB, disconnecting and reconnecting USB of mouse/KB, and remoting in with Chrome Remote Desktop do nothing to remedy this "hard lock". The only input that produces a response on the server is Ctrl+Alt+Del. In that menu mouse/KB function normally. One can select any option or request a Shut Down/Restart. However upon exit (e.g. clicking "Task Manager" to try and kill barrier server process), mouse/KB revert to their "locked up" state.

The only solution I have found is to completely restart or power cycle the server (desktop).

To Reproduce

I believe this might be a Win 10 deep sleep/hibernation/fast start related bug. Typically I'm lazy and do not shutdown the barrier server or client when I choose "Hibernate" in my Win power menu to "shut down" my computers before I go to bed (typ. client laptop followed by server desktop some time later). When waking them up in the morning, generally server first, barrier will often (but not always) resume as if nothing had changed. It is some time after restarting (typically a number of hours after) that this bug will suddenly occur.

Expected behavior
Server crash/hang/disconnect error would trigger some routine to release barrier's control over mouse/KB after some timeout period (maybe 30 sec?).

Screenshots
What the client barrier sees:

Desktop (please complete the following information):
Server:

OS: Widows 10 Education Ver. 20H2 Build 19042.985
Barrier version 2.3.3-release-3395cca9
(if it matters disp format)

where 1: 3440x1440
2&4: 2560x1440
3: 1920x1080

Client:

OS: Widows 10 Pro for Workstations Ver. 20H2 Build 19042.985
Barrier version 2.3.3-release-3395cca9
(if it matters disp format, 3840x2160)

Additional context

While the To Reproduce section appears a bit convoluted, this has now occurred 4-5 times necessitating a complete restart of the Desktop/Server, so I do believe it is a persistent bug. I have set my desktop/server barrier to log to a file now, so I should have some server-side insight to what happens in the future.

Originally created by @liamgconnolly on GitHub (Jun 8, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1191 **Describe the bug** Laptop (client, Win 10) connected to Desktop (server, Win 10) and program works as expected until sudden disconnection during cursor move from client to server (client reports "Server Dead" and then attempts to reconnect unsuccessfully until it is stopped manually). Upon this sudden disconnect, mouse/KB of client behave normally, however mouse/KB on server appear "locked up". No cursor is visible. Connecting additional mouse/KB, disconnecting and reconnecting USB of mouse/KB, and remoting in with Chrome Remote Desktop do nothing to remedy this "hard lock". The only input that produces a response on the server is Ctrl+Alt+Del. In that menu mouse/KB function normally. One can select any option or request a Shut Down/Restart. However upon exit (e.g. clicking "Task Manager" to try and kill barrier server process), mouse/KB revert to their "locked up" state. The only solution I have found is to completely restart or power cycle the server (desktop). **To Reproduce** I believe this might be a Win 10 deep sleep/hibernation/fast start related bug. Typically I'm lazy and do not shutdown the barrier server or client when I choose "Hibernate" in my Win power menu to "shut down" my computers before I go to bed (typ. client laptop followed by server desktop some time later). When waking them up in the morning, generally server first, barrier will often (but not always) resume as if nothing had changed. It is some time after restarting (typically a number of hours after) that this bug will suddenly occur. **Expected behavior** Server crash/hang/disconnect error would trigger some routine to release barrier's control over mouse/KB after some timeout period (maybe 30 sec?). **Screenshots** What the client barrier sees: ![image](https://user-images.githubusercontent.com/68346297/121266583-5e655380-c880-11eb-8c24-e0b411ba2dde.png) **Desktop (please complete the following information):** Server: - OS: Widows 10 Education Ver. 20H2 Build 19042.985 - Barrier version 2.3.3-release-3395cca9 - (if it matters disp format) ![image](https://user-images.githubusercontent.com/68346297/121268014-b69d5500-c882-11eb-9e45-3b5114e0c8df.png) where 1: 3440x1440 2&4: 2560x1440 3: 1920x1080 Client: - OS: Widows 10 Pro for Workstations Ver. 20H2 Build 19042.985 - Barrier version 2.3.3-release-3395cca9 - (if it matters disp format, 3840x2160) **Additional context** While the *To Reproduce* section appears a bit convoluted, this has now occurred 4-5 times necessitating a complete restart of the Desktop/Server, so I do believe it is a persistent bug. I have set my desktop/server barrier to log to a file now, so I should have some server-side insight to what happens in the future.

gitea-mirror commented

2026-05-05 07:20:13 -06:00

Author

Owner

@liamgconnolly commented on GitHub (Jun 9, 2021):

Got a screen grab of the server-side in the rare case that it did eventually kill/restart the process its self:

@liamgconnolly commented on GitHub (Jun 9, 2021): Got a screen grab of the server-side in the rare case that it did eventually kill/restart the process its self: ![image](https://user-images.githubusercontent.com/68346297/121434693-4f93a500-c943-11eb-94b3-58ca512d1273.png)

gitea-mirror commented

2026-05-05 07:20:15 -06:00

Author

Owner

@denego commented on GitHub (Sep 12, 2021):

Looks quite similar to this one.
https://github.com/debauchee/barrier/issues/1248
Try disabling clipboard sharing, until fixed.

@denego commented on GitHub (Sep 12, 2021): Looks quite similar to this one. https://github.com/debauchee/barrier/issues/1248 Try disabling clipboard sharing, until fixed.

No labels

Rows
Columns