Never ignore a bug that occurs early in a test to investigate a bug that occurs later. Oftentimes the later bug is a mere side effect of the earlier one. You'll save yourself time if you fix bugs in the order they appear.
Never forget the goal is to make the program work—fixing the bug is merely the means, not the end. Periodically step back and consider if there might be an easier way to fix the program than the one you're working on now.
When something works one way but fails in a different way, focus on the differences. Any theory that does not explain why the code sometimes works but sometimes fails can be instantly rejected. The differences will give you powerful hints about where to look.
Never assume the problem is a bug in the hardware, API, or OS without reasonable proof. Those tools go through far more testing than your product likely does. The majority of your bugs will be your own fault. Don't be too quick to blame the compiler.
Keep a few test computers on which debugging tools are NEVER installed—no exceptions. Period. Your test environment should mimic your typical customer as closely as possible, and if your typical customer doesn't install debugging tools, then neither should your test lab.
Step over all new code in the debugger as soon as you finish writing it. You'll see things you didn't notice when writing the code. There are very few more effective ways to catch bugs early on.