github-starred/barrier

Fork 0

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

[GH-ISSUE #442] Windows 7 client don't reconnect after suspend to ram #343

New issue

Open

opened 2026-05-05 06:04:47 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 06:04:47 -06:00

Owner

Originally created by @spiderbit on GitHub (Sep 24, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/442

After resume I can't switch to the windows client with my mouse till I restart the service either via the gui or windows services dialog.

I even created a restart barrier Tast, that if I run it manually makes it work but scheduled as Power-troubleshooter Event Id 1 does not do the trick.

I assume that the service must be restarted later maybe the network is not up directly after the wakeup.

Best workaround at the moment use shutdown instead of suspend.

Originally created by @spiderbit on GitHub (Sep 24, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/442 After resume I can't switch to the windows client with my mouse till I restart the service either via the gui or windows services dialog. I even created a restart barrier Tast, that if I run it manually makes it work but scheduled as Power-troubleshooter Event Id 1 does not do the trick. I assume that the service must be restarted later maybe the network is not up directly after the wakeup. Best workaround at the moment use shutdown instead of suspend.

gitea-mirror added the

windows

label 2026-05-05 06:04:47 -06:00

gitea-mirror commented

2026-05-05 06:04:51 -06:00

Author

Owner

@fritzw commented on GitHub (Mar 30, 2020):

Which PC do you suspend? For me, suspending the client PC (Windows 10) works fine and it automatically reconnects. However, if I suspend the server PC (also Windows 10), the client can't reconnect to the server until I restart the barrier server (click either Reload, or Stop and Start in the GUI). After that, the client reconnects automatically after a few seconds.

UPDATE: Okay, today the automatic reconnect worked without restarting barrier. So there seems to be some non-deterministic property to the problem.

@fritzw commented on GitHub (Mar 30, 2020): Which PC do you suspend? For me, suspending the client PC (Windows 10) works fine and it automatically reconnects. However, if I suspend the server PC (also Windows 10), the client can't reconnect to the server until I restart the barrier server (click either Reload, or Stop and Start in the GUI). After that, the client reconnects automatically after a few seconds. UPDATE: Okay, today the automatic reconnect worked without restarting barrier. So there seems to be some non-deterministic property to the problem.

gitea-mirror commented

2026-05-05 06:04:54 -06:00

Author

Owner

@fritzw commented on GitHub (Apr 9, 2020):

The issue seems to be more complex than that. Sometimes it is sufficient to restart the barrier server process, and the client reconnects after a few seconds. Sometimes however, restarting the server does nothing, so I have to connect a keyboard or mouse to the client PC in order to restart the barrier client.

The Server is connected via LAN, the client is connected via WiFi.

@fritzw commented on GitHub (Apr 9, 2020): The issue seems to be more complex than that. Sometimes it is sufficient to restart the barrier server process, and the client reconnects after a few seconds. Sometimes however, restarting the server does nothing, so I have to connect a keyboard or mouse to the client PC in order to restart the barrier client. The Server is connected via LAN, the client is connected via WiFi.

gitea-mirror commented

2026-05-05 06:04:57 -06:00

Author

Owner

@panaut0lordv commented on GitHub (Jun 23, 2020):

For me another suspend and resume makes it reconnect, still it's pretty reproducible and complaining about route to host. Windows client and Ethernet on both client & server,

@panaut0lordv commented on GitHub (Jun 23, 2020): For me another suspend and resume makes it reconnect, still it's pretty reproducible and complaining about route to host. Windows client and Ethernet on both client & server,

No labels

Rows
Columns