github-starred/barrier

Fork 0

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

[GH-ISSUE #567] On Windows, barrierd creates zombie processes and causes System (ntoskrnl) to burn CPU #446

New issue

Open

opened 2026-05-05 06:23:56 -06:00 by gitea-mirror · 9 comments

gitea-mirror commented

2026-05-05 06:23:56 -06:00

Owner

Originally created by @nyanpasu64 on GitHub (Feb 16, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/567

Operating Systems

Server: Windows 10 Version 1909

Client: n/a

Barrier Version

2.3.2

Steps to reproduce bug

Boot up a Windows machine with Barrier installed.
Wait while the Barrier service (barrierd.exe) leaks barriers.exe handles.

If you download https://github.com/randomascii/blogstuff/blob/master/FindZombieHandles/prebuilt/FindZombieHandles.exe and run it, you'll see:

44 zombies held by barrierd.exe(40000)
    44 zombies of barriers.exe

The number of zombie processes increases over time. On my system that has been running for around 7 days, barrierd.exe leaked a whopping 15846 instances of barriers.exe.

This is not only a theoretical problem, but causes the Windows kernel (System, ntoskrnl.exe) to burn CPU, and audio drivers to encounter latency spikes (detected via LatencyMon).

Using Process Hacker, I noticed that the System (ntoskrnl) process thread 72 intermittently uses CPU time. By capturing a trace using WPRUI.exe and viewing in Windows Performance Analyzer, I found that MiTrimOrAgeWorkingSet is taking lots of time. Using Process Hacker to sleep thread 72 causes LatencyMon to not detect latency, but causes the Windows lock screen to hang the system instead.

Diagnostics and signs

Capturing an ETW trace: https://superuser.com/questions/527401/troubleshoot-high-cpu-usage-by-the-system-process

My symptoms: https://superuser.com/questions/1360097/how-to-control-cpu-usage-of-ntoskrnl-exemiwalkpagetablesrecursively

How I discovered that I had zombie processes: https://superuser.com/questions/1326046/windows-10-slowly-increases-ram-usage-on-2-different-pcs

Detecting that Barrier was leaking zombie processes: https://github.com/randomascii/blogstuff/blob/master/FindZombieHandles/prebuilt/FindZombieHandles.exe

Originally created by @nyanpasu64 on GitHub (Feb 16, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/567 ### Operating Systems ### Server: Windows 10 Version 1909 Client: n/a ### Barrier Version ### 2.3.2 ### Steps to reproduce bug ### 1. Boot up a Windows machine with Barrier installed. 2. Wait while the Barrier service (`barrierd.exe`) leaks `barriers.exe` handles. If you download https://github.com/randomascii/blogstuff/blob/master/FindZombieHandles/prebuilt/FindZombieHandles.exe and run it, you'll see: > 44 zombies held by barrierd.exe(40000) > 44 zombies of barriers.exe The number of zombie processes increases over time. On my system that has been running for around 7 days, barrierd.exe leaked a whopping 15846 instances of barriers.exe. This is not only a theoretical problem, but causes the Windows kernel (System, ntoskrnl.exe) to burn CPU, and audio drivers to encounter latency spikes (detected via LatencyMon). Using Process Hacker, I noticed that the System (ntoskrnl) process thread 72 intermittently uses CPU time. By capturing a trace using WPRUI.exe and viewing in Windows Performance Analyzer, I found that MiTrimOrAgeWorkingSet is taking lots of time. Using Process Hacker to sleep thread 72 causes LatencyMon to not detect latency, but causes the Windows lock screen to hang the system instead. ### Diagnostics and signs Capturing an ETW trace: https://superuser.com/questions/527401/troubleshoot-high-cpu-usage-by-the-system-process My symptoms: https://superuser.com/questions/1360097/how-to-control-cpu-usage-of-ntoskrnl-exemiwalkpagetablesrecursively How I discovered that I had zombie processes: https://superuser.com/questions/1326046/windows-10-slowly-increases-ram-usage-on-2-different-pcs Detecting that Barrier was leaking zombie processes: https://github.com/randomascii/blogstuff/blob/master/FindZombieHandles/prebuilt/FindZombieHandles.exe

gitea-mirror added the

bug

windows

critical

labels 2026-05-05 06:23:56 -06:00

gitea-mirror commented

2026-05-05 06:24:00 -06:00

Author

Owner

@SonicZentropy commented on GitHub (Feb 23, 2020):

This also happens with base synergy, not just Barrier. I found barrier specifically trying to get around te same thing happening with synergy

@SonicZentropy commented on GitHub (Feb 23, 2020): This also happens with base synergy, not just Barrier. I found barrier specifically trying to get around te same thing happening with synergy

gitea-mirror commented

2026-05-05 06:24:03 -06:00

Author

Owner

@shymega commented on GitHub (Feb 23, 2020):

@jimbo1qaz Thanks for your in-depth report. I've tagged this bug as critical, due to the nature of it.

@SonicZentropy Interesting to note. Was that Synergy 2.x?

Thanks.

@shymega commented on GitHub (Feb 23, 2020): @jimbo1qaz Thanks for your in-depth report. I've tagged this bug as critical, due to the nature of it. @SonicZentropy Interesting to note. Was that Synergy 2.x? Thanks.

gitea-mirror commented

2026-05-05 06:24:07 -06:00

Author

Owner

@SonicZentropy commented on GitHub (Mar 3, 2020):

@shymega No sir, I vastly prefer 1.x/Barrier to 2. Specifically, it was Synergy version:

1.10.3-stable-ca35737a

I wish I had more info for you, as I spent quite a while trying to figure out what was causing it. I never could reliably reproduce it or figure it out though. It happens very rarely and with no consistent pattern I can find. A couple of my friends who use Synergy have had it happen to them as well, also with no pattern or indications. I just wanted to chime in so you guys would know it comes from the synergy codebase and not barrier!

@SonicZentropy commented on GitHub (Mar 3, 2020): @shymega No sir, I vastly prefer 1.x/Barrier to 2. Specifically, it was Synergy version: 1.10.3-stable-ca35737a I wish I had more info for you, as I spent quite a while trying to figure out what was causing it. I never could reliably reproduce it or figure it out though. It happens very rarely and with no consistent pattern I can find. A couple of my friends who use Synergy have had it happen to them as well, also with no pattern or indications. I just wanted to chime in so you guys would know it comes from the synergy codebase and not barrier!

gitea-mirror commented

2026-05-05 06:24:10 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 28, 2020):

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions[bot] commented on GitHub (Sep 28, 2020): This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

gitea-mirror commented

2026-05-05 06:24:14 -06:00

Author

Owner

@nyanpasu64 commented on GitHub (Sep 28, 2020):

(Crossposting with #611, a duplicate)

Just installed v2.3.3 (which includes #656). I'm seeing errors every 10 seconds:

[2020-09-27T18:42:56] INFO: starting new process as privileged user
[2020-09-27T18:42:56] INFO: drag and drop enabled
barriers.exe: no configuration available
[2020-09-27T18:42:57] ERROR: failed to launch, error: process immediately stopped
[2020-09-27T18:42:57] INFO: backing off, wait=10s, failures=9

and barrierd.exe eats 4 more handles every time an attempt occurs, but I didn't wait long enough to watch the handle count rise.

FindZombieHandles.exe reports the zombie process count incrementing by 1 at a time.

I think #656 didn't fix this bug.

@nyanpasu64 commented on GitHub (Sep 28, 2020): (Crossposting with #611, a duplicate) Just installed v2.3.3 (which includes #656). I'm seeing errors every 10 seconds: ``` [2020-09-27T18:42:56] INFO: starting new process as privileged user [2020-09-27T18:42:56] INFO: drag and drop enabled barriers.exe: no configuration available [2020-09-27T18:42:57] ERROR: failed to launch, error: process immediately stopped [2020-09-27T18:42:57] INFO: backing off, wait=10s, failures=9 ``` and barrierd.exe eats 4 more handles every time an attempt occurs, but I didn't wait long enough to watch the handle count rise. FindZombieHandles.exe reports the zombie process count incrementing by 1 at a time. I think #656 didn't fix this bug.

gitea-mirror commented

2026-05-05 06:24:17 -06:00

Author

Owner

@imtbl commented on GitHub (Dec 19, 2020):

This issue seems to be fixed in Synergy now:

https://github.com/symless/synergy-core/pull/6762
https://github.com/symless/synergy-core/issues/6567#issuecomment-735831518

@imtbl commented on GitHub (Dec 19, 2020): This issue seems to be fixed in Synergy now: https://github.com/symless/synergy-core/pull/6762 https://github.com/symless/synergy-core/issues/6567#issuecomment-735831518

gitea-mirror commented

2026-05-05 06:24:20 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):

@imtbl That's a great find, thank you!

@p12tic commented on GitHub (Jan 10, 2021): @imtbl That's a great find, thank you!

gitea-mirror commented

2026-05-05 06:24:22 -06:00

Author

Owner

@yutotakano commented on GitHub (Apr 14, 2021):

I'd be wary of cherry-picking that fix still, because according to that thread it's still an ongoing problem... :(

@yutotakano commented on GitHub (Apr 14, 2021): I'd be wary of cherry-picking that fix still, because according to that thread it's still an ongoing problem... \:(

gitea-mirror commented

2026-05-05 06:24:24 -06:00

Author

Owner

@mirh commented on GitHub (Feb 28, 2022):

Can confirm even in 2.4.0 (of course you need some of the other issue that makes service start fail, to then trigger this nuisance)
Btw you have to download all files in this folder, no just the exe.

@mirh commented on GitHub (Feb 28, 2022): Can confirm even in 2.4.0 (of course you need some of the other issue that makes service start fail, to then trigger this nuisance) Btw you have to download all files in [this folder](https://github.com/randomascii/blogstuff/tree/main/FindZombieHandles/prebuilt), no just the exe.

No labels

Rows
Columns