Debugging is an art. A lost art of course, now that everyone is writing unit tests and no one ever needs to use the debugger anymore. But for those of us who don't mind some history, or are stuck with it, here's how I usually tackle it.
Binary search is a method to quickly narrow your search space while not running the chance of missing what you're looking for. There are a few properties your search space needs in order to be able to apply binary search, most important of which that it has to be ordered. Fortunately, code usually is ordered. Not to be confused with structured.
So how does it work? The key to binary search is not quickly finding what you're looking for, but eliminating what you're not looking for early. So with binary search debugging we need to pick our break points such that we can quickly say whether the current state of the program is broken yet.
It is very important to not read code. Or at least, read as little code as possible. When in doubt, don't read. Don't do it. This is the single biggest mistake junior debuggers tend to make. And while it can be intensely interesting to try and understand everything that happens, you have to repress this urge if you want speed.
But what if you can't tell whether the state of the program is broken yet?
Unless the bug has a clear symptom, there should be something you can check. There should always be something someone points to saying "Aha! That's not how it should be!". Whether it's the wrong price of a product, the wrong e-mail address selected for a mailing or the wrong packet of data sent to that API, there is always a starting point. And that came to be at some other point. And that came to be at a point before, and so on. So work your way backwards. It is important to follow the trail and not skip steps, especially if you're unfamiliar with the code. Because the less familiar you are and the more you're off trail, the more you need to read code and reading code costs time and headaches.
So start at the end, when you know things are broken. Jump backwards to before things were broken. Jump forwards to when things are broken again, but less far. Jump backwards to when things were broken again, but further ahead. Repeat until you've found the cause or an underlying symptom. If you found an underlying symptom, then repeat this entire process. If you've found the cause, then squash and celebrate!
Happy huntings!