A few weeks ago I got a call from my wife because her desktop computer wouldn't boot. When I got home that evening I found that it was hung at the BIOS screen. The odd part was sometimes I could get it to boot, but only sometimes. The pattern made no sense so I started stripping back the layers of complexity.
With only power, HDMI, wired keyboard and mouse connected I could get it to boot. I ran memory, CPU, BIOS and Windows tests and could find no problems. So I started adding things back one at a time. When I plugged in the USB webcam it hung at the BIOS screen. To further complicate the troubleshooting, it only hung when doing a complete POST and USB enumeration from scratch. Shutting down and powering back on worked even with the webcam connected, because Windows Fast Startup restores a hibernated kernel session instead of enumerating USB again.
That strip-it-down method is the key to troubleshooting. Reduce the system to the simplest thing that works, verify it, then add one layer at a time until you break it again.
Earlier this year I stopped by a corporate client's divisible conference space where our engineering team was commissioning the system. The handheld mics were distorted in the room but when in a call they were fine to the far side. The team had been working the problem for a couple of hours and was looking into hardware issues.
I asked what would happen if they routed the mics straight to the speakers and bypassed all the routing and processing in the DSP. It was a quick programming change to strip down the system to a simpler state. That test came up clean and the mics sounded fine in the room.
That simple test didn't fix anything, but it simplified the search. It proved that the microphones, amplifiers, and speakers were all working correctly and that the fault had to be in the programming of the DSP. I went on to my meeting. By the time I came back, the team had added the DSP elements back, one by one, until they found an AEC reference routed wrong in one of the matrices. The asymmetry was the clue. The system worked to the far side but not in the room. That meant that someplace after the paths diverged there was a problem.
Reducing works the same way on a rack of hardware and on a line of programming, and indeed on the computer on my wife's desk at home.
When you have been stuck for hours, stop trying to name the fault and start taking things away until you get down to a known working state.