[GH-ISSUE #1849] Windows 10/11 Server Hangs Until Remote Stopped #1356

New issue

Open

opened 2026-05-05 07:45:05 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 07:45:05 -06:00

Owner

Originally created by @JerryFrum on GitHub (Dec 5, 2022).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1849

What happened?

Windows 10/11 as Server won't let me use keyboard/mouse locally to unlock the desktop. Keyboard/mouse works fine on Mac when Windows is locked - have to stop Mac Barrier client to "release" the keyboard/mouse to unlock the Windows system. Happens once every week or two with no rhyme/reason to why as its used the same way.

Version

v2.4.0

Git commit hash (if applicable)

No response

If applicable, where did you install Barrier from?

Github download

What OSes are you seeing the problem on? (Check all that apply)

Windows, macOS

What OS versions are you using?

Windows 10 Pro (latest as of Oct 2022)
Windows 11 Pro (latest as of Dec 2022)
Mac Monterey 12.6

Relevant log output

No response

Any other information

Mac is suspended daily with closing lid
Windows is locked with Win+L key

Will go into Windows at night remotely via RDP. In AM, will open Mac and unlock with fingerprint. However some mornings I'll go in and cannot unlock the Windows machine if the Mac is on/unlocked first. Have to go into Mac machine and stop the Barrier app to unlock K/M to allow me to login to Windows. Then re-enable Mac Barrier and things work fine.

Have gone thru now 2 different Windows OS' and have updated hardware drivers and even put new NIC in Windows machine (faster card). Mac has been connected via Wireless and also connected with wired NIC thru USB-C dongle. Because its so infrequent - hard to figure what's same/different with each time it happens.

Originally created by @JerryFrum on GitHub (Dec 5, 2022). Original GitHub issue: https://github.com/debauchee/barrier/issues/1849 ### What happened? Windows 10/11 as Server won't let me use keyboard/mouse locally to unlock the desktop. Keyboard/mouse works fine on Mac when Windows is locked - have to stop Mac Barrier client to "release" the keyboard/mouse to unlock the Windows system. Happens once every week or two with no rhyme/reason to why as its used the same way. ### Version v2.4.0 ### Git commit hash (if applicable) _No response_ ### If applicable, where did you install Barrier from? Github download ### What OSes are you seeing the problem on? (Check all that apply) Windows, macOS ### What OS versions are you using? Windows 10 Pro (latest as of Oct 2022) Windows 11 Pro (latest as of Dec 2022) Mac Monterey 12.6 ### Relevant log output _No response_ ### Any other information Mac is suspended daily with closing lid Windows is locked with Win+L key Will go into Windows at night remotely via RDP. In AM, will open Mac and unlock with fingerprint. However some mornings I'll go in and cannot unlock the Windows machine if the Mac is on/unlocked first. Have to go into Mac machine and stop the Barrier app to unlock K/M to allow me to login to Windows. Then re-enable Mac Barrier and things work fine. Have gone thru now 2 different Windows OS' and have updated hardware drivers and even put new NIC in Windows machine (faster card). Mac has been connected via Wireless and also connected with wired NIC thru USB-C dongle. Because its so infrequent - hard to figure what's same/different with each time it happens.

gitea-mirror commented

2026-05-05 07:45:07 -06:00

Author

Owner

@CodeDragon5 commented on GitHub (Jan 20, 2023):

I also use Win10 as the host, though I have a Linux client. I notice that this happens if I try to leave the host while on the login screen, which I still do accidentally if I shake my mouse too vigorously to wake the computer.

@CodeDragon5 commented on GitHub (Jan 20, 2023): I also use Win10 as the host, though I have a Linux client. I notice that this happens if I try to leave the host while on the login screen, which I still do accidentally if I shake my mouse too vigorously to wake the computer.

gitea-mirror commented

2026-05-05 07:45:08 -06:00

Author

Owner

@CodeDragon5 commented on GitHub (Jan 21, 2023):

Messing around with it a little, I found a work around that is effective for me: I added a hotkey combination with the action of Switch to Screen, selecting the host screen as the target. Pressing the hotkey pulled the cursor back to my host and allowed me to log into that computer without needing stop the client's Barrier instance.

@CodeDragon5 commented on GitHub (Jan 21, 2023): Messing around with it a little, I found a work around that is effective for me: I added a hotkey combination with the action of Switch to Screen, selecting the host screen as the target. Pressing the hotkey pulled the cursor back to my host and allowed me to log into that computer without needing stop the client's Barrier instance.

gitea-mirror commented

2026-05-05 07:45:09 -06:00

Author

Owner

@JerryFrum commented on GitHub (Jul 14, 2023):

Quick update - I've since upgraded my MBP (client for Barrier) to Ventura 13.4.1 and Win 11 (server for Barrier) - is on latest patches and such. Same issue occurs, open MBP first and sometimes the Win 11 system won't respond to keyboard presses util I stop Barrier on the MBP.

Barrier is still the same 2.4 version obviously.

@JerryFrum commented on GitHub (Jul 14, 2023): Quick update - I've since upgraded my MBP (client for Barrier) to Ventura 13.4.1 and Win 11 (server for Barrier) - is on latest patches and such. Same issue occurs, open MBP first and sometimes the Win 11 system won't respond to keyboard presses util I stop Barrier on the MBP. Barrier is still the same 2.4 version obviously.