Wil Shipley wrote up a story about the tracking down and fixing of a tricky to reproduce bug. It's a good example of how good debuggers/troubleshooters think and find problems. That's something always always tough to put into words, so any time anyone gets close I like to point it out.
For me, the tools used aren't quite as step-by-step. I tend to look at all the info up front (stacktrace/exception/defect report) so it's all sort of in my head when I start, which sometimes helps catch the part that doesn't make sense a little earlier.
If Wil's steps hadn't worked, the next think I would have tried would have been adding temporary assertions to verify some of those assumptions (even assumptions that I just looked up in the documentation). Sometimes the docs are wrong or confusing, and the best way to find out what's really going on is, well, to find out what's going on.
I often find that doing that finds the problem, or perturbs the bug in a way that gives more clues. Don't be afraid to experiment; sometimes the same defect occurring in a slightly different circumstance can give a lot of information about it.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site 
or contact me at rob at big dis dot com.
See my writings on: