The DLL That Lied: Breaking Everything on the Way to v1
I tried to ship. I broke everything instead.
The Starting Point
The X52 Pro Configurator was working. Axes read from the HOTAS, processed through deadzones and curves, forwarded to vJoy virtual devices. Games saw clean input. It worked.
So naturally, I decided to package it into a standalone installer. PyInstaller exe, Inno Setup, the works. How hard could it be?
The Descent
The first sign of trouble was a DLL error popup on launch. Two of them, actually. Windows RegisterClassEx failures that appeared before the app even loaded its UI.
Then vJoy stopped outputting. The app said everything was fine — axes acquired, device connected, writes returning True. But joy.cpl showed nothing. Flat lines. No movement.
Then the auto-setup dialog broke. Then the admin elevation broke. Then the app started crashing on startup with AttributeError because I'd removed a threading event but left a reference to it three methods down.
Each fix introduced a new problem. Each new problem needed another fix. I was chasing my own tail through a single 2,000-line file, and every change was making it worse.
The Miscommunication
Here's the thing about working with an AI co-engineer: it's brilliant at what you ask it to do. The problem is when you're both solving different problems and neither of you realises it.
I was looking at the output — "vJoy isn't showing axis movement." My co-engineer was looking at the code — finding real bugs, fixing real issues. DLL double-loading. Stale attribute references. Broken admin elevation flows. Auto-setup logic that acquired devices just to check their status, then couldn't reconfigure them because they were now locked.
All real problems. All worth fixing. But none of them were the problem.
We spent hours adding complexity. A temporary Python script that elevated itself to admin. A lazy-loading DLL wrapper. An axis-checking function that concatenated strings wrong. Each fix was correct in isolation and completely beside the point.
The axes weren't moving because the writes were going to the wrong DLL.
The Root Cause
I was using pyvjoy — a Python wrapper around vJoy's native DLL. Sensible choice. Well-known library. One problem: pyvjoy bundles its own copy of vJoyInterface.dll inside the package directory.
pyvjoy's DLL: 179,200 bytes
System DLL: 888,432 bytes
Not even close to the same file.
pyvjoy's bundled DLL was an older version that didn't match the driver I had installed — the BrunnerLivio fork (v2.2.2.0), which is the one that actually works with Windows 11.
The old DLL could connect to the driver. It could acquire devices. It could call SetAxis and get True back. But the actual data never reached the virtual joystick because the internal protocol between the DLL and the kernel driver didn't match.
Every function returned success. Nothing actually worked.
That's the worst kind of bug. No error message. No exception. No crash. Just silence.
Back to Basics
After hours of spiralling, I finally said the magic words: "No. Right back to basics. Can we just get one vJoy device and a test script to work?"
Strip everything away. No app. No pyvjoy. No auto-setup. Just Python, ctypes, and the system DLL.
dll = ctypes.WinDLL(r"C:\Program Files\vJoy\x64\vJoyInterface.dll")
dll.AcquireVJD(1)
dll.ResetVJD(1)
dll.SetAxis(16383, 1, 0x30) # X axis, half deflection
joy.cpl moved.
Three lines. That's all it took to prove the system worked. The driver was fine. The hardware was fine. It was the library sitting between them that was lying.
The Fix
I ripped out pyvjoy entirely and replaced it with a thin wrapper class — about 40 lines of ctypes code that loads the system-installed DLL directly. No bundled copies. No version mismatches. No middleman.
I also added ResetVJD() after acquiring each device — something pyvjoy never did, and something the driver apparently needs to initialise its internal buffers properly.
First run after the fix: all axes moving, all buttons firing, both vJoy devices responding. Mode switch, toggles, POV hats — everything.
I genuinely teared up.
What I Learned
1. "Returns True" doesn't mean "worked." Silent failures are the hardest bugs. When every function call reports success but the system doesn't respond, you can debug for hours without finding the problem — because the problem isn't in your code.
2. Libraries bundle things you don't know about. pyvjoy isn't broken. It works fine if your installed vJoy version matches its bundled DLL. But if you're using a different fork — which you have to on Windows 11 — the mismatch is invisible until you compare file sizes.
3. Complexity spirals are a warning sign. If every fix needs another fix, you're not solving the problem. You're decorating it. The moment I stopped adding code and started removing it, the answer appeared.
4. Your co-engineer solves what you ask it to solve. AI is incredible at finding and fixing bugs. But it optimises for the question you asked, not the question you should have asked. If I'd said "why doesn't SetAxis reach the driver?" instead of "fix the DLL error popup," we'd have found the root cause in minutes, not hours.
5. Back up before you start. I didn't back up before the packaging attempt. Hours of recovery could have been avoided with a single folder copy. Lesson learned the hard way — again.
Where It Stands
The X52 Pro Configurator is working. Both vJoy devices configured, all 9 axes mapped, all 31 buttons assigned, mode switch passing through, POV hats active. A golden backup exists that I'm not touching.
Next: package it into a standalone exe without breaking it this time. And this time, there's a backup.
Sometimes the hardest part of shipping software isn't writing it. It's not destroying it on the way out the door.