Quick tip: In-program debugging aid

[NoCforMe]

I don't know about you, but it seems whenever I write a program I end up with bugs that I need to track down and stomp. Sometimes a debugger (I use OllyDbg) works, but other times not even a real debugger will help much.

Over the years I've come up with several debugging aids of my own; this latest one is really simple, yet quite effective at finding out what's going on inside your code. It's a window in the program (assuming your program is a GUI app, not a console app) that can display text to clue you in. Here's my recipe:

1. Create an edit window in your program's main window or dialog. Make it big enough to show the text you'll be displaying; multi-line assumed here. Make it read-only (no need to have it accept typed-in input). Make the control multi-line with a vertical scrollbar:

Code Select Expand

window style = WS_CHILD or WS_VISIBLE or ES_MULTILINE or ES_READONLY or WS_VSCROLL

Store the edit control handle in a global variable to make it easily accessible.

2. Create a function in your code to display text in the window. Here's mine:

Code Select Expand

;====================================
; LogResults()
;
; Appends text to an edit control.
; Handle to window is ResultsDispHandle.
;
; On entry,
;    EAX--> text to add
;====================================

LogResults    PROC
    LOCAL    textPtr:DWORD

    MOV    textPtr, EAX

; Set selection to the very end, add the text + CR/LF:
    INVOKE    SendMessage, ResultsDispHandle, EM_SETSEL, -1, -1
    INVOKE    SendMessage, ResultsDispHandle, EM_REPLACESEL, FALSE, textPtr
    INVOKE    SendMessage, ResultsDispHandle, EM_REPLACESEL, FALSE, OFFSET CRLFstr

; Make edit control scroll to the very end:
    INVOKE    SendMessage, ResultsDispHandle, WM_VSCROLL, SB_BOTTOM, 0

    RET

LogResults    ENDP

To display text, set EAX to point to the text buffer, then call LogResults(). The function adds the text to the edit buffer, then scrolls to the end. You can scroll back through the text to see earlier output. I automatically add a carriage return/line feed for each item displayed so I don't have to add that to each display string.

Simple but effective.

Hints: for more bulletproof debugging, use PUSHA/POPA in any logging functions to preserve all registers. You can write specialized functions, or if you want to display one or a few variables, use something like this:

Code Select Expand

    LOCAL    buffer[256]:BYTE

    INVOKE    wsprintf, ADDR buffer, OFFSET <format string>, <variable(s) to log>
    LEA    EAX, buffer
    CALL    LogResults


[jj2007]

Can you post a working, complete example? Thanks.

[NoCforMe]

Sure, give me a day or two.

[HSE]

Hi NoCforMe!

I've come up with several debugging aids of my own;

In Masm32 SDK package you have VKim debug system.

What problem you see in VKdebug?

HSE

[NoCforMe]

Never used it. I'll have to take a look at it.

I'm guessing it's more than I need at this level; what I described here is a pretty low-level debugging aid. Doesn't show anything about processor state, memory, code, etc.
OK, I took a look at it. I'm sure it's a useful tool, but two things: first, it's not as easy to use as my method described here. With my debugging window, there's no installation required, just create the window (edit control) and send stuff to it. With VKDebug you have to install the package, learn how to use the various functions and macros, etc. Plus it uses the registry (ugh!).

Second thing is that I've already created a similar tool, called LogBuddy, which I've posted here previously. Don't know if mine measures up to the VK tool, but it works well. However, it's more complex and requires some "installation" (it uses a DLL).

Different levels of debugging for different needs.

[HSE]

I'm guessing it's more than I need at this level

Who care? You can use what you need.

[NoCforMe]

"Who care"? I care. I don't want to use a sledgehammer to kill a mosquito.

[HSE]

With VKDebug you have to install the package, learn how to use the various functions and macros, etc.

Of course, you think is more easy to reinvent the wheel

Must be clear for beginners that to use any tool requiere some learning, VKdebug is very easy and you have to install it just once.

You can do what you want, NoCforMe.

But nobody need to travel your personal calvary. 

[jj2007]

With VKDebug you have to install the package, learn how to use the various functions and macros, etc.

Of course, you think is more easy to reinvent the wheel

I checked my folders, and voilà, there it is: \Masm32\vkdebug\ - installed 30.10.2014. That's probably the day when I spontaneously decided to reinvent the wheel

Anyway, I am curious to see a working example from NoCforMe

[HSE]

there it is: \Masm32\vkdebug\ - installed 30.10.2014.

Perhaps that was a reinstallation.
 
VKdebug is in Masm32 SDK at least from 2008. I think a lot before, but I'm not sure.

[jj2007]

The readme.txt is dated 16.9.2002, so it's over 21 years old. For its time, it was probably a good tool, but there was a reason why I rolled my own: it's clumsy.

[HSE]

The readme.txt is dated 16.9.2002, so it's over 21 years old.

Yes, but I don't know when was added to package.

but there was a reason why I rolled my own: it's clumsy.

I also adapted a little to my taste, just that was superseded by ObjAsm32 Debug System  

[NoCforMe]

[...] but there was a reason why I rolled my own: it's clumsy.

Exactly. It always strikes me funny when people say "so why don't you just use (x) instead of reinventing the wheel?". Take my LogBuddy; don't know if you've tried it or not, but I think it's a pretty good debugging tool. Can show all or some of the messages a window receives, display variables, dump memory, etc. However, it takes a lot of setup to use: you have to put in a code stub at the end of your program code, initialize it, do some other stuff. Which is sometimes a pain in the ass. Hence this simple alternative to do minimal debugging. Takes a small amount of effort to put it in your code (the worst part is figuring out where to place a fairly sizeable edit control in your main window or dialog).

You asked and I agreed, so I will post a working example. I'm working on other things at the moment, though, so it'll be a little while.

[daydreamer]

NoCforMe, walking your own path, even if reinventing the wheel,is have fun while getting more skilled in new things

[TimoVJL]

DebugView / DbgWin.exe exists and usable with OutputDebugString

https://learn.microsoft.com/en-us/sysinternals/downloads/debugview