Speed up development using... disassembly!
For a programmer, there's a time when you're trying to finish a feature and need to flush out the initial bugs in the product. A very typical but inefficient process is to run the app, find a problem, shutdown the app, fix it in the code, recompile it, and then restart the app. In our build environment, it could actually take a long time to restart an app because the code hasn't been optimized, so anything that will prevent a restart helps. One tip that has really sped up my development time has been the use of the memory window in the debugger. Now of course you can use the memory window to look at objects such as strings or structures, but using the memory window to alter instructions is an excellent way of reducing unnecessary restarts. I'll share with you the three examples that I use most often to save me time while debugging.
One thing involves using the assembly instruction NOOP. Asserts are great in that they catch problems in advance in a debug build, but have you encountered the same assert fires off over and over again for a problem you don't plan to immediately fix? One quick way to get through is to view disassembly, look at where the interrupt instruction is, and open the memory window to that location. Then type in the NOOP instruction (0x90 on the x86 CPU) and continue on! Also, if there's code you want to simply bypass for the remaining of your run, just NOOP those instructions, and you save time for the recompile! Just remember to write the problem down so you remember to fix it.
Another usefulness of the memory window is when you want to change the value of some constant. Instead of stopping, changing the value, and restarting again, just go to the disassembly view, find out where the constant is, and change it. Some examples include assigning a value using the equals operator, a value used in calculation, and just about any other constant that shows up as a number in the memory window. This allows you to continue on your scenario, which saves lots of time in the long run.
The last usage of the memory window I use often is in altering code. No, I'm not trying to be the compiler and alter the instructions by figuring out what the assembly is. This involves just a simple logic flip. For example, if you have a “if (pJunk == NULL)” that you realized should have been “if (pJunk != NULL)”, just find the bne, jne, or *ne instruction and flip it! There, now you can continue to debug other issues all in the same pass. Again, remember to write it down so you don't forget to fix it, or the next time you restart the app, you'll hit the same issue again!
[Author: James Lee]