So you're aware of the IDE menu option Debugging > Exceptions, where you can specify in detail on which types of exception the debugger shall break when they occur and before the runtime scans the call stack upward to find a responsible exception hander (the so-called first chance exception), it just doesn't help really much? Breaking on most exception types is disabled there by default, and in complicated debugging scenarios like yours it can be quite helpful to fine-tune debugger behavior by enabling a few of them that are more or less specifically related to your scenario. (Actually, I about just as much use that menu item to disable a few of the exceptions breaking on is enabled by default, but that's another story I think.)
I actually use these settings quite a bit while debugging now, unfortunately they only take me so far at times.


Do I get you right that you don't intend to throw exceptions yourself from your assembly routines, you just want to maintain proper stack traces? In that case I'm not quite sure what you mean by "include [your] own information about what happened", when the problem actually is to get hands on the exception information in the first place.
What I actually was talking about there, I would like to either fix the problem with the stack trace or figure out how to throw my own exceptions so that I could (hopefully) include some pertinent info on why the exception happened. I am still reading up on the "global catch-all" that you mentioned, and will probably have a question or two about that once I try it out. I havent had the time to work on anything the last few days as Ive been dealing with sick kids and a sick dog while being sick myself.

I have logging capabilities in my code, unfortunately, most of the time when I am trying to track a bug down, its something that only happens once in every hundred thousand runs or something which leaves quite a log file to go through. When I am debugging, I run my programs in single-threaded mode (in the sense I dont spin up any other threads), Ive learned lately to watch what thread the error happans on, as Ive been running into problems with the garbage collection thread after I made changes to the memory management routine.

It seems like everytime I post here, it boils down to a debugging question. I am looking into a modern book on assembly programming to see if there may be something more I can do in my coding style to help. The only thing Ive read is "The art of assembly language" but I run into conflicting ideas when reading some of the recent blogs and web pages. For instance, I started out breaking the algorithms down into small parts, but then read that all the jumping costs too much time so that should be brought to a minimum, but trying to put all that code in one algorithm makes it hard to maintain, for example, my division algorithm contains some 1,000 lines of code when I call out to other routines within it, putting it all into a single algorithm without any calls it jumped to almost 15,000 lines of code, while it did make it run faster, it was almost impossible to maintain. I have learned my lesson about commenting in the code through