Before the causes: the SmartScreen look-alike

On a first launch, Windows may intercept the .exe with a SmartScreen prompt (“Windows protected your PC”) instead of opening the program, which reads as “won’t start.” That is Windows being cautious about a program without a commercial signature, not a crash: choose More info → Run anyway and the program opens normally — provided your copy is the verified package, which is the whole point of checking the hash published alongside it. SmartScreen only explains a first-launch block, though. If the program previously ran on this machine and now fails, skip ahead: something in its stack changed, and the causes below are where to look.

Cause 1: The dialog names .NET, but the fix is ViGEmBus (#578)

It confuses everyone the first time: the crash popup says “Microsoft .NET Framework,” yet in issue #578 the recorded remedy was to remove and reinstall ViGEmBus. The dialog title names the framework that reported the exception, not the component that failed — when BetterJoy starts, it initialises its virtual-controller layer, and a broken ViGEmBus install surfaces as exactly this unhandled-exception dialog. So: uninstall ViGEmBus (Settings → Apps), reboot, install the current 1.22.0 from the link on our download page, reboot again, and relaunch. Our ViGEmBus not found guide covers the full repair, including the Device Manager check.

Cause 2: A config file your Windows locale can’t read — updating is the fix

BetterJoy v7.1 exists for one reason. Its entire official changelog is a single fix: config reading did not work when the Windows locale uses a comma as the decimal separator — which is most of Europe and much of the world. If you are on v7.0 or earlier with such a locale, and the program crashes or misbehaves around reading its BetterJoyForCemu.exe.config, you do not have a mystery bug; you have the exact defect the hotfix repaired. Updating to v7.1 is the fix. Our update guide covers moving up without losing your settings.

Cause 3: A corrupted or badly edited config — restore a fresh one

Hand-editing the .exe.config is part of normal BetterJoy life (calibration values, legacy toggles), and a malformed edit can leave the program unable to parse the file at startup. The clean recovery:

1. Close BetterJoy fully (check the system tray).
2. Rename your current BetterJoyForCemu.exe.config to something like .config.bak — don’t delete it; your settings live there.
3. Extract a fresh, untouched .exe.config from the original v7.1 ZIP into the program folder.
4. Launch. If the program starts, re-apply your edits one at a time, launching after each, until the bad edit reveals itself.
5. If it still won’t start with a pristine config, the config was never the problem — move on to Cause 4.

The config file guide explains what each documented setting does, so your re-applied edits are deliberate ones.

Cause 4: Driver conflicts and leftovers — isolate them

BetterJoy sits on a small stack of drivers, and conflicts there surface as startup failures rather than neat errors. Isolate them in this order:

• Two hiding layers: if you ever installed both the bundled HIDGuardian and the modern HidHide, they are documented as mutually exclusive — the author’s own guide says they must not be on the same system. Pick one stack and remove the other properly (ordered removal in our HIDGuardian recovery guide).
• An instance already running: since v6.3 the program refuses to open a second copy. An old instance minimised to the tray makes a fresh double-click look like a crash. Check the tray and Task Manager before diagnosing anything else.
• A damaged program folder: extract the ZIP to a new folder in a normal user location (not a protected directory — see the settings-path problem in the not-detected guide) and run from there. If the fresh copy starts, your old folder was the fault.
• Security software: check your antivirus quarantine for the .exe or its DLLs before assuming corruption, and only restore files from the verified package.

If none of the four causes fits, capture the exact dialog text — the exception dialog’s details are what the project’s issue tracker needs, and the quoted error string is usually how a maintainer recognises the case. All other startup-adjacent fixes are indexed on the troubleshooting hub.

FAQ

Does BetterJoy need a specific .NET version installed?

The official documentation does not state a runtime version requirement, and we won’t invent one. What is documented is the behaviour above: the “.NET Framework” dialog is the messenger, and its recorded triggers are the ViGEmBus install state (#578) and config reading (v7.1’s locale fix). Fix those before touching .NET itself.

It crashes only when I connect the controller, not at launch. Same page?

Related, but start with the ViGEmBus guide — virtual controllers are created at connection time, so a bus problem can wait until then to surface — then check for the two-hiding-layers conflict in Cause 4.

Will reinstalling BetterJoy delete my remappings?

Your settings live in BetterJoyForCemu.exe.config in the program folder. Back that file up before any reinstall or folder move and your configuration survives; the update guide explains the full preserve-your-settings routine.

The shape of the problem (#1222)

The most recent report is the cleanest: on Windows 11, the PC recognised a PowerA controller while BetterJoy did not list it at all. That split — Windows yes, BetterJoy no — is the signature of this issue and separates it from pairing trouble. If Windows cannot see your controller either, you have a different problem; start with the not-detected guide instead. What follows assumes Windows sees the pad fine.

Why third-party pads are a hard case

BetterJoy was written against Nintendo’s own hardware. It finds controllers by how they present themselves over Bluetooth — their identifiers and behaviour — and third-party manufacturers imitate that presentation to varying degrees: different Bluetooth identifiers and MAC addresses, different polling behaviour, differently scaled sensors. Version 7’s release notes are candid that third-party support “is not perfect,” and the support that exists flows through one feature: the Add Controllers button.

There is a naming problem underneath the identifier problem. Nintendo’s pads announce themselves to Windows in the standard forms BetterJoy was built to expect, while third-party pads announce vendor-specific names and device IDs that vary not just between brands but between models from the same brand in the same year. A detection routine can only match what it knows or is taught — which is why one PowerA model can appear in BetterJoy while its near-identical sibling never does, and why outcomes in the tracker are resolutely model-by-model rather than brand-wide. Keep that in mind while running the checklist: you are testing your specific unit, not the logo on it.

The checklist: what is actually worth trying

1. Confirm the pad works as a generic controller first. Open joy.cpl and check that buttons and sticks respond there. If a pad works in joy.cpl but not in BetterJoy, at least you know the hardware and the pairing are sound.
2. Run the Add Controllers flow properly. With the controller connected to Windows, start BetterJoy and use the Add Controllers button — our third-party controllers tutorial walks the full flow, including what the button can and cannot teach the program about a new device.
3. Try USB as well as Bluetooth. Some pads present differently wired than wireless; a model invisible over Bluetooth occasionally registers over a cable (and vice versa). Ten minutes, worth ruling out.
4. If it registers but the gyro or sticks feel wrong, calibrate. The v7 feature set includes config-file calibration for third-party pads — the acc_sensiti / gyr_sensiti values in BetterJoyForCemu.exe.config exist for exactly the “recognised but misbehaving” case. Recognised-but-weird is fixable; never-recognised is usually not.
5. Search the tracker for your exact model. With six-plus PowerA threads alone, someone may have posted a model-specific outcome — success or confirmed failure — that saves you an evening.

The honest bottom line on PowerA

Across those years of reports, many PowerA models have simply never been recognised by BetterJoy, and there is no configuration file edit that changes a device’s Bluetooth identity into one the program accepts. (A stronger claim circulates in community posts — that the maintainer confirmed PowerA is unsupported outright — but it is not something we can quote verbatim from a primary source, so we will not print it as fact. The pattern of reports speaks plainly enough on its own.) If you have run the checklist, the rational conclusion is that your model is in the not-recognised group, and your options are: use the pad where it works natively (many third-party pads behave as standard controllers in Steam and in games with their own input support), use it on the console it was built for, or use a genuine Nintendo pad — or a clone with a confirmed success report — for your BetterJoy setup. There are no affiliate links in that advice; it is the same answer the tracker gives, minus the years of scrolling. One adjacent trap: if a pad is recognised but then appears twice in a game, that’s not this issue — it’s double input, and it has a clean fix. The program itself is on the download page, and all the neighbouring fixes are gathered on the troubleshooting hub.

FAQ

My PowerA worked with an older BetterJoy. Did support get removed?

Not deliberately, as far as the record shows — but recognition depends on the specific model’s behaviour, and Windows Bluetooth stack updates over the years have changed how some pads present themselves. Re-run the Add Controllers flow on the current version and check the tracker for your model before assuming a regression.

Will the maintained BetterJoy fork recognise my PowerA?

The community fork’s documented additions are newer hardware families (such as NES/N64-style controllers) and a modernised driver stack — we have no verified source promising PowerA recognition, so we won’t claim it. If you try the fork, treat it as an experiment, not a fix.

Is there a list of third-party models that do work?

There is no official compatibility list — that absence is part of the problem. The practical substitute is the issue tracker itself: model-specific threads with confirmed outcomes, which is why step 5 of the checklist points you there.

What the notification and the colour change mean

BetterJoy reads the battery level your controller reports and does two things with it: it can raise a low battery notification (the feature was added as a headline item in v6.4b), and it changes the background colour of the controller’s icon in the BetterJoy window as a running battery indicator (present since v6). So the first check is free: glance at the icon colour before reacting to a popup. If the colour says healthy and the popups keep coming anyway, you are not looking at a battery problem — you are looking at one of the glitches below. One caveat: Bluetooth battery reporting from game controllers is coarse, often a handful of rough levels rather than a true percentage, so treat “low” as “charge soon,” not a precise measurement.

Glitch 1: Notification spam that survives the game (#898)

In issue #898, after the user closed their emulator, BetterJoy kept firing low battery notifications continuously — the only thing that stopped them was restarting. If your spam outlives the session that triggered it, do exactly that: close BetterJoy completely (check the system tray, not just the window) and relaunch it; if the notifications persist, reboot. This pattern is a stuck notification state, not new information about your battery arriving every few seconds, and no setting change is needed once it clears.

Glitch 2: A popup on every button press, and input stops reaching the emulator (#973)

Issue #973 is the stranger variant: inside the emulator, every button press raised a low battery notification, and the controller’s input did not reach the game. The workaround that reporter confirmed — on Windows 11, incidentally, which is useful evidence the combination works there — was to change the legacy UseHIDG value in BetterJoyForCemu.exe.config (the toggle for the bundled HIDGuardian hiding layer) and to follow a specific start order: launch BetterJoy and let it settle before starting the emulator. Two cautions before you copy it: write down the original value first, and treat it as a targeted workaround for this exact symptom, not a general tweak — our config file guide documents UseHIDG as a legacy, troubleshooting-only switch for precisely this reason. If your input is being swallowed more generally, the not-detected guide and the gyro/DSU checks cover the neighbouring causes.

Charging while you play

If the battery really is low, you have a clean option with the Pro Controller: play over USB. A USB-C cable carries data and charge at the same time, so a wired session tops the battery up instead of draining it — and as a bonus you remove Bluetooth from the equation entirely. Joy-Cons are less flexible: they do not charge while you are playing with them detached; they charge when attached to the console or a charging grip, so a genuinely flat Joy-Con means a charging break or swapping to the other pair. Community practice for long sessions is simple — start charged, and treat the first honest notification as your cue to plug in rather than a countdown to argue with.

Reducing false triggers

• Fully charge, then test: a controller charged to full that still triggers immediate “low battery” popups is reporting badly or hitting a glitch — that contrast is your diagnostic.
• Restart BetterJoy after emulator sessions rather than leaving it resident for days; the #898 spam state builds across sessions.
• Re-pair if readings stay implausible: remove and re-pair the controller in Windows Bluetooth settings so the battery reporting channel is renegotiated.
• Keep the layers straight: if the popup-per-press pattern matches #973, apply that workaround deliberately (above) instead of stacking random changes.

One more readout worth trusting over any single popup: after a full charge and a fresh pairing, watch the icon colour through a session. A colour that steps down gradually is the feature working as designed; a colour that claims “low” within minutes of a full charge is the reporting glitch again, and the re-pair in the list above is the fix to repeat — not another charge.

The notification feature working correctly is worth having — a controller dying mid-session without warning is worse. Get a clean copy of the program from the download page if your build predates the feature’s fixes, and find related fixes on the troubleshooting hub.

FAQ

Can I turn the low battery notification off?

There is no prominently documented on/off switch for it in the program’s official documentation, and we won’t invent one. The realistic controls are the ones above: keep the battery genuinely charged, restart the program to clear the stuck state (#898), or apply the #973 workaround when the popup-per-press pattern matches.

The popup says low battery but the Switch shows plenty of charge. Who is right?

Probably the Switch. Bluetooth battery reports to Windows are coarse and can go stale, especially across sleep and re-pairing. Charge fully, re-pair, and judge by the icon colour plus a fresh session rather than a single popup.

Is the notification spam a sign of malware or a broken controller?

No — both documented spam patterns (#898 and #973) are BetterJoy-side states with named workarounds, on otherwise healthy controllers. If spam survives a reboot with BetterJoy closed, look elsewhere; with BetterJoy open, you are in the territory this page covers.

Why BetterJoy hides your controller in the first place

HIDGuardian is the legacy hiding layer bundled with BetterJoy v7.1. Its job is legitimate: it stops games from seeing the physical controller alongside BetterJoy’s virtual one (the double input problem). The side effect is persistence — the hiding outlives the session. If you close BetterJoy, uninstall things in the wrong order, or the service stops unexpectedly, the controller can stay hidden (“affected”) with no obvious way back. The warning from the project’s documentation ecosystem is worth repeating up front: uninstalling HIDGuardian must follow the official order — removing driver files directly can break more than the controller, in the worst accounts extending to keyboard and mouse input.

The recovery: release the device at localhost:26762

1. Make sure the HidCerberus service is running — it is installed alongside HIDGuardian in the Drivers\HIDGuardian folder of the BetterJoy package. If you removed the service already, reinstall the package’s HIDGuardian component temporarily; you cannot release devices through a UI that no longer exists.
2. Open your browser and go to http://localhost:26762/ — this is the local HidCerberus control page served on your own machine, not a website.
3. Find the Currently affected devices list.
4. Remove every device from that list. The wiki’s instruction is explicit: all of them, not just the controller you are missing.
5. Restart your PC. The release takes effect on reboot.
6. After the restart, pair or plug in the controller and confirm it appears in joy.cpl and in your other programs again.

Related log lines you may have seen in BetterJoy’s console — HidGuardian was stopped. Starting..., Unable to start HidGuardian..., Unable to purge whitelist. — all belong to this layer misbehaving, and this recovery is the documented exit from that state.

Uninstalling HIDGuardian for good — in the safe order

If you are moving to the modern HidHide setup (recommended in our double input fix) or leaving BetterJoy entirely:

1. Release all affected devices at localhost:26762 first (steps above) and reboot once.
2. Then uninstall the driver using the package’s own “HIDGuardian Uninstall (Run as Admin).bat” in the same Drivers\HIDGuardian folder — that script exists precisely so you don’t hand-delete system driver files.
3. Reboot again, and verify the controller behaves normally with no hiding layer at all before installing anything new.

Skipping step 1 is the classic mistake: uninstall the layer while a device is still affected and the device has no manager left to release it.

If you no longer have the BetterJoy folder

A common dead end: you deleted the program folder weeks ago — taking the Drivers\HIDGuardian folder and its install/uninstall scripts with it — and the controller is still hidden. The recovery tools live in that folder, so get them back: download a fresh copy of the package from the download page, extract it anywhere convenient, and run the HIDGuardian install script once, as administrator, then reboot. That restores the HidCerberus service so the localhost:26762 page loads again. From there, follow the release steps above, then the ordered uninstall. Installing the layer again feels backwards when your goal is to remove it, but the release list is managed by that service — without it, there is nothing left that can free the device, and hand-deleting files in this state is how the situation gets worse.

Prevention: make BetterJoy clean up when it closes

Version 6 added a config option to remove affected devices when the application shuts down, with the release notes stating the intent plainly: it “should prevent any more issues of the controller being unusable after the program.” If you keep using the legacy layer, enable that shutdown cleanup so a normal exit leaves your controller usable by everything else — our config file guide explains where these legacy toggles live and why you should record original values before touching them. Also make a habit of closing BetterJoy normally rather than killing it in Task Manager; a killed process never runs its cleanup. If your controller instead is visible to Windows but BetterJoy itself won’t list it, that’s the mirror-image problem — work through the not-detected guide. The update guide also covers this recovery as part of old-driver cleanup when moving between versions.

FAQ

Is localhost:26762 safe? It looks like a random website.

It is a page served by the HidCerberus service on your own computer (localhost means “this machine”). Nothing is uploaded anywhere. It only exists while that service is installed and running.

The 26762 page won’t load. What now?

The HidCerberus service is not running — usually because it was uninstalled or disabled. Reinstall the HIDGuardian component from the BetterJoy package’s Drivers folder, reboot, and try the page again; then do the release and the ordered uninstall above.

Can I just switch to HidHide and skip all this?

Eventually, yes — HidHide is HIDGuardian’s maintained successor. But the release step is not skippable: a device still affected by HIDGuardian must be freed first, and the two drivers must never be installed at the same time. Free the device, uninstall in order, then set up HidHide. All related fixes are gathered on the troubleshooting hub.

Why this exception appears

BetterJoy talks to ViGEmBus through its client library (Nefarius.ViGEm.Client.dll, in the program folder) when it starts and when it creates virtual controllers. The not-found exception is the library reporting that the bus driver itself is not present and running on the system. In practice that means one of four things: ViGEmBus was never installed (easy to do if you ran the .exe straight from the ZIP), the installer was interrupted, an older install is broken, or the machine was never rebooted after installing. Issue #578 — the startup crash dialog titled “Microsoft .NET Framework” — carries the same moral, and its thread title literally annotates the fix: remove and reinstall ViGEmBus.

The repair, step by step

1. Get the current driver from a trustworthy source. Our download page links the official nefarius release. The current and final version is ViGEmBus 1.22.0; the project has been retired and archived by its author, which means 1.22.0 is the version to standardise on — and a strong reason to avoid random “driver updater” sites offering their own repacks.
2. Remove the old install first if one exists. Settings → Apps → find the ViGEmBus entry → uninstall. If your only copy is the old MSI bundled inside the BetterJoy v7.1 ZIP (a 1.16-era driver), a standalone 1.22.0 install over the top usually works — the 1.22.0 release notes even describe running the installer twice to complete an in-place upgrade — but a clean remove-then-install removes doubt.
3. Run the installer as a normal install and let it finish; do not interrupt it when the screen pauses.
4. Reboot. This step is not optional. Bus drivers load at boot. The #194 pattern — everything installed, nothing detected — is what skipping the reboot looks like.
5. Start BetterJoy again and connect a controller. The exception should be gone; confirm the virtual controller appears in joy.cpl.

Check Device Manager if it still fails

As community practice, verify the driver is actually present: open Device Manager and look under System devices for the Nefarius Virtual Gamepad Emulation Bus entry. If it is missing entirely, the install did not take — repeat the install step and watch for errors. If it shows a warning icon, uninstall the device from Device Manager, reboot, and install 1.22.0 fresh.

One installer for every Windows PC

One less thing to get wrong: the final ViGEmBus release ships as a single installer covering x64, x86 and ARM64 (ViGEmBus_1.22.0_x64_x86_arm64.exe), with Windows 10 and 11 as its supported systems — you do not need to hunt for a per-architecture build the way the old MSI pair inside the BetterJoy ZIP (separate x64 and x86 files) required. If your repair attempt involved a file named like a per-version “setup” from a driver-download site rather than that single official asset, discard it and start the repair over with the real one; mismatched repacks are a recurring cause of “installed but still not found.”

The antivirus quarantine case

Driver installers occasionally get quarantined by security software because they load kernel components — check your antivirus history if the installer “completed” but the Device Manager entry never appeared. Restore the file only when it is the genuine installer you downloaded from the official release, and consider adding the installer to your AV’s allowlist for the reinstall. Never fix this by downloading the driver from a different, less accountable site; with a retired project, the official GitHub release is the only source we recommend.

What this error is not

It is not your controller, your Bluetooth, or your emulator. It also is not fixed by reinstalling BetterJoy itself — the program is fine; its foundation is missing. If the exception appears only after you removed a “unused driver” with a cleanup tool, that tool deleted ViGEmBus, and the same repair applies. Once the bus is back, work through the not-detected guide if a controller still does not appear, or the startup crash guide if the program itself still will not open. More fixes are indexed on the troubleshooting hub, and the correct first-run order is in the install guide.

FAQ

BetterJoy’s ZIP already includes a ViGEmBus installer. Why install 1.22.0 separately?

The bundled installer is an old 1.16-era build that has worked for many users, but it predates the final driver by years. If you hit the not-found exception, moving to the maintained-final 1.22.0 removes the old build as a variable.

ViGEmBus is “retired.” Is it still safe and usable?

Retired means no future updates, not broken: 1.22.0 remains the widely used final release on Windows 10 and 11. The practical caution from the author’s end-of-life notes is about the old auto-updater phoning a retired domain — another reason to install 1.22.0 (which removed the updater) rather than an ancient version.

The exception appears when I connect the controller, not at startup. Same fix?

Yes. The client library also touches the bus when a virtual controller is created, so a partially installed driver can survive until first use. Run the same remove–install–reboot repair.

Check 1: Your Intel Bluetooth driver version

This is the rare lag fix with an exact number attached. In issue #731, a lagging secondary Joy-Con on Dolphin was fixed by updating the Intel Bluetooth driver from Intel’s website — the threshold in that report was a driver older than 22.180.0. Windows Update routinely serves older Bluetooth drivers than Intel’s own download center, so “my drivers are up to date” inside Windows often isn’t. If your PC uses Intel wireless (most laptops and many motherboard modules do), download the current Bluetooth driver package from Intel directly, install, reboot, and retest before buying anything.

Check 2: Which controller lags — and the author’s blunt diagnosis

Issue #571 describes the classic shape of this problem: with two Bluetooth controllers, the one that synced first carried almost a second of delay. The author’s reply was blunt — “joycons natively don’t like Intel drivers/BT adapters” — and in the same discussion, a user solved their setup with an Asus USB-BT400 USB adapter. Two lessons: the chipset and driver stack matter more than the Bluetooth version number printed on the box, and “the first-paired controller lags” is a known pattern, not something you imagined. A quick diagnostic: disconnect both controllers, pair only the lagging one, and play. If it is fine alone, your adapter or driver is struggling with multiple connections — exactly the wiki’s 3–4 connection warning — and no BetterJoy setting will change that.

Check 3: Rumble load on the same link

Rumble data travels over the same Bluetooth connection as your inputs and motion samples, and heavy rumble makes everything else queue behind it. The pattern is documented: in issue #616 the console errors began after about 20 minutes with rumble enabled, while rumble-off sessions ran for hours (see our duplicate timestamp guide). The practical fix costs nothing: reduce rumble intensity in your emulator — the long-standing guidance for Cemu is around 70–80% — and see whether the lag follows the rumble setting. Older BetterJoy versions also carried a genuine rumble-lag bug fixed in v6.1, so if you are on an ancient build, updating comes first.

Check 4: Adapter placement and interference (community practice)

These steps are standard Bluetooth troubleshooting rather than BetterJoy-specific documentation, and they fix a surprising share of cases:

• Move the adapter (or your PC) so the controller has line-of-sight within a couple of metres; a rear motherboard antenna behind a metal case is the worst common setup.
• If you use a USB Bluetooth dongle, put it on a front port or a short USB extension cable — away from USB 3.0 hubs and external drives, which are known to radiate interference in the 2.4 GHz band.
• Disconnect other Bluetooth devices (headphones, phones, a second pair of Joy-Cons) for one test session to see if the lag is contention.
• For a Joy-Con pair, make sure both were paired separately and appear individually in BetterJoy before joining them, per the Joy-Con connection guide.

When a dedicated USB Bluetooth adapter is the real fix

If the Intel driver is current, rumble is tamed, placement is good, and a pair of Joy-Cons still lags while a single controller is fine, you have hit the adapter’s connection ceiling. That is a hardware limit, and the honest fix is a decent dedicated USB Bluetooth adapter — the BT400 is simply the model named in the project’s own issue thread; treat it as an example of the class, not a magic part number. Buy for a reputable chipset and current drivers, keep your motherboard Bluetooth disabled while testing so Windows uses one stack, and buy from somewhere with returns: Bluetooth behaviour varies enough by PC that no adapter is a guaranteed cure. (Our buying guides cover adapter picks separately — this page deliberately keeps the diagnosis tool-agnostic.)

If lag survives a known-good adapter too, the problem has moved — re-check the detection guide and the troubleshooting hub, and grab a clean copy of the program from the download page if your install predates v6.1’s rumble fixes.

FAQ

Is a Bluetooth 5.0 or 5.3 adapter automatically better than 4.0?

Not automatically. The documented failures are about chipset and driver quality and how the stack handles several simultaneous game controllers — which is why a well-supported 4.0 dongle appears in the project’s issue thread as the fix. Judge by chipset reputation and driver currency, not the version badge.

My Pro Controller lags too, on USB it doesn’t. Same fix?

Yes — USB removes the radio from the equation, so lag that exists only on Bluetooth lives in the adapter/driver/placement layer. Work through Checks 1, 3 and 4 in that order.

Does BetterJoy add input delay itself?

BetterJoy’s translation layer is not the documented cause in any of the reports behind this page; the identified causes are the Intel driver threshold, multi-connection load, and rumble traffic. Keep the program updated so you are not fighting the pre-v6.1 rumble bug, and measure after each single change.

Related buying guides: if your lag survives every fix on this page, the radio itself is the remaining suspect — our Bluetooth adapters for Switch controllers on PC guide covers what to replace it with, and when no adapter is needed at all.

How the pieces connect (so the checks make sense)

In the BetterJoy setup, buttons reach Cemu through the virtual XInput controller, while motion travels separately: BetterJoy runs a Cemuhook/DSU server on your PC, and Cemu connects to it as a client. Two independent paths means gyro can fail while buttons work perfectly — and the fix is almost always in the motion path: the server, the address, or the slot.

Check 1: The server is running, at the right address

Start BetterJoy with your controller connected and look at its console: you should see the server start line, Starting server on 127.0.0.1:26760. The defaults from the project’s wiki are serverIP = 127.0.0.1 and serverPort = 26760. In Cemu’s DSU client settings, the server address must match exactly — 127.0.0.1, port 26760. A single wrong digit in the port is the most common silent failure, because Cemu does not complain; it simply shows no motion device. If the console never shows the server starting, fix detection first with our controller not detected guide.

Check 2: The right slot under GamePad motion source

The DSU server exposes controller slots, and Cemu’s GamePad motion source must point at the slot your controller actually occupies — the #671 symptom was a Pro Controller present everywhere except there. In Cemu’s input settings, open the motion source dropdown and select the DSU controller entry rather than leaving it on a default or empty slot. With Joy-Cons joined in BetterJoy, remember they present as one controller: pick that combined entry. If the dropdown is entirely empty, Cemu is not reaching the server at all — go back to Check 1, and type the address by hand instead of trusting a remembered value.

A related slot trap catches two-controller households: each physical controller occupies its own DSU slot, so a second player’s profile pointing at slot 1 gives them buttons with no motion while player one works perfectly. If motion fails for exactly one of two pads, compare the motion-source slot in each profile before changing anything else — it is a thirty-second check that looks, from the player’s seat, identical to a dead gyro.

Check 3: The wiki’s motion reset and calibration basics

The project’s FAQ entry for “motion controls don’t work / work badly” gives a disarmingly simple fix: turn the controller off and back on while everything is running — hold Home or Capture for 2 seconds to disconnect, then press a button to reconnect. Do this with Cemu open and the DSU client configured, so the motion stream renegotiates cleanly. The same wiki section’s calibration advice applies if motion works but feels wrong: in Cemu’s input profile, turn off “Also use for buttons/axes” for the motion source and set the deadzone to 0; both settings distort gyro input when left on. If aiming works but pointing the controller fills BetterJoy’s console with Duplicate timestamp enqueued, that is a separate queue problem covered in its own guide.

Check 4: When the config itself is the problem

In #671, after the standard checks, the resolution was a complete reinstall of Cemu — the emulator’s own configuration had become the fault. Before you go that far, back up your Cemu folder, and treat reinstall as the last step, not the first. The lesson of that thread is the ordering: port and slot first (five minutes), emulator reinstall last.

The honest alternative: Cemu’s native SDL motion

Cemu 2.x can read Switch controller motion natively: in Input Settings, choose the SDLController API for your Pro Controller and tick Use motion — no BetterJoy, no DSU server. Current community guidance treats this as the first thing to try for Cemu-only play, and if it works for your setup, it is the simpler stack. The BetterJoy route still earns its place when the SDL path misbehaves on your system, when you want one setup that also feeds other emulators, or when you specifically need dual Joy-Con motion with your choice of which hand supplies the gyro — the case the Ryujinx family’s own README still names BetterJoy (or DS4Windows) as required. If you are setting up from scratch, our gyro guide explains the three gyro modes (DSU server, gyro-to-mouse, gyro-to-stick) and when each fits; the program itself is on the download page, and more fixes are indexed on the troubleshooting hub.

FAQ

Buttons work but there is no motion tab option at all. Why?

Your input profile is probably using XInput only. Motion arrives through the DSU client, which must be configured separately with the 127.0.0.1:26760 server — the two paths are independent by design.

Motion works in the Cemu settings preview but not in game. What now?

Check that the game’s controller profile actually assigns the motion source — profiles are per-game in Cemu. Also verify “Also use for buttons/axes” is off and the deadzone is 0, per Check 3.

Should I just switch to SDL motion permanently?

If you only play Cemu and SDL motion works with your controller, yes — fewer moving parts. Keep the BetterJoy route in mind for multi-emulator setups and dual Joy-Con motion, where it remains the documented path.

Step 0: Confirm it is double input, not drift

Open joy.cpl (press Win+R, type joy.cpl) with BetterJoy running. If you see both the real controller and an Xbox 360/DS4 entry, and both respond to the same stick, you have double exposure. If only the virtual controller responds oddly, your problem is elsewhere — check the troubleshooting hub instead of changing drivers.

The quick fixes (try these first)

• In Steam games: pick one master. Either let Steam Input handle the physical controller with BetterJoy closed, or use BetterJoy’s virtual controller and disable Steam Input for that game (right-click the game → Properties → Controller → Disable Steam Input). Steam reading the raw pad while BetterJoy also feeds it is the #455 scenario.
• For gyro-only use: BetterJoy can run only its motion server. Turn off XInput emulation in BetterJoy and let your emulator take buttons from its native input while motion arrives over the DSU connection — with no virtual gamepad created, there is nothing to double.
• In emulators: assign the input profile to the virtual XInput device only, and clear any profile bound to the physical controller.

If a game has no such settings — many non-Steam games don’t — you need the real fix: make the physical controller invisible to everything except BetterJoy.

The modern fix: hide the physical controller with HidHide

HidHide (by nefarius, current version 1.5.230) is the maintained tool for exactly this job: it hides selected HID devices from all applications except the ones you whitelist. It is a separate download from the same author’s project pages — it is not part of the BetterJoy v7.1 package on our download page, which still bundles the older HIDGuardian instead.

1. Remove HIDGuardian first if you ever installed it (see the warning below), then reboot.
2. Install HidHide and reboot when asked.
3. Open the HidHide Configuration Client. On the Applications tab, add BetterJoyForCemu.exe — this whitelists BetterJoy so it can still see the physical controller.
4. On the Devices tab, tick your Switch Pro Controller or Joy-Cons.
5. Tick Enable device hiding at the bottom.
6. Restart BetterJoy and check joy.cpl again: only the virtual controller should respond in games now, while BetterJoy still lists the real one.

This is the same approach the community converged on in #1009: hide the native device, keep only the XInput output.

The hard rule: HidHide and HIDGuardian must never coexist

Nefarius’s own setup guide states it in capitals: HidHide and HidGuardian MUST NOT be together on the same system. HIDGuardian is the 2016–2018 research driver that BetterJoy v7.1 installs from its Drivers\HIDGuardian folder; it has been discontinued, and HidHide is its direct successor. If your double-input fix “made things worse” or the controller vanished entirely, a leftover HIDGuardian is the prime suspect. Removal has a safe order — release the devices from the blacklist first, then uninstall, then reboot — and our HIDGuardian recovery guide walks through it. Never delete driver files by hand; mishandled removal is how people end up with a controller no program can see.

Side effects to expect

While hiding is enabled, non-whitelisted programs will not see the physical controller at all — that is the point, but it surprises people when the pad “disappears” from another emulator or from Steam. Whitelist only the programs that should see the raw controller (BetterJoy itself); whitelisting a game defeats the fix for that game. If instead the console starts filling with Duplicate timestamp enqueued, that is the related two-readers problem on the motion side — see our guide to that message. And if you later touch the legacy toggles mentioned in the config file guide (UseHIDG, PurgeWhitelist), note your original values first: they belong to the old HIDGuardian era and interact with everything on this page.

Keeping the fix in place

Two habits keep double input from creeping back. First, after any HidHide update or reinstall, re-open the Configuration Client and confirm your device is still ticked and hiding is still enabled — updates can reset the list, and the symptom returns silently. Second, when you deliberately un-tick device hiding (say, to use the pad somewhere that needs the raw controller), remember that every game can see both devices again from that moment; re-enable hiding before your next BetterJoy session rather than debugging the same drift a second time.

FAQ

Why doesn’t BetterJoy hide the controller automatically?

Version 7.1 was built when HIDGuardian was the standard layer, and it does use that layer when installed — but HIDGuardian is discontinued and conflicts with modern HidHide installs, which is why the maintained route today is the separate HidHide setup described above.

Does hiding affect Bluetooth pairing?

No. Pairing happens at the Windows Bluetooth level, below where HidHide works. The controller still connects normally; it is only hidden from applications that are not whitelisted.

Can I hide the controller for one game but not others?

HidHide’s hiding is system-wide once enabled — the whitelist is per-application for who may see the device. For a single Steam title, the per-game Steam Input toggle is the finer tool; use HidHide when several programs need the same treatment.

What the message means

BetterJoy streams motion data from your controller to emulators through its built-in Cemuhook/DSU server. Each motion sample carries a timestamp, and samples are queued in order. When a sample arrives whose timestamp is already in the queue, BetterJoy drops it and logs Duplicate timestamp enqueued. An occasional dropped sample is invisible in gameplay. The problem is the flood: when something downstream keeps requesting or reading data in a way that generates duplicates continuously, the log scrolls non-stop and, in the worst reports, real input stops getting through.

The author’s root cause: the emulator is reading the wrong input API

The clearest explanation on record comes from issue #336, where the message spammed the log after launching an emulator and the controller stopped working. The author (Davidobot) replied that the root cause was the emulator reading the controller through DirectInput instead of XInput — the emulator was seeing the raw controller alongside BetterJoy’s virtual one, and the fix in that thread was to install the HIDGuardian driver layer and enable it, so only the XInput device remained visible.

Translated into steps for your setup:

1. In your emulator’s input settings, set the controller API to XInput (not DirectInput) for the virtual controller BetterJoy creates.
2. Make sure the game is not also reading the physical controller directly. If it can see both devices, you have the classic double-exposure setup — our double input fix explains how to hide the physical controller properly with HidHide.
3. Restart both the emulator and BetterJoy after changing the API; the queue state does not reset mid-session.

Scenario 2: It starts after about 20 minutes, with rumble on

Issue #616 describes a different pattern: the message appears after roughly 20 minutes of play with rumble enabled, while turning rumble off lets the same user play for hours. If your flood is time-delayed rather than instant, treat rumble as the trigger: lower the rumble intensity in your emulator (the long-standing community guidance for Cemu is around 70–80%), or disable rumble for a session to confirm the pattern before changing anything else. Rumble traffic shares the same Bluetooth link as the motion stream, which is also why rumble shows up in several of our Bluetooth lag checks.

Scenario 3: It floods when a streaming or capture tool joins

The earliest detailed report, issue #292, involved Parsec: the log flooded and the user had to disconnect the Pro Controller to stop it. Streaming and remote-play tools hook controllers in their own way and can recreate the same “two readers” conflict as the DirectInput case. If your flood starts exactly when a streaming, capture, or remapping tool launches, close that tool, confirm the log goes quiet, then reintroduce it — and make sure it is not also exposing the physical controller as a second device.

One honest boundary: in issue #387 the message recurred on v6.3 even with the config’s legacy PurgeWhitelist option changed, alongside stray Windows shortcut presses. Not every instance has a clean user-side fix, and the later stages of that thread are workarounds rather than a patch. If you have eliminated the wrong-API cause and the rumble pattern, say so plainly in a new issue report — you are past what configuration can solve.

When you can safely ignore it

If the line appears occasionally in the console while your controller responds normally — in a menu, during a loading screen, once in a while mid-game — it is the queue doing its job and dropping a redundant sample. It needs no action. Act only when it is continuous, when it coincides with input loss, or when it arrives with a pattern (a specific emulator, rumble, a streaming tool) you can match to the scenarios above.

New to the program itself? Start with the first-run guide and the package on the download page so your baseline setup is known-good, then come back here if the message appears. More fixes live on the troubleshooting hub.

If you end up reporting it

Should you take this to the issue tracker, report it the way the useful threads in the archive do: quote the exact message, name the emulator and which input API it was set to (XInput or DirectInput), state whether rumble was on, and note when in the session the flood starts — immediately, or after a delay like the ~20 minutes in #616. Those four facts are what separate your report from the dozens of unactionable ones, and they are the same four facts the fixes on this page are organised around.

FAQ

Is “Duplicate timestamp enqueued” an error that damages anything?

No. It is a log message about a dropped motion sample. It does not corrupt your controller, your config, or your saves. Only its continuous form matters, because of the input problems that travel with it.

The fix mentions HIDGuardian. Should I install it?

HIDGuardian is the legacy layer bundled with v7.1, and it was the era-correct answer in the author’s thread. Today the maintained hiding tool is HidHide, and the two must never be installed together. Our double input fix walks through the modern route and the removal order for the old one.

It only happens in one emulator. Is BetterJoy broken?

Almost certainly not — a single-emulator pattern points at that emulator’s input API setting (DirectInput vs XInput) or its DSU client configuration, which is exactly the author’s diagnosis in #336.

Step 1: Read what the console is actually telling you

Launch BetterJoyForCemu.exe and look at the log lines. In issue #358, a user whose Pro Controller was never detected saw only two lines: Starting server on 127.0.0.1:26760 and All systems go. That pattern tells you something useful: the program itself started fine — its motion server is running — but it never enumerated a controller. The problem is between Windows and the controller, not inside your emulator. If instead you see errors about drivers, jump to our ViGEmBus not found fix, because a missing virtual bus produces a different failure.

Step 2: Remove the pairing and re-pair the proper way

Stale pairings are the classic cause. The official wiki’s fix for No Joycons detected is to reconnect following the proper disconnect procedure, and in practice a full remove-and-repair is the version of that advice that works:

1. Close BetterJoy completely.
2. In Windows, open Settings → Bluetooth & devices, find the controller, and choose Remove device.
3. Hold the controller’s Home or Capture button for about 2 seconds (or tap the Sync button) so it fully disconnects — this is the documented disconnect method, and skipping it is how half-paired states happen.
4. Hold the small Sync button on top of the controller for about 5 seconds until the lights start cycling.
5. Add it again under Add device → Bluetooth, wait until Windows says the device is ready, and only then start BetterJoy.

If you need the button-by-button pairing flow, our Pro Controller connection guide covers it for both the Pro Controller and Joy-Cons.

Step 3: Check the run order and duplicate instances

BetterJoy scans progressively while it runs, so a controller paired after the program started should appear — but when it doesn’t, restart the program after the controller is connected to Windows. Also make sure BetterJoy is not already running: since v6.3 the program refuses to start a second instance, and an old copy minimised to the system tray can make a fresh launch look like “nothing happens.” Check the tray and Task Manager, kill any existing BetterJoyForCemu.exe, then launch once.

Step 4: Isolate Bluetooth with a USB cable

Plug the controller in with a USB data cable. The wiki’s USB advice is to unplug, replug, and give Windows a moment to finish setting the device up before judging. Two outcomes:

• It appears over USB but not Bluetooth: the pairing or your Bluetooth stack is at fault. Re-do step 2, and if Joy-Cons are involved, work through the adapter and driver checks in our Bluetooth lag fix — a weak adapter often fails at detection before it ever gets to lag.
• It appears on neither: check whether any program can see it. If the controller vanished from every app after a previous BetterJoy session, it may still be sitting on the legacy HIDGuardian blacklist — recover it with the localhost:26762 recovery guide before trying anything else.

One more wiki item worth ten seconds: if plugging into USB does literally nothing, open Device Manager’s USB controller properties and untick the power-saving option that lets Windows turn the device off.

Step 5: Move BetterJoy out of protected folders

Issue #678 pairs this symptom with a popup: Access to the path 'C:\Windows\system32\settings' is denied. That happens when the program lives somewhere Windows protects and cannot write its settings. Extract the ZIP from the download page into an ordinary user folder — Documents or Desktop, never System32 or Program Files without admin rights — and run it from there.

What will not fix this

Two dead ends to save you time. First, Switch 2 controllers: v7.1 predates them and does not recognise Joy-Con 2 or the Switch 2 Pro Controller at all — no re-pairing will change that. Second, some third-party pads pair with Windows perfectly yet are never listed by BetterJoy; that is a separate, documented limitation covered in our third-party controller guide.

Still stuck after all five steps? Browse the full list on the BetterJoy troubleshooting hub — your symptom may match a different fix.

FAQ

Windows says the controller is connected. Why is BetterJoy empty?

Pairing only means Windows completed a Bluetooth handshake. BetterJoy still has to open the device, and a stale pairing, a second program holding it, or the HIDGuardian blacklist can each block that. The remove-and-repair in step 2 plus the USB test in step 4 separate those causes.

Do I need to run BetterJoy as administrator to detect controllers?

No. Detection does not need admin rights; per the official README, administrator mode is only the fix when your keyboard or mouse mappings do not work. If you see an access-denied popup about a settings path, that is a folder-location problem (step 5), not a permissions ritual to repeat.

The controller worked yesterday and vanished today. What changed?

Most often one of three things: Windows re-paired it as a “new” device, another tool (Steam, an emulator) was holding it when BetterJoy scanned, or a previous session left it hidden by HIDGuardian. Steps 2, 3 and 4 cover them in that order.