Interesting. Generally, what I do as the first step is immediatelly connect a remote debugger and debug the piece of code that I think is problematic (which is correct in around 90% of the times for me). Then, the answer is generally trivial. I started doing this because it felt way more time efficient than staring into the code and trying to think what goes wrong over there.
I've found that sometimes there's additional benefit to the "take a step back and think about what the code is actually doing" step, in the sense that doing so helps gain better knowledge about how the code actually works and often reveals opportunities to simplify the design (sometimes in such a way that ends up inadvertently fixing the problem, though admittedly it'll more often just introduce more bugs ;) ).
