This guide covers the final release, version 1.22.0, how to download it safely from GitHub, how to install and verify it, how to upgrade an older copy correctly, and how to remove it cleanly. It also explains an important safety warning about the old vigem.org domain, which you should never use for downloads.

What ViGEmBus Is — and What It Is Not

ViGEmBus stands for Virtual Gamepad Emulation Bus. It is a Windows kernel-mode driver developed by nefarius, the developer name of Benjamin Höglinger-Stelzer of Nefarius Software Solutions e.U. in Austria. The project is released under the BSD-3-Clause license and was developed as an independent, open-source project.

ViGEmBus is not part of InputMapper. It is not made by DSDCS, the developer behind InputMapper, and it is not bundled as an InputMapper component in any official sense. InputMapper 1.7 simply uses ViGEmBus as its output method. When InputMapper reads your physical DualShock 4, it asks ViGEmBus to present a virtual Xbox 360 controller to Windows, and your games interact with that virtual controller.

That separation matters for troubleshooting. A ViGEmBus installation problem is a driver problem, not an InputMapper profile problem. A missing or broken bus driver produces errors such as a virtual bus not being found, controllers that appear in InputMapper but never appear in games, and mapping tools that start normally but do nothing when you press buttons. If you see those symptoms, start with the driver, not with your button mappings. Our virtual bus not found guide walks through that specific error in more detail.

Who Needs ViGEmBus?

You need ViGEmBus if you use a tool that outputs through it. The two most common cases for readers of this site are:

• InputMapper 1.7 — the final InputMapper release, version 1.7.7452.13622 from May 2020, outputs exclusively via ViGEmBus.
• DS4Windows — the maintained DS4Windows continuation also uses ViGEmBus for its virtual controller output. See our DS4Windows install guide for the full setup order.

You do not need ViGEmBus for a controller that Windows and your game already support natively. An Xbox controller used on its own does not need a virtual bus. A DualShock 4 used in a game with native DualShock support does not need one either. Install ViGEmBus when a mapping tool explicitly requires it — not as a general controller fix.

ViGEmBus 1.22.0: The Final Release

Version 1.22.0 was released on November 2, 2023. The developer titled it the “It’s dead, Jim” release, and it is the final version. The GitHub repository has been archived, which means no further updates, bug fixes, or new builds are planned.

The retirement was not caused by a technical failure. According to the developer, the project was retired following a trademark conflict with ViGEM GmbH. As part of that outcome, the vigem.org domain was handed over in December 2023. That history is the reason for the safety warning later in this guide: the old domain is no longer controlled by the developer, and you should never download the driver from it.

Being final does not mean being broken. Version 1.22.0 remains the correct, known-good build for InputMapper 1.7 and DS4Windows on current Windows versions. What “final” means in practice is that you should install exactly this version, verify it carefully, and not go looking for a newer one — there is none, and any site claiming to offer ViGEmBus 1.23 or later is not offering a genuine release.

Download ViGEmBus 1.22.0

The official source is the nefarius GitHub releases page. The release asset is named ViGEmBus_1.22.0_x64_x86_arm64.exe. Use the button below to go to that GitHub asset via our download redirect:

Download ViGEmBus 1.22.0 from GitHub

If GitHub is unreachable from your network, a mirror copy is available here: Download ViGEmBus 1.22.0 (mirror). The mirror is a secondary copy for convenience only — GitHub remains the authoritative source, and you should verify the file hash after downloading from any mirror, as described in the next section.

Avoid third-party driver download sites entirely. Old versions of this driver circulated with bundled updaters that pointed at the old vigem.org domain. Version 1.22.0 removed the updater entirely, specifically because those old updaters continuing to contact a domain the developer no longer controls was identified in the End-of-Life note as a privacy risk. A genuine 1.22.0 installer does not contain an updater and will never ask you to update ViGEmBus from the web.

Verify Your Download with SHA-256

Before installing any kernel driver, verify the file. The verified details for the genuine 1.22.0 asset are:

• File name: ViGEmBus_1.22.0_x64_x86_arm64.exe
• File size: 6,278,576 bytes
• SHA-256: 89220a7865076b342892f98865f3499fb7c4cfd673159e89d352c360fd014c6a

This hash was confirmed by direct download from GitHub. To check your copy on Windows, open PowerShell in the folder where you saved the file and run:

Get-FileHash .\ViGEmBus_1.22.0_x64_x86_arm64.exe -Algorithm SHA256

Compare the output character by character with the hash above. If even one character differs, or the file size is different, do not install the file. Delete it and download again from GitHub using the button above. A mismatch means you do not have the genuine release asset — it may be corrupted, incomplete, or repackaged by a third party.

Install Steps

1. Close InputMapper, DS4Windows, and any games. Driver installation is cleaner when nothing is actively using the virtual bus.
2. Right-click the downloaded installer and choose Run as administrator. A kernel driver cannot install correctly without elevated rights.
3. Follow the installer prompts and accept the driver installation dialog from Nefarius Software Solutions e.U. if Windows asks you to confirm installing the device driver.
4. Restart Windows when the installer finishes, even if you are not prompted. A restart guarantees the bus driver is loaded in its final state before you test any mapping tool.
5. After the restart, open Device Manager and look under System devices for the Nefarius Virtual Gamepad Emulation Bus entry. Its presence confirms the bus driver is installed.
6. Start InputMapper from the InputMapper download page build, connect your controller, and confirm a virtual controller appears in Windows Game Controllers (joy.cpl).

Upgrading in place: the official release notes give one unusual instruction — if you are upgrading over an existing ViGEmBus installation, run the installer twice. Run it once, let it finish, then run it again before restarting. This ensures the old driver files are fully replaced. Skipping the second run is a known cause of “I updated but nothing changed” reports.

Uninstalling ViGEmBus

If you are moving away from InputMapper and DS4Windows entirely, you can remove the driver cleanly:

1. Close all mapping tools and disconnect your controllers.
2. Open Settings → Apps → Installed apps, find the ViGEmBus entry, and uninstall it. Alternatively, use Programs and Features in Control Panel.
3. Restart Windows to unload the driver completely.
4. Optionally, open Device Manager, enable View → Show hidden devices, and confirm the Nefarius Virtual Gamepad Emulation Bus entry is gone.

Do not uninstall ViGEmBus while you still rely on InputMapper 1.7 or DS4Windows — both tools will stop producing a virtual controller immediately. If your goal is fixing double input rather than removing the stack, keep ViGEmBus installed and read our HidHide setup guide instead. For other problems, the InputMapper troubleshooting hub collects the common fixes in one place.

Frequently Asked Questions

Is ViGEmBus part of InputMapper?

No. ViGEmBus is an independent open-source project by nefarius (Benjamin Höglinger-Stelzer, Nefarius Software Solutions e.U.), released under the BSD-3-Clause license. InputMapper 1.7 uses it for virtual controller output, but the two projects have different developers.

What is the latest version of ViGEmBus?

Version 1.22.0, released on November 2, 2023, is the final version. The GitHub repository is archived and no newer release exists. Any site offering a higher version number is not offering a genuine release.

Why should I never download ViGEmBus from vigem.org?

The vigem.org domain was handed over in December 2023 following a trademark conflict with ViGEM GmbH and is no longer controlled by the developer. The End-of-Life note warns that old updaters still pointing at the old domain are a privacy risk. Version 1.22.0 removed the updater entirely. Always download from GitHub instead.

Why do the release notes say to run the installer twice?

For in-place upgrades over an existing installation, the release notes instruct you to run the installer twice so the old driver files are fully replaced. Run it, let it finish, run it again, and then restart Windows.

What ScpToolkit and ScpVBus Were

ScpToolkit was a driver package from the PlayStation controller era before the current tools matured. Its job was to make Sony controllers usable on Windows by installing the components games expected. At its core sat ScpVBus — the “SCP Virtual Bus” — a virtual bus driver that presented emulated controllers to the system, playing the same architectural role that ViGEmBus plays today.

The connection to this site is direct. InputMapper’s older generations were built on that stack: InputMapper 1.5 and 1.6 used ScpVBus for their virtual controller output. Only with the 1.7 generation did InputMapper move to ViGEmBus. So if you installed InputMapper around the mid-2010s and followed the instructions of the day, Scp components very likely went onto your machine as part of the deal — and on machines that were never cleaned up, they may still be there now.

Why 2016-Era Guides Still Recommend It

Old guides are not lying about their own era. In 2016, ScpToolkit was a mainstream answer, forum threads linked to it constantly, and for InputMapper 1.5/1.6 users it was effectively a required dependency. The problem is purely one of time. Blog posts and videos from that period still rank in search results, still get copied into new “guides” by content farms, and still present the installation as current best practice without mentioning that the InputMapper line moved on, that the successor driver exists, or that a vulnerability has since been recorded against the old build.

Treat any controller guide’s driver advice as dated by its publication year. If a page recommends ScpToolkit as the first step and never mentions ViGEmBus, you are reading history, not instructions.

The Documented Risk: CVE-2019-25464

The concrete, on-the-record risk involves the InputMapper build from the Scp era. InputMapper 1.6.10 has CVE-2019-25464 recorded against it — a buffer overflow vulnerability. A CVE entry means the flaw was formally catalogued in the public vulnerability database; it is not forum speculation.

Put the risk in proportion. This does not mean your PC is compromised, and a legacy driver sitting unused is not an emergency. What it does mean is that deliberately installing or keeping the 1.6.10-era stack in 2026 means running code with a known, documented flaw at driver level, when a maintained-successor stack exists that does the same job. The rational response is not panic — it is a planned cleanup, which the rest of this article walks through. If you are still actively using InputMapper 1.6.10, moving to the final 1.7 build from the download page is part of that cleanup.

When Scp and ViGEmBus Stacks Coexist

The most common day-to-day problem with the legacy stack is not security drama — it is conflict. Two virtual bus drivers on one system means two pieces of low-level software both able to create virtual controllers, enumerate devices, and interact with the same input path. Typical symptoms include:

• Phantom or duplicate controllers appearing in Windows Game Controllers (joy.cpl).
• InputMapper reporting the virtual bus as missing or unstable even though ViGEmBus 1.22.0 is correctly installed, because the legacy stack is interfering with device enumeration. (If this is your exact error, see the virtual bus not found guide after cleanup.)
• Controllers that work in one game and misbehave in another, depending on which virtual device each game enumerates first.
• Exclusive-mode failures that resist every profile tweak, because the conflict lives below the application layer — our exclusive mode guide covers the application-level causes once the driver layer is clean.

Driver stacks are not a “more is better” situation. One virtual bus — the current one — is the goal.

Safe Removal: Step by Step

Remove the legacy stack carefully and in order. You are working with kernel-level drivers, so give yourself an undo button first.

1. Create a restore point. Open “Create a restore point” from the Start menu and make one manually before touching any driver. If anything goes wrong, this is your way back.
2. Close everything controller-related. Exit InputMapper and any other mapping tools, and disconnect your controllers.
3. Uninstall the applications first. In Settings → Apps, uninstall ScpToolkit and any Scp-related components, plus old InputMapper 1.5/1.6 installs if present. Applications go before drivers, so nothing is left trying to call a driver you are about to remove.
4. Clean up leftover devices. Open Device Manager, enable View → Show hidden devices, and look for legacy Scp/ScpVBus entries (including greyed-out ones) under system and controller device categories. Remove leftover ScpVBus device entries you find. Be conservative: if an entry is clearly part of your current, working hardware, leave it alone.
5. Check hidden driver remnants. While hidden devices are shown, also clear greyed-out duplicate controller entries left behind by the old stack — stale duplicates are a frequent cause of “the game sees two controllers” even after uninstall.
6. Restart Windows. Driver removal is not complete until a restart unloads everything. Do not skip this and immediately judge the results.

If a step fails — an uninstaller errors out, or an entry refuses to remove — stop and restart, then retry that single step before continuing. Forcing your way through a half-removed driver stack is how small cleanups turn into long evenings. Further help lives in the troubleshooting hub.

The Modern Replacement Stack

Once the legacy components are out, the current stack is small and well defined:

• ViGEmBus 1.22.0 replaces ScpVBus as the virtual bus. Install it with verification using our ViGEmBus install guide.
• HidHide replaces the era’s ad-hoc hiding workarounds, hiding the physical controller from games while whitelisting your mapping tool — see the HidHide setup guide.
• InputMapper 1.7.7452.13622, the final InputMapper build, sits on top and outputs through ViGEmBus.

That trio does everything the Scp-era setup did, with components that were maintained years longer, no recorded CVE against the mapper build, and no second bus driver fighting for the same devices. If your PC still carries pieces of 2016, an hour spent on this cleanup is the single highest-value maintenance task for your controller setup.

Frequently Asked Questions

Is ScpToolkit dangerous to have installed?

The documented issue is specific: InputMapper 1.6.10, from the ScpVBus era, has CVE-2019-25464, a buffer overflow, recorded against it. That is a reason to plan a cleanup and move to the modern stack, not a reason to panic. An unused legacy driver is technical debt with a known flaw, and removing it removes the question entirely.

Why do so many guides still tell me to install ScpToolkit?

Because they were written when it was correct advice. InputMapper 1.5 and 1.6 used ScpVBus, so 2016-era guides recommend the Scp stack. Those pages still rank today, but InputMapper 1.7 moved to ViGEmBus, and the old advice is now outdated.

Can ScpVBus and ViGEmBus be installed together?

They can end up installed together, but they should not stay that way. Two virtual bus drivers cause phantom controllers, enumeration conflicts, and virtual-bus errors. Remove the Scp stack and keep ViGEmBus 1.22.0 as the single virtual bus.

What should I install instead of ScpToolkit?

The modern stack: ViGEmBus 1.22.0 as the virtual bus, HidHide for hiding the physical controller, and InputMapper 1.7.7452.13622 as the mapper. Create a restore point, uninstall the Scp components first, clean up leftover devices in Device Manager, restart, then install the new stack.

HidHide is the tool that fixes this properly. It hides your physical controller from games while still letting InputMapper see it. This guide covers what HidHide does, how to install it, how to configure it step by step for InputMapper, how to confirm the cloak is working, and how to undo everything if you ever want to.

What HidHide Does

HidHide is a HID device firewall developed by nefarius, the same developer behind ViGEmBus. HID stands for Human Interface Device — the category that includes game controllers. A firewall for HID devices works by controlling which applications are allowed to see which devices.

In a typical InputMapper setup the data flow looks like this: your physical DualShock 4 talks to InputMapper, InputMapper translates it, and ViGEmBus presents a virtual Xbox controller to your game. The problem is the shortcut Windows leaves open — the game can also see the physical DualShock 4 directly, bypassing InputMapper entirely. One press, two controllers, two inputs.

HidHide closes that shortcut. You place the physical controller on its hidden list, and HidHide then conceals that device from every application except the ones you explicitly whitelist. InputMapper stays whitelisted, so it keeps receiving the real controller. Your games are not whitelisted, so all they can see is the clean virtual controller. Double input disappears because there is only one visible controller left for the game to hear.

HidHide is the direct successor of HidGuardian, the older hiding tool from the InputMapper 1.7 era. It was written from scratch as a replacement, not patched on top of the old code. If you are still running HidGuardian and HidCerberus components from an old install, read our HidGuardian vs. HidHide comparison before adding HidHide — you want one hiding system, not two.

Requirements and Download

The latest release covered here is HidHide v1.5.230, released on May 11, 2024. The installer asset is HidHide_1.5.230_x64.exe (8,078,016 bytes), published on GitHub releases. This build supports Windows 10 and Windows 11 on 64-bit Intel and AMD systems only. There is no 32-bit build, so if you are on a 32-bit Windows installation, HidHide is not an option for your machine.

Download HidHide from GitHub using the button below:

Download HidHide 1.5.230 from GitHub

Before you start, make sure the rest of the stack is in place. You need InputMapper installed from the download page and a working ViGEmBus driver — if you have not installed that yet, follow the ViGEmBus install guide first. HidHide hides a device; it does not create the virtual controller that replaces it.

Install HidHide

1. Close InputMapper and any running games.
2. Right-click HidHide_1.5.230_x64.exe and choose Run as administrator. HidHide installs a driver-level component, so elevation is required.
3. Complete the installer, then restart Windows when prompted. The hiding driver is not fully active until after a restart.
4. After the restart, open the HidHide Configuration Client from the Start menu. This small window is where all configuration happens — you will use its Applications tab and Devices tab.

Configure HidHide for InputMapper

Work through these three steps in order: whitelist the applications that must keep seeing the real controller, hide the physical controller, then switch hiding on.

Step 1: Whitelist InputMapper and Your Essential Tools

Open the Configuration Client and go to the Applications tab. Add the InputMapper executable to the list. Any application on this list can still see hidden devices, so InputMapper belongs here — without this entry, you would hide the controller from the very program that needs it.

Think carefully about what else belongs on this list. Whitelist any other tool that must access the real, physical pad directly — for example, a configuration utility you use to check the physical controller itself, or another mapping program you run instead of InputMapper for some games. Do not whitelist your games. The entire point is that games should only see the virtual controller. A common beginner mistake is whitelisting everything “just in case,” which quietly disables the fix.

Step 2: Add the Physical DS4 to the Hidden List

Connect your DualShock 4 the way you normally play — USB or Bluetooth — and switch to the Devices tab. You will see the connected HID devices listed. Identify your physical DualShock 4 entry and check the box to hide it.

Be precise here. Hide the physical controller, not the virtual Xbox 360 controller created by ViGEmBus. If several similar entries appear, disconnect and reconnect the pad and watch which entry appears and disappears. Hiding the wrong device is reversible, but identifying the right one now saves a confusing test later.

Step 3: Enable Device Hiding

Tick the Enable device hiding option in the Configuration Client. The moment hiding is active, non-whitelisted applications lose sight of the physical pad. The setting takes effect without another restart in most cases, but if your test below looks wrong, one restart after enabling hiding is a sensible first check.

Verify the Cloak with joy.cpl

Do not trust a checkbox — verify. With InputMapper running and your controller connected, press Win + R, type joy.cpl, and press Enter to open Windows Game Controllers.

Because joy.cpl itself is not whitelisted, it shows you the game’s point of view. You should see only the virtual Xbox 360 controller in the list — the physical DualShock 4 should be absent. Open the virtual controller’s properties and press buttons on your real pad: the indicators should respond, proving the chain physical pad → InputMapper → virtual controller is alive, while the physical device itself stays cloaked.

If you still see both controllers in joy.cpl, hiding is not active: re-check that Enable device hiding is ticked and that you hid the physical device entry, not the virtual one. If you see neither controller, InputMapper is probably not running, or the physical pad was hidden without InputMapper being whitelisted — re-check Step 1. Our dedicated double input fix walkthrough covers the remaining edge cases, including games that cache controller lists at launch and need a full restart after you change HidHide settings.

Inverse Whitelist Mode

HidHide also offers an inverse whitelist mode, sometimes described as blacklist-style operation. In normal mode, a hidden device is concealed from everything except whitelisted applications. In inverse mode, the logic flips: the device remains visible generally, and you instead specify the applications it should be hidden from.

Inverse mode can be convenient if you only need to hide the pad from one or two specific games and want everything else to keep direct access. For a dedicated InputMapper setup, however, the standard whitelist mode is the safer default: new games automatically get the correct, hidden view without you having to remember to add each one. Whichever mode you choose, verify with joy.cpl afterwards — the test is identical.

How to Undo HidHide

Everything HidHide does is reversible from the same Configuration Client. To temporarily restore normal visibility, simply untick Enable device hiding. To stop hiding one controller, uncheck it on the Devices tab. To remove the tool completely, uninstall HidHide from Settings → Apps and restart Windows; after uninstall, all devices are visible to all applications again, exactly as they were before. Note that if you remove HidHide while still using InputMapper, the double input problem it was solving will return — that is expected behaviour, not a new fault.

Troubleshooting Basics

• Controller vanished everywhere, including InputMapper: InputMapper is missing from the Applications whitelist. Add its executable and re-enable hiding.
• Double input persists in one game: the game may have been whitelisted by mistake, or it cached controllers before hiding was enabled. Remove it from the whitelist, fully close the game, and relaunch it.
• Physical pad missing from the Devices tab: connect it before opening the client, try the other connection method (USB versus Bluetooth), and confirm it appears in joy.cpl with hiding disabled.
• Nothing hides after configuration: restart Windows once so the driver reloads with your settings, then repeat the joy.cpl check.

For wider problems beyond hiding — devices not connecting, exclusive-mode errors, or crashes — the troubleshooting hub is the best starting point.

Frequently Asked Questions

Does HidHide replace ViGEmBus?

No. They do different jobs. ViGEmBus creates the virtual controller that games see, while HidHide hides the physical controller from games. A complete InputMapper setup needs both: ViGEmBus for output and HidHide to prevent double input.

Which applications should I whitelist in HidHide?

Whitelist InputMapper and any tool that must access the real physical controller directly. Do not whitelist your games — games should only see the virtual controller, which is what stops double input.

How do I check that HidHide is actually hiding my controller?

Open Windows Game Controllers by running joy.cpl while InputMapper is running. Because joy.cpl is not whitelisted, you should see only the virtual Xbox 360 controller, not the physical DualShock 4. Button presses on the real pad should still register in the virtual controller’s properties.

Can I remove HidHide without breaking InputMapper?

Yes. Untick Enable device hiding to disable it temporarily, or uninstall HidHide from Settings and restart. InputMapper will keep working, but the double input problem HidHide was solving will return because games will see the physical controller again.

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

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.cpl that 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.

This guide untangles the three DS4Windows lineages, tells you which version is real and maintained today, and gives you the correct install order. It also explains why a DS4Windows guide belongs on an InputMapper site at all — the two tools share roots, and for one increasingly common controller, DS4Windows does something InputMapper simply cannot.

The Short Answer

The maintained DS4Windows today is the ds4windowsapp project on GitHub, positioned as the official continuation of the Ryochan7 line. Its latest release is labeled v3.5, released on February 9, 2026. That GitHub repository is the download source you should use:

Get DS4Windows from the ds4windowsapp GitHub

Everything else — the original Jays2Kings program, the closed Ryochan7 repository, and random “DS4Windows” download portals — is history or a trap. The rest of this article explains why, because understanding the lineage is the only reliable protection against the fake download sites that now surround this name.

Lineage One: Jays2Kings, the Original

DS4Windows began in 2014, in the DS4Tool era, when the DualShock 4 was new and Windows games overwhelmingly expected Xbox controllers. Jays2Kings’ DS4Windows was the program that popularised the solution: read the DS4, present it to Windows as an Xbox 360 controller, and let every XInput game work with Sony’s pad.

That original line is obsolete. It has not been the living project for many years, its assumptions about drivers and Windows belong to another era, and no one should install it today. If a guide written around the Jays2Kings build is your source, treat everything in it — download links included — as out of date. Its historical importance is real; its practical usefulness is over.

Lineage Two: Ryochan7, the Long-Running Successor

For most of DS4Windows’ life, the version everyone actually used came from Ryochan7, who carried the project forward as its maintainer. That line reached its final release, version 3.3.3, on December 31, 2023. There will be no further Ryochan7 releases.

Here is the part that matters for your safety: Ryochan7’s GitHub repository now returns a 404. The canonical home of that entire era of the software is simply gone. That vacuum is exactly what fake download sites exploit. When the real source disappears, impostor pages rush in offering “the latest DS4Windows” behind ad-covered download buttons, bundled installers, and version numbers that do not correspond to any real release. A user who remembers that DS4Windows was legitimate software — because it was — reasonably trusts the name, and that trust is what these sites farm.

The rule for 2026 is simple: if a page offers you a DS4Windows installer download directly, with no connection to a GitHub releases page, close it. The genuine continuation distributes through GitHub, as the section below describes.

Lineage Three: ds4windowsapp, the Maintained Continuation

The living project is ds4windowsapp/DS4Windows on GitHub. It is positioned as the official continuation of the Ryochan7 line — the same lineage, carried on by a new home after the Ryochan7 repository closed. Its latest release, labeled v3.5 (February 9, 2026), is the version new installs should take.

For completeness, there was also a separate fork by schmaldeo, which reached version 3.9.9 in January 2025. That fork is now archived, so despite its higher version number it is not the current choice — version numbers across different forks do not form a single sequence, and a bigger number from a dead fork loses to a maintained continuation every time. If you previously installed the schmaldeo fork, moving to the ds4windowsapp release is a sensible cleanup step.

Install in the Right Order: Drivers First

DS4Windows does not work alone. Like InputMapper, it relies on the same modern driver stack — ViGEmBus for virtual controller output and HidHide for hiding the physical pad. Install in this order so each layer is ready before the next one looks for it:

1. ViGEmBus 1.22.0. Install the final ViGEmBus release first, following our ViGEmBus install guide, including the SHA-256 verification and the “run the installer twice” upgrade note. DS4Windows uses ViGEmBus output, exactly as InputMapper 1.7 does — if you already have 1.22.0 installed for InputMapper, you do not need to install it again.
2. HidHide. Install HidHide next, using the HidHide setup guide. DS4Windows also pairs with HidHide for hiding the physical controller — in the HidHide configuration, whitelist DS4Windows (instead of, or alongside, InputMapper) and hide the physical pad. This is what prevents double input in games.
3. DS4Windows itself. Download the latest release from the ds4windowsapp GitHub releases, extract it to a permanent folder (not your Downloads temp space, since the program keeps its profiles beside the executable), and run it as administrator for the first launch so it can confirm its driver dependencies.
4. Connect and verify. Connect your DualShock 4 or DualSense, confirm DS4Windows lists it, then open joy.cpl and check that the virtual controller responds to the real pad’s buttons while the hidden physical device stays invisible to non-whitelisted programs.

Why This Guide Lives on an InputMapper Site

Two reasons. The first is lineage: InputMapper and DS4Windows grew from the same 2014 moment, when DS4Tool and the first DS4Windows appeared to solve the identical problem — a brand-new Sony controller that Windows games would not talk to. InputMapper’s own history runs straight through that era, and the modern driver stack described on this site — ViGEmBus output plus HidHide hiding — is shared by both tools. If you set up one, you have essentially set up the other.

The second reason is a hard capability gap. InputMapper’s final build, 1.7.7452.13622, dates from May 2020 — before the DualSense existed. DualSense support is not in InputMapper’s official input list, and no update will ever add it, because InputMapper is discontinued. DS4Windows supports the DualSense. So for a growing share of readers, the honest advice is: keep InputMapper for the DualShock 4 workflow you know, and use DS4Windows when a DualSense is on your desk. Our DualSense on PC guide maps out what works where, and the head-to-head in InputMapper vs. DS4Windows will help you pick a daily driver.

Whichever tool you choose, the discipline is the same as everywhere on this site: downloads from the project’s real GitHub home, drivers verified before installation, and one change at a time when you test. If something misbehaves afterwards, the troubleshooting hub is a good first stop — most controller-stack problems are shared across both programs.

Frequently Asked Questions

Which DS4Windows version should I install in 2026?

Install the latest release from the ds4windowsapp GitHub repository, labeled v3.5 (February 9, 2026). The ds4windowsapp project is the maintained continuation of the Ryochan7 line. Download it from GitHub releases, not from third-party download sites.

Is Ryochan7’s DS4Windows still available?

Its final release was version 3.3.3 on December 31, 2023, and the Ryochan7 GitHub repository now returns a 404. Because the original source is gone, be especially wary of sites claiming to offer Ryochan7 downloads — that gap is what fake download sites exploit.

Does DS4Windows need ViGEmBus and HidHide?

Yes, it uses the same driver stack as InputMapper. ViGEmBus provides the virtual controller output and HidHide hides the physical controller to prevent double input. Install ViGEmBus 1.22.0 first, then HidHide, then DS4Windows.

Can DS4Windows do anything InputMapper cannot?

Yes: DualSense support. InputMapper’s final build is from May 2020, before the DualSense launched, and DualSense is not in its official input list. DS4Windows supports the DualSense, which is why many InputMapper users keep both tools installed.