Search for help with an older InputMapper install and you will quickly land on a 2016-era guide telling you to install ScpToolkit. At the time, that advice was reasonable. Today, following it blindly can leave you with an outdated driver stack, a known-vulnerable component, and conflicts with the modern tools you actually want to run. This article explains what ScpToolkit and ScpVBus were, why old guides recommend them, what the documented risks are, and how to remove the legacy stack safely and replace it with the modern one.
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.
- 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.
- Close everything controller-related. Exit InputMapper and any other mapping tools, and disconnect your controllers.
- 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.
- 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.
- 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.
- 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.