Depends. If there's an error message, I tend to skim it over to get the sense of where the problem happened. Then I go back to the code, waste 5 minutes trying to figure out what went wrong, then go, "ok... what does the error actually say"? Once I read and understand the error message (if it isn't too terribly vague), then I can narrow down the issue. I'm a huge believer in logging and my application logs every single database error, along with the SQL statement and parameters/values used.
If it's database related and it's not immediately obvious what a dope I was, I'll copy/paste, or reconstruct the SQL in SSMS and try to narrow it down from there. At that point, if I still can't get it right away, I'll start commenting out certain joins until I can figure out which one was causing the issue. Process of elimination.
If it's front-end code, Chrome debugger or console.log will be my choice. Again, depends on the situation. I have the JavaScript Errors Notifier extension, and that is super helpful to locate errors. Every now and then, Chrome and Firefox are totally fine, but IE encounters the error instead. Say what you will about IE, one thing it is good at is finding tag-related errors that others quite forgivingly skip over (e.g. unclosed tags, misspelled tags, etc.). Those are far and few between for me, but it happens. The Chrome debugger throws those javascript errors, and gets you right to the line that caused the problem much of the time. Of course, that's not the whole story there. Why was that variable undefined, for example? Go through the obvious stuff: did the value get initialized? No? Is it a function parameter? Yes. Did it get passed in from the calling function? Yes. Hmm... time to step through with the debugger or do some console logging.
If it's back-end code, again, it depends. I rarely use a debugger with PHP server code on for a web-application, but every once in a while I do, especially for more complicated stuff. Most of the time, I start putting log debug statements in and watching my log. Sometimes, it's as simple as logging how far the process gets before it errors out. Again, process of elimination. Once that's figured out, the next question is: is it a programming problem or a data problem. Many times, it's a data problem, so dumping objects to the log to inspect the data is useful and often exposes what the problem is.
These methods let me find bugs within just a few minutes 80% of the time. The rest of the time, things might get a bit more involved, especially when I have to delve into a third-party library to figure out what's happening. I had to do that yesterday. Fun times!