Fifteen Processes Watching My Keyboard
My typing on the main PC was lagging seconds behind me. Bad enough to record it on my phone. This is what the audit found — and what I did with it.
The symptom
Type a sentence at normal pace, watch the characters appear a couple of seconds later, out of order, with drops. A message that should have read ok do 1 by 1 and log the results came out okj do 1 by 1 and log the results.. thisw thyping is a tes and being recoreded as a basline for our studies. The phone caught the delay between finger and screen.
My first move was going to be moving the powered USB hub off the extension cable that runs to my desk. Extension cables are the physical suspect. They're the part of the path you can pick up and swap. And there's a version of me — from before I started doing this work with Claude Code as the sparring partner — that would have pulled the plug, moved the hub to a different port, and called it fixed.
Instead I asked for a full system audit before touching hardware.
What the audit showed
Uptime: 18 hours. CPU: 22% average across three samples. RAM: 20 GB free of 32. Disk: idle at 0%. Thermal: fine. Power scheme: High Performance. No pending Windows update.
The audit ran the checks that would have shown physical distress:
- Zero USB error events in the last 24 hours. If the extension cable were dropping packets or causing hub resets, this log fills up. It was empty.
- Zero PnP churn events in the last hour. If the driver stack were re-enumerating devices, this counter climbs. It was flat.
- No thermal throttling, no runaway process, no antivirus scan in progress.
If the cable had been the cause, at least one of those signals would have been dirty. None were.
The audit did find things. The one that mattered:
Fifteen instances of RazerAppEngine.exe running simultaneously.
Together, ~1.5 GB of RAM and roughly 450 seconds of accumulated CPU time. All of them hooked into the keyboard's HID stack — the code path that carries every keystroke from the device up to whatever application is receiving it — for macro detection and per-key RGB lighting sync.
Fifteen hooks. On one keyboard. Every keystroke fanning out fifteen ways before the character reached the application I was trying to type into.
The isolation test
I killed all fifteen RazerAppEngine instances in one command. No reboot. No uninstall. Nothing else touched.
- Total processes on the system: 282 → 267
- RAM freed: ~1.2 GB
- Average CPU load: 22% → 8%
Then I typed a test line in Notepad. The reply came back:
WOAH LAG GONE INSTANT TYPING
All caps, zero typos, one-shot. Followed later by "yeah alll goodbetter test was my ranom finger jabbing teqnique" — a stress test with deliberate chaos. Also clean.
Diagnostic complete. Root cause: vendor peripheral software leaking hooks into the input stack. Not the cable, not the hub, not the driver, not the phantom devices in the PnP tree, not the antivirus. The software the keyboard vendor wanted running so their RGB could pulse in time with a game.
The durable fix
I could have set a scheduled task to kill orphan RazerAppEngine instances at every login. That would work as a mitigation. It would also mean maintaining a workaround forever for a bug I did not create.
Instead I uninstalled the whole vendor stack: the main app, the Chroma runtime, the game-tracking layer, plus a third-party Elite Dangerous lighting integration that had piggy-backed on it. Eight background services stopped and disabled. Six running processes killed. Registry entries removed. Around 3.5 GB of on-disk footprint freed across Program Files, Program Files (x86), ProgramData, and the user's LocalAppData (the last of which alone was 2.2 GB).
The keyboard and mouse still work. Windows sees them as generic HID devices and drives them correctly out of the box. Typing works. Clicking works. The extra thumb buttons on the mouse — which the games I play care about — are standard HID buttons, so games see them natively without any vendor middleware in the loop.
Replacement stack, open source, no bloat:
- OpenRGB — cross-vendor RGB control for the keyboard and mouse. Free, open source, actively maintained. Both my devices are on its supported list with full per-key control.
- PowerToys Keyboard Manager — key remapping. Made by Microsoft. Installed alongside PowerToys' other utilities that I already wanted.
- AutoHotkey — for macros if I ever need them again. Script-driven, no background daemon.
None of them hook into the keyboard the way the vendor stack did. None of them fan out fifteen background processes when I open a game.
What the exercise was actually about
The lag was the symptom. The lesson was that I nearly blamed the cable — the physical thing I could see and touch — when the actual problem was invisible, was software I did not install with intent (it came bundled with the driver installer), and had been quietly degrading a fundamental input path for weeks or months without my noticing.
Audit before you assume the physical suspect. And when a vendor gives you 800 MB of RGB software to run their peripheral, ask what it costs you to keep it running in the background of every keystroke you type for the rest of the machine's life.
Mine was costing me the ability to type at pace. Yours might be costing you something you haven't measured yet.
Sister piece from Nyx on the diagnostic pattern behind this fix: The Physical Suspect.