vJoy Monitor (JoyMonitor): Verify Axes and Buttons Live

If you search for vJoy monitor, what you need is JoyMonitor: the small monitoring tool bundled with vJoy that shows the live state of a virtual device. It answers the single most valuable diagnostic question in any vJoy setup: is the virtual device actually receiving the axes and buttons my feeder thinks it is sending, right now? That answer, obtained in thirty seconds, decides whether your next hour belongs in Windows and feeder settings or inside a game’s binding menus. This guide shows how to use JoyMonitor properly, how to read what it displays, and how to use it before blaming a game.

What JoyMonitor shows

JoyMonitor displays the current state of a selected vJoy device: the position of each enabled axis, the pressed or released state of its buttons, and POV hat position where configured. It is a passive observer. It does not change configuration, it does not generate input, and it does not fix anything. Its value is precisely that passivity. When you move a physical control, run a feeder script or press a mapped key, JoyMonitor shows what arrived at the virtual device, stripped of every game-specific layer. If the value moves here, the driver and feeder chain is working. If it does not move here, no game will ever see it.

A clean monitoring routine

1. Open Configure vJoy first and note the device ID, axes and button count you configured. Monitoring the wrong device is the most common false alarm.
2. Start your feeder and load the profile you actually play with, not a test profile you half remember.
3. Open JoyMonitor and select the same device ID the feeder writes to.
4. Move one physical control at a time, slowly, through its full range, and watch the matching virtual axis.
5. Press each mapped button once and confirm the corresponding button indicator changes in the monitor.
6. Check the POV hat last, in all directions, then leave the feeder idle for a few seconds and confirm every axis settles at a stable rest value.

Work through that routine in order and write down anything that misbehaves in plain language: throttle axis moves the wrong virtual axis, button 7 never fires, one axis jitters at rest. Those notes turn a vague feeling that something is wrong into a feeder mapping problem you can fix in minutes. They also protect you from the opposite error, reconfiguring a healthy driver because a game profile was loaded incorrectly. The monitor does not care which game you play. That neutrality is exactly why it belongs before game troubleshooting, not after it.

Reading the results like a diagnostician

Three patterns cover most real setups. Pattern one: nothing moves at all. That points below the game, at a feeder that is not running, a feeder targeting a different device ID, or a driver and configuration problem. Check joy.cpl as a second witness: if the device is absent there too, return to installation and configuration. Pattern two: axes move but buttons do not, or the reverse. That is usually a feeder mapping gap or a device whose button count in vJoyConf is lower than the feeder expects. Pattern three: everything moves in the monitor but the game ignores it. Now, and only now, the game is the problem area: bindings, device selection inside the game, or a game that needs a different input layer because vJoy is DirectInput, not XInput.

Jitter, wrong axes and stuck buttons

Small axis jitter at rest in the monitor usually comes from the physical device or the feeder’s curve and deadzone settings, because the monitor is honestly reporting what the feeder sends. Fix it in the feeder, not by reinstalling the driver. An axis moving the wrong virtual channel is also a feeder mapping issue: the feeder chose that target, and vJoyConf only needed the axis enabled. A button that appears stuck on in the monitor points to a feeder output latched on, a macro still running, or two feeders writing the same device and fighting. Close feeders one at a time while watching the monitor and the culprit will reveal itself by making the symptom stop.

The DLL mismatch symptom pointer

One failure does not belong in JoyMonitor at all, and recognising it saves time. If a feeder refuses to start, reports that it cannot acquire the device, or shows an error in the family of driver version does not match DLL, the problem is a version mismatch between the installed vJoy driver and the vJoyInterface.dll the feeder is loading. The documented pattern is a feeder carrying a DLL from one release, for example 2.1.8, against a driver from another, for example 2.1.9. The fix is to use a DLL from the same release as the installed driver, not to keep clicking in the monitor. Our troubleshooting cluster covers that error string in full.

Common mistakes

• Monitoring the wrong device ID. Match the monitor, vJoyConf and the feeder to the same ID before drawing conclusions.
• Testing without a feeder. vJoy alone sends nothing. An idle monitor is correct behaviour, not a fault.
• Blaming the game first. Use the monitor before opening the game. It splits the problem space in half.
• Changing driver and feeder at once. If the monitor picture changes, you will not know which change caused it. One change, one retest.
• Ignoring rest state. A device that will not settle at rest will drift in menus and simulators. Catch it here.

Frequently asked questions

Is JoyMonitor the same as joy.cpl? They are complementary. joy.cpl proves Windows lists the device and shows its test view; JoyMonitor gives a clearer live view dedicated to vJoy devices. Using both gives you two independent witnesses. Do I need JoyMonitor running while I play? No. It is a diagnostic tool. Close it when the setup is proven. The monitor shows movement but my game shows nothing. What next? Check the game’s device list and bindings, confirm the game reads DirectInput devices, and remember simulators may list every vJoy device under the same name, so you may be binding a different device than the one you monitored.

Keep going

Start from the vJoy download page if you need the installer again, and use the vJoy Setup hub as the index for this whole cluster. Two guides that pair naturally with this one are Configure vJoy with vJoyConf and How to Use vJoy: Feeders Explained. Read them in that order if you are building a setup from scratch: download choice first, installation second, configuration third, and only then time inside a game or simulator. That order prevents the most common wasted hour in this niche, which is debugging a feeder or a game for a driver problem that was visible in Windows all along.