You have done the single most valuable piece of troubleshooting already, which is proving the controller good on a second machine. That turns an open-ended problem into a bounded one: something on the desktop is refusing this class of device while accepting others.
Start with state, because it is free and it is the most common answer. Windows caches device state, and a hybrid shutdown restores it rather than clearing it, so a bad state survives what most people think of as a restart. Disable fast startup, shut down fully, unplug the controller, leave it a minute, then boot and plug it in. That alone resolves a meaningful share of cases where a device works elsewhere and not on one machine.
Next, look for leftovers from controller software. This is the most likely cause on a desktop that works for everything except controllers. DS4Windows, older vendor utilities, reWASD, ScpToolkit and similar tools install drivers and filter drivers that sit in the HID stack, and an incomplete uninstall can leave something that swallows controllers before Windows presents them. In Device Manager, turn on View then Show hidden devices and look through Human Interface Devices and Universal Serial Bus controllers for greyed-out or unknown entries related to controllers, and remove them. Then cold boot again.
If that does not do it, check whether anything is claiming the device exclusively at boot: a service or startup entry from one of those tools can run before you log in. Look through startup apps and services for anything controller-related and disable it.
The diagnostic that narrows it further if you are still stuck: boot the desktop from a Linux USB stick and plug the controller in. If it works there, the hardware and ports are definitively fine and the problem is entirely in the Windows installation, which makes a targeted driver cleanup, or in the last resort an in-place Windows repair, the right route rather than more guessing.
