A useful debugging tool

[NoCforMe]

There are tons of debugging aids out there, and I'm sure all of us have our collection of routines and code snippets that we use to try to figure what the hell's going on in there, apart from Olly or some other real debugger.

Well, here's another tool I came up with. I like this one; it's a logging window you can attach to your program to display info while it's running. And I'm really kinda proud of myself at the moment because this is my very first DLL! All these years and I never tried it; one day and I got one running. Not right off the bat, of course, 'cuz I had to make the usual stupid mistakes first ...

I opted for a DLL because I wanted to have minimum intrusion into the code being debugged; don't like having to link in extra modules, and I also don't like having to insert huge swaths of code to display stuff. This tool is, I think, a pretty good compromise. I call it LogBuddy.

Here's now it works:

1. You insert some minimal code into your program you want debugged: the header file at the top:

Code Select Expand


include LogBuddy.inc


and a not-too-big stub module at the end:

Code Select Expand


include LogBuddyStub.asm


2. In your code, you first need to initialize LogBuddy--this loads the DLL and gets all the procedure addresses in it:

Code Select Expand


CALL LogBuddyInit


3. At the point where you want the logging window to appear, you start LogBuddy like so, which creates the logging window:

Code Select Expand


INVOKE LogBuddyStart, OFFSET OurWinTitle ;or pass NULL to use the default window title


4. Now you can use it to log stuff. You have the following functions at your disposal:

• LogBuddyLogMsg():  Logs Windows messages (WM_xxxx)
• LogBuddyDumpMem():  Gives you a standard hex/ASCII memory dump display
• LogBuddyAddText(): Adds any text you want to the log
• LogBuddyAddSeparator():  Puts a visual separator in the log
• LogBuddyClearLog()
• LogBuddyLogVar():  Writes an item, "<var> = <value>" to the log in any of several formats
• LogBuddyWriteToFile()

These are all implemented through small stub routines in your code that call the DLL routines (using push-push-call). The stub checks for errors, so if the DLL isn't loaded for some reason it'll report that and prevent you from trying to call through null pointers.

The DLL can go in whatever folder your program is running from.

The log window has some toolbar buttons in it for interactive control as well. One nice feature is that if you're logging messages and you start getting overwhelmed by a flood of them, you can turn off logging, and turn it back on later.

Anyhow, maybe someone wants to give this a try. All the files should be in the .zip.

This is not finished. Several missing things and some issues:
1. Write to file is not yet implemented.
2. This only works with 32-bit assembly-language code. Later I might add support for C, but since I don't use 64-bit, probably won't do that. But when it gets closer to being finished I'll post my complete code here and you can modify it yourself.
3. I plan on improving the message logging to include WM_NOTIFY notifications and other additional information.
4. I still haven't gotten how to scroll my edit control (a RichEdit) to the end when I add stuff to it so the last info added is visible. Any advice here would be appreciated.
5. Still need to refine the clean-up phase, make sure all handles are released or deleted, etc. So far, I haven't noticed any major problems. Of course, the last thing you want is a buggy debugging tool!

Oh, and I managed to get all the bitmaps into the DLL without using any resource stuff. (Like someone here said, "Look Ma, no resources!") That BMP loading routine I came up with is a killer.

[jj2007]

cannot open file : \masm32\include\my_masm32rt.inc

It is also good practice to use the full path for ML and LINK, instead of relying on environment variables:

\Masm32\bin\ml /c /coff /Fl /Sg /Sn LogBuddyTest.asm

[NoCforMe]

Damn! I keep forgetting that.

I'm just so tired of having to wrap those include files with .nolist ... .list. Why the hell didn't whoever wrote those put those lines in? Nobody wants to see 10,000 lines of crap in their listing file.

And really, is there one single person here who uses this stuff who doesn't have their path set to \masm32\bin? (Or more specifically, who doesn't have their path set to the folder where those executables are, wherever that happens to be.)

Update .zip in previous post.

[hutch--]

I get the most useful information with the /EP option. Trick is to put an easy to find pattern in the source then open the editor on the /EP output file, search for the pattern string and you get past all of the include data.

[NoCforMe]

You mean you see all that stuff in your listings? No thanks. Life's too short for that.

[jj2007]

I'm just so tired of having to wrap those include files with .nolist ... .list. Why the hell didn't whoever wrote those put those lines in? Nobody wants to see 10,000 lines of crap in their listing file.

Just don't use the /Fl option. The RichMasm source assembles in 8 seconds with that option set, 2.5 seconds without; and it generates 14MB listing. There are very few situations where I have to see that listing.

And really, is there one single person here who uses this stuff who doesn't have their path set to \masm32\bin?

Yes, me. Plus every n00b who just installed the Masm32 SDK. Environment variables are DOS era; there is a reason why the SDK has the hard-coded \Masm32\bin path: it just works, out of the box, always. Unless some n00b insists to use C:\Masm32\bin, while C: is not my Masm32 drive.

[NoCforMe]

There are very few situations where I have to see that listing.

So what do you do when you get assembly errors? or doesn't that happen for you?

[jj2007]

There are very few situations where I have to see that listing.

So what do you do when you get assembly errors? or doesn't that happen for you?

It happens all the time to me

When it happens, RichMasm jumps to the offending line, and I see immediately the "missing bracket" or whatever was the reason. On very rare occasions, I need the full listing, and then a simple case-sensitive search for Error A points me to the problem. Or it doesn't, sometimes the assembler emits the error message to the console (where the editor picks up the offending line) but "forgets" to write Error A1234 to its 79MB listing.

[hutch--]

 

> You mean you see all that stuff in your listings? No thanks. Life's too short for that.

No, you have read it incorrectly, when yo use the /EP option, you get all of the includes so you put an easy to find pattern in the beginning of YOUR source.

; xxxxxxxxxx    ; or anything else you like.

Do a search for this pattern, you jump over all of the includes, but a /EP listing makes more sense with less garbage.

[zedd151]

And really, is there one single person here who uses this stuff who doesn't have their path set to \masm32\bin?

There are quite a few actually. There is a requirement of the Masm32 SDK that it be in the root of a drive. This simplifies things from the perspective of the SDK.  As far as actually setting "PATH= xxxxxx" to include the paths to the masm32 binaries, I would'nt do that. But certain that others may tend too do things 'their way'.
At any rate, I'll check out the .dll later today ...   

I truncated this post from a much longer version. I didn't want it to sound like a rant.    So nevermind if you had read the original extended post. 

[zedd151]

Upon looking at the test piece for the dll, it seems that the dll mostly catches WM_xxxx mesages. I am not sure if I have any practical uses for the dll debugging tool at the moment, but will test it when I do find a possible need for it. As far as using the options that you listed, could you elaborate if possible.

[NoCforMe]

Sure, although I though I pretty much spelled it out in the original post. You can show

• A memory dump, in standard 16-bytes-per-line hex/ASCII format
• The value of a single variable ("XXXXX = YYYYY"), in signed/unsigned int, hex or string format
• Any text you choose (which could include variable values)

That's pretty much it, apart from some niceties like visual separators in the log. This is not a debugger, simply a debugging aid.

I could add timestamps to it for those who want to check timing; do you think that would be a good idea?

[hutch--]

Z,

As far as fixed paths, once you have had to deal with hundreds who did not read the installation instructions and turned up here with the normal "It Dozen Wurk", Fixed paths on installation solved the problem and it also made posting code between members a lot easier and compatible.

When you get code posted that uses something else, its a case of whether you could be bothered testing it.

[NoCforMe]

Since you continued this discussion of paths, Hutch, consider this: Yes, I have MASM installed in the "right" place, (x):\masm32, where (x) is a drive other than C:. So far, so good.

But I use what I'll bet a lot of people here use, if not most of us: a command window for assembling and linking. (Rather than the default dumbass Windows "cm.exe", I use much nicer one, 4DOS, that I've been using since 1990.) And it allows me to set paths, something that still works under Windows 10 and is still useful. So if I need to fire up the assembler, linker or librarian, I can just type "ml xxxxxx" or "link xxxx" without having type the complete pathname (\masm32\ml, etc.). Now and then I need to see what all the options are for these programs. See how that works?

I'm just curious, how many people here have paths set to the masm32 executables? Show of hands?

(btw, this makes me wonder about some of Micro$oft's tools. Anyone else notice how every time you run lib it totally messes up the command window, so you have to issue a cls command to clear the screen?)

[hutch--]

Hi David,

The problem is that CMD.EXE is installed on every computer that will run 32 bit PE files and it runs command line apps with no problems at all. Most have heard of 4DOS but you would struggle to get above a 0.00000000000000? user base in comparison to CMD.EXE.

You can also bypass any command prompt by using CreateProcess() and create a binary that calls any of the Microsoft command line tools and this is how most of the IDE's do it but you don't want to be limited to any one particular IDE.

A batch file is a solution that can be run directly from the command line, you don't need any editor or IDE and you can run any command line option you want, all you have to do is write it.