If you have followed InputMapper for any length of time, you have met two similarly named tools: HidGuardian and HidHide. Both exist to solve the same problem — hiding a physical controller so games only see the virtual one — but they come from different eras of PC controller mapping, and they work in fundamentally different ways. Running the wrong one, or worse, running both, is a reliable source of vanished controllers and confusing errors.
This article tells the full story: why hiding was so hard in the ScpToolkit era, how HidGuardian and its companion service HidCerberus worked, why the developer retired that design, how HidHide does the job differently, and what you should do if the old stack is still installed on your PC.
The Original Problem: Games See Everything
Controller mapping creates a duplicate by design. InputMapper reads your physical DualShock 4 and presents a virtual Xbox controller to Windows. Unless something intervenes, Windows offers both devices to every game. Games that accept input from all connected controllers then register each press twice — the original DS4 signal and the remapped virtual signal arrive as two separate inputs.
The older InputMapper generations had it worse. InputMapper 1.5 and 1.6 were built on the Scp stack, using ScpVBus as their virtual bus. That era’s tooling had no clean, reliable way to hide the physical controller from selected applications. Users fought double input with exclusive-mode tricks and per-game workarounds that broke whenever a game grabbed devices in a different order or a driver update reshuffled things. The need was obvious: a proper, system-level way to say “this physical device should be invisible — except to the one program doing the mapping.” If you want the background on that older stack and why it aged badly, see our article on ScpToolkit and ScpVBus risks.
HidGuardian and HidCerberus: How the Pair Worked
HidGuardian was nefarius’ answer from that era. Developed between late 2016 and 2018, it is a kernel-mode filter driver with a blunt but effective approach: once a controller was placed under its protection, HidGuardian hid that device from all applications, without exception.
Complete hiding creates an obvious problem — the mapping tool itself also needs to see the controller. That is where the companion piece came in. HidCerberus was a Windows service that acted as the “whitelister.” Applications did not talk to HidGuardian directly; instead, a tool like InputMapper asked HidCerberus for access, and the service decided who was permitted to see the protected device. If your program was on the approved list, HidCerberus let it through. Everything else saw nothing at all.
This is why InputMapper 1.7-era installations included a file named HidCerberus.Srv.exe. That executable was the whitelister service. If it was not running, was blocked, or had fallen out of sync with the driver, the protected controller effectively ceased to exist for every program on the machine — including InputMapper. Many “my controller disappeared completely” reports from that period trace back to this two-part design: the driver hid aggressively, and a separate service held the only keys.
Why HidGuardian Was Retired
The most important fact about HidGuardian comes from its own developer: nefarius describes it as a research project and proof of concept. It was an experiment in how device hiding could be done at the kernel level, not a product designed for years of mainstream support.
Once the concept was proven, the sensible move was to build the real solution properly. HidGuardian’s repository was archived in favour of HidHide, its direct successor. The old driver receives no updates and no fixes, and its design — total hiding controlled through a separate whitelister service — carries inherent fragility: two components that must agree, a service that must be running, and an all-or-nothing hiding model with little room for nuance.
None of this makes HidGuardian malicious or dangerous in itself. It makes it obsolete. Keeping an archived, proof-of-concept kernel driver in your input path when a maintained replacement exists is technical debt sitting at the lowest, most sensitive level of your system. Stability problems, including the blue-screen cases covered in our HidGuardian blue screen migration article, are exactly where that debt tends to surface.
HidHide: The Same Job, Designed Differently
HidHide was written from scratch as HidGuardian’s successor. The developer calls it a HID device firewall, and the firewall metaphor captures the design difference well. Instead of hiding a device from absolutely everything and punching holes through a separate gatekeeper service, HidHide itself manages a per-application whitelist: you choose which devices to hide, and the configuration directly lists which applications may still see them.
In practice that gives you a single tool with a single configuration client. You add the physical DualShock 4 to the hidden list, add InputMapper to the applications list, and enable device hiding. There is no separate whitelister service to babysit. HidHide also offers an inverse mode that flips the logic for users who only need to hide a device from specific applications.
The current release is v1.5.230 (May 11, 2024), distributed via GitHub releases for Windows 10/11 64-bit Intel/AMD systems. Our HidHide setup guide walks through installation and configuration step by step. Like ViGEmBus, HidHide is an independent nefarius project — it is not part of InputMapper, but it is the hiding layer the InputMapper 1.7 workflow was always meant to be paired with, replacing its own era’s HidGuardian arrangement.
Side-by-Side Comparison
| Aspect | HidGuardian | HidHide |
|---|---|---|
| Developer | nefarius | nefarius |
| Era | Developed late 2016 to 2018 | Successor project; latest v1.5.230 (May 11, 2024) |
| Status | Archived; research project / proof of concept | Current recommended solution |
| Codebase | Original experimental driver | Written from scratch as the successor |
| Hiding model | Hides protected devices from all applications | Hides devices from all except whitelisted applications |
| Access control | Separate HidCerberus service (the whitelister) decides who may see the device | Per-application whitelist managed inside HidHide’s own configuration |
| InputMapper era | InputMapper 1.7-era installs included HidCerberus.Srv.exe | Recommended pairing for InputMapper 1.7 today |
| Extra modes | None documented here | Inverse whitelist mode available |
Which One Is on Your PC — and What to Do
Check what you actually have before changing anything. Open Settings → Apps and look for HidHide, HidGuardian, and related legacy components. In older InputMapper 1.7-era installations, the presence of HidCerberus.Srv.exe among the installed files is the tell-tale sign of the HidGuardian stack. You can also scan Device Manager for legacy filter-driver entries while looking at your controller devices.
Then act on what you find:
- HidHide only: you are on the modern setup. Nothing to do — configure it per the setup guide and play.
- HidGuardian / HidCerberus only: plan a migration. Install HidHide, reproduce your hiding setup there (hide the physical pad, whitelist InputMapper), verify with
joy.cplthat only the virtual controller is visible to non-whitelisted apps, and only then remove the old components. The step-by-step migration, including what to do if the old driver is causing crashes, is in the blue screen and migration article. - Both installed: do not leave two hiding systems stacked. Decide on HidHide as the keeper, confirm it works on its own, and remove the HidGuardian-era pieces so only one driver is making visibility decisions.
- Neither installed: if you play without double-input problems, you may not need hiding at all. Install HidHide only if a game actually shows duplicate inputs.
Whichever path you take, change one layer at a time and test in a game after each change. Input problems are far easier to diagnose when you know exactly which step altered the behaviour. If you are starting from a clean installation, the download page plus the getting started guide will put the modern stack — InputMapper, ViGEmBus, HidHide — together in the right order.
Frequently Asked Questions
Is HidHide the same program as HidGuardian with a new name?
No. HidHide is the direct successor of HidGuardian, but it was written from scratch. HidGuardian hid protected devices from all applications and relied on the separate HidCerberus service as the whitelister. HidHide manages a per-application whitelist itself, inside one configuration client.
Why did the developer stop HidGuardian?
Nefarius describes HidGuardian as a research project and proof of concept developed from late 2016 to 2018. Once a better solution was built, the repository was archived in favour of HidHide. It receives no updates or fixes.
I found HidCerberus.Srv.exe on my PC. What is it?
It is the whitelister service from the HidGuardian era, included with InputMapper 1.7-era installations. It decided which applications were allowed to see controllers hidden by HidGuardian. Its presence means the legacy stack is, or was, installed — plan a migration to HidHide.
Can I run HidGuardian and HidHide at the same time?
You should not. Two hiding systems making visibility decisions about the same device leads to unpredictable results, including controllers vanishing from everything. Migrate fully to HidHide and remove the HidGuardian-era components.