Your Bugs ..
Even if pointing out bugs is not a great problem in Assembly, you may have to face some difficult cases. RosAsm's syntax and editing features help a lot at preventing errors before the actual Run time. In most cases, faulty statements will be properly pointed out either by the Compiler or, if not, by the integrated Debugger. Other than that, when you encounter no cue hanging Bugs, think first of these:
Unpaired push / pop that leave a wrong return Address on the Stack. The Debugger is unable to point out this error, because the exception is raised out only after the Return. Then, you see the Debugger pointing usually to the last line of your Source because the pointed Code to be executed is then out of your real Code space, or, if hazard achieves in some Address really inside your Code, the pointed Instruction may be at any location in your Source.
Confusion between Variables and Addresses. RosAsm (and NASM) simplified notation help a lot at preventing such errors, but you may be confused when, for example, managing Variables that hold pointers to tables of Pointers. Then, there are many chances you will see the Debugger pointing you to a read or write Instruction with an Access-Violation Message.
Bad Parameter in an API call. There is no medicine against this. Just test your new calls and carefully read the API Documentation. This documentation is sometimes bad, because it has been written by documentalists, instead of programmers, but my own experience has proven to me that I was, at least, as bad a reader than the documentalists were bad writers... Explaining such complicated stuff is not very easy.
Bad Parameters Number in an API call. This results in the same error as the aforementioned Unpaired push / pop error, with the same (un)expected effect.
Bad indices when scanning a flow of Data. Asm programmers have regularly to face the '+1/-1' dilemma. The Human brain (mine, at least) is poorly designed to deal with this problem: We have a Table beginning at 0A0000 Address. 5 Bytes of Data are stored in this Table. At what Address is the last Value? What is the next free Address? What is the length of the Data Set?... despite the fact that I began programming more than 30 years ago, I must say that I still solve these problems just like a baby would: Paper / Pencil / Mark-Points / Count.
Generally speaking the best Debugger I ever wrote is the Hexprint Routine I provide in all BaseX.exe Files. For bug hunting , Debuggers are usually a waste of time. In most cases Hexprint will point out quickly, at least what is hanging (if not why, which may be a more complicated problem... but no Debugger will ever tell you why, as you may know...). The cases when you will have to spend more than two Minutes for fixing a bug, with Hexprint, will be very exceptional cases and very rare indeed.
~~~~~~~