I don't think many errors are related to typing errors. Typos will generally not produce stuff that will compile so rarely produces anything that gets even as far as unit testing, let alone beyond that. Those few that do are generally very easy to spot.
In 16 years in development the only issues that I've seen which were caused by a hardware fault were so major (i.e. system / sub-system down) that it was instantly obvious and was picked up by the sysadmins. Once it makes it as far as the programmer I'd suggest that you remove the possibility of hardware error from your mind until you see some very very strong evidence to suggest that that's the case as generally it's so unlikely you shouldn't waste time thinking about it.
Errors fall into three categories:
1) Misunderstandings - that is the system is working correctly but someone has misunderstood what it's meant to do. The best way to find out if this is the case is to get as much information as possible, ideally by speaking to someone who has actually seen the error and ask what they saw and what they expected to see.
2) Configuration Errors - while there are very few errors which are caused by hardware errors, there are plenty caused by machines being set up differently as far as software configuration goes. This is particularly likely if you can't reproduce the error on your development set up which is likely to be pretty non-standard because of the assorted tools you've got installed and changes you've made to be productive. The best thing to do here is to have a development test environment which is a clone of production and try and reproduce the error on there. Once you have you can start comparing that environment to the ones where it works and see what the differences are.
3) Code Errors - the code is out and out wrong. There are common problems (not checking return values or badly handled errors, incorrect loops and checks - for instance not checking the final record in an array or collection because the developer got confused about whether it ended at i or i-1) but exactly how common they are varies from project to project and in any case, they're easy enough to spot by walking the code. The main things I'd say here are make sure you can reproduce the error (this may involved getting details of a specific record where the error occurs from the user) and walk the code line by line.
Broadly speaking I'd suggest the following hints:
1) Own the problem. It's your problem and you need to fix it regardless of what it is or who originally caused it. This may involve you looking into things that aren't your area of specialisation but it that's what it takes, that's what you do.
2) Speak to the user. The thing which slows down problem resolution the most in my experience is bad information so cut that out by going straight to the user and find out what's happening. Have them walk you through it, what they did, what they saw, what they expected to see. Ask if it happens all the time or just some of the time. If it's just some of the time ask them about patterns, get details of specific records where it occurs. Question everything and assume nothing. And when I say speak to them, I mean speak to them - you'll find out more than through some e-mail conversation and you'll do so far far faster.
3) Reproduce the problem. Don't guess at the solution, reproduce it, it's the only way of knowing you've really found what's happening. Walk the code step by step and see what's actually happening. This may involve reproducing the environment or getting a copy of the database - if you have to, that's what you do.
4) Be realistic. It's not a hardware problem and you've not found a problem with the compiler. Once you've worked out it's a real problem (that is that the user is not mistaken about what it's meant to be doing) and you've reproduced it, by far the most likely issue is that the code is wrong so don't kid yourself otherwise.
5) Fix the root problem, not the symptom. If they say everything is out by 1, don't just subtract 1 from everything, find out WHY it was out by 1 and fix that. If you only fix the symptom, you will see the problem again.