How to Log Keypresses in Windows and Ubuntu to Diagnose Communication Error

To diagnose communication errors by logging keypresses in Windows and Ubuntu, use built-in diagnostic tools rather than third-party keyloggers. In Windows, enable the On-Screen Keyboard’s accessibility features or use PowerShell to capture input events. In Ubuntu, utilize xev for X11 sessions or evtest for Wayland to monitor raw input data from the kernel.

Understanding Input Diagnostics

When a keyboard fails to communicate correctly with an application or operating system, the issue often lies in the driver layer, the input method framework, or hardware interference. Traditional "keylogging" software is designed for surveillance and often triggers security alerts or antivirus warnings. For technical diagnosis, you need transparent access to the raw input stream to verify that every physical press generates a corresponding digital event.

This approach allows you to distinguish between hardware failures (where no signal is sent) and software conflicts (where signals are dropped or misinterpreted). By observing these low-level events, you can pinpoint whether the problem originates from the USB controller, the kernel module handling the device, or the window manager interpreting the data.

Windows: Using Accessibility and PowerShell

Windows does not include a dedicated command-line tool for simple key logging by default, but it offers robust accessibility features that reveal input states. The most reliable non-invasive method involves the On-Screen Keyboard (OSK), which provides visual feedback for every detected keystroke.

1. Press Win + R to open the Run dialog.
2. Type osk and press Enter to launch the On-Screen Keyboard.
3. Physically press keys on your external keyboard while watching the OSK.
4. If a key is pressed physically but not highlighted on the screen, the issue is likely at the hardware or driver level.

For more advanced diagnostics, you can use PowerShell to monitor specific input events. While capturing all keystrokes requires administrative privileges and careful handling of security policies, you can check the status of input devices using system commands. Open PowerShell as Administrator and run the following command to list connected HID (Human Interface Device) devices:

Get-PnpDevice | Where-Object {$_.Class -eq "HID"} | Select-Object FriendlyName, Status

If the status shows errors, the device is not communicating properly with the OS. You can also use the Get-EventLog cmdlet to search for recent input-related errors in the System log, which may indicate driver crashes or timeout issues.

Ubuntu: Using xev and evtest

Linux provides powerful, built-in utilities for inspecting input devices directly from the terminal. These tools bypass graphical interface layers, giving you a clear view of what the kernel receives.

For X11 Users: The xev Utility

If you are using the traditional X11 display server, the xev utility is the standard tool for debugging keyboard issues. It opens a small window and prints every X11 event associated with it to the terminal.

1. Open a terminal window.
2. Type xev and press Enter.
3. A small white window will appear. Click inside it to focus.
4. Press keys on your physical keyboard.
5. Observe the terminal output for lines containing KeyPress or KeyRelease.

Each line includes a keycode (e.g., keycode 24). If pressing a key produces no output in the terminal, the X server is not receiving the event. This suggests a problem with the X server configuration, the display driver, or the underlying kernel input subsystem.

For Wayland Users: The evtest Utility

Modern Ubuntu versions default to the Wayland display server, where xev is largely obsolete because Wayland isolates applications from direct input access. Instead, use evtest, which reads directly from the Linux input event nodes in /dev/input/.

First, install the utility if it is not present:

sudo apt update
sudo apt install evtest

Then, run the tool to identify your keyboard device:

sudo evtest

Select your keyboard from the numbered list. Press keys physically and watch the terminal. You should see detailed reports like:

Event: time 1678901234.567890, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70006
Event: time 1678901234.567890, type 1 (EV_KEY), code 26 (KEY_A), value 1

The value 1 indicates a key press, while value 0 indicates a release. If values do not change when you press keys, the kernel driver is failing to detect the hardware event.

Troubleshooting Common Findings

Once you have collected the diagnostic data, interpret the results based on the missing components. If Windows OSK does not reflect physical presses, try disconnecting and reconnecting the keyboard, or testing a different USB port to rule out port-specific power issues. In Ubuntu, if xev or evtest shows no activity, check for conflicting input drivers or stale udev rules.

Additionally, ensure that no accessibility filters are active. In Windows, go to Settings > Accessibility > Keyboard and disable "Filter Keys." In Ubuntu, check Settings > Accessibility > Typing for any sticky keys or slow keys options that might be intercepting input before it reaches the diagnostic tools.

If you are experiencing specific issues with certain applications, such as Chrome ignoring keyboard input, refer to our guide on fixing keyboard problems in browsers. Similarly, if you are working within a virtual environment like WSL, database connection issues might be unrelated to keyboard input, so consult our troubleshooting guide for WSL DB connections if network errors persist alongside input problems.

Frequently Asked Questions

Is using xev safe for my system?

Yes, xev is a standard, pre-installed debugging utility in X11 environments. It only reads input events destined for its own window and does not record, store, or transmit keystrokes to any external party. It is widely used by developers and system administrators for legitimate troubleshooting.

Why does my keyboard work in BIOS but not in Ubuntu?

This indicates that the hardware is functional, but the Linux kernel driver or user-space configuration is failing. Use evtest to check if the kernel sees the keypresses. If it does, the issue lies with the desktop environment or display server settings. If it does not, check dmesg logs for driver errors during boot.

Can I log keystrokes in Windows without administrator rights?

While some third-party tools require admin rights, the On-Screen Keyboard (osk.exe) runs without elevated privileges and provides immediate visual feedback. For programmatic logging via PowerShell, administrator rights are typically required to access system-wide input hooks or event logs securely.

What should I do if evtest shows repeated key codes?

Repeated key codes usually indicate a stuck key, a hardware short circuit, or a debounce issue in the keyboard firmware. Physically inspect the key for debris or mechanical failure. If the issue persists across multiple keyboards, the problem may lie with the USB controller or motherboard port.

Does Wayland support key logging like X11?

Wayland intentionally restricts direct access to input events for security and privacy reasons, making traditional keylogging impossible for applications. However, system-level tools like evtest still work because they interact with the kernel's input subsystem directly, bypassing the display server isolation.