./tell

Or: How Linux once again helps you to analyze a Windows problem…

Our marketing assistant’s private Windows PC has recently been experiencing lag and performance problems. After these became more and more frequent, he began to tackle the problem using the usual methods. After updating and rolling back almost all drivers, reinstalling affected applications and repairing the system using the appropriate Windows functions did not help, he tried a BIOS update and restarting the operating system.

After the PC was completely reinstalled clean, at least the symptoms of the problem changed. In addition to the more than one-second jerks in some applications, the notification sound for disconnecting a USB device was now played with every still image. So after all the work, the problem had initially gotten worse. However, the sound output that has now been added has led to a new approach.

Due to the fact that the same error was thrown out in enormous quantities when reading all internal system events, it was quite clear that either the mainboard had hardware damage or a driver for a USB port had a compatibility problem. After we installed a USB driver for an older version of Windows in compatibility mode and the sound was still playing every second, a hardware defect seemed to be the most realistic cause of the problem.

We remained with this assumption until the idea arose to test whether the same symptoms occur under Linux. So we booted the PC with an Ubuntu stick. After no events could initially be read out, the PC was put under load for some time with various benchmark tests.

Even after a long time under full load, no difficulties arose under Linux. Which is why a hardware error was now considered rather unlikely. So it was time to boot Windows again and search more meticulously for the problem.

This more detailed search mainly consisted of searching PowerShell for a ComponentID that matched the error. Unfortunately, there was no success here. In the registration editor there was finally a match, which in turn led us to a hardware ID. Shortly afterwards, an HID device (“Human Interaction Device”) with the corresponding ID was found in the Device Manager. When this device was deactivated, the USB sounds and laggs also disappeared. However, we still don’t know what exactly was deactivated. But since no desired function in the system has caused any problems so far, we will accept this for the time being.

So once again Linux helped to identify the problem (what a big surprise for all developers that it was Windows) and thus saved a lot of time that would otherwise have been wasted on trial-and-error attempts.

(And he promised us that he would actually think about a Linux installation)