Sign in to follow this  
Followers 0
autoitter

Capture debug information UDF

9 posts in this topic

So, this is my first UDF that I like to share with you all. It can be used to capture debug information written by programs using the OutputDebugString API. A lot of programs write useful information using OutputDebugString.

I searched for a way to capture this information and came across this link. This describes a way to read debug information using C++. My first attempt was to try and rewrite this in pure AutoIt using DllCalls. But I guessed it was to much work, especially converting all the structures that are needed.

So I decided to take a different approach and use a helper DLL. I used the code by Randy Charles Morin and rewritten it as a DLL. Additionally I made a wrapper UDF.

I have put the DLL, UDF and a simple example of a viewer in this ZIP:

DebugCapture.zip

The DLL is written using Visual Studio 6. For those who are interested, I included the source:

DebugCaptureDLLSource.zip

The UDF contains 3 functions:

_StartDebugCapture()

This function loads the helper DLL and starts the capturing process. As soon as this function successfully returns, you have to call _GetDebugOutput() regularly to read the debug information. If you don't read the debug information, you will block the processes trying to write this information for a while (the OutputDebugString() API will block for a maximum time of 10 seconds).

_StopDebugCapture()

Call this function if you don't want to process debug information anymore.

_GetDebugOutput()

Call this on a regular basis, to read the debug information. The function is non blocking. If there is nothing to read it will just return an empty string. If you call this function with no parameters it will return all debug information. Optionally you can call it with a PID (for example returned by Run). That way you will only get the debug information written by that specific process. @extended is always set to the PID of the process that outputted the information.

That's about it. Hope it's useful. Comments and suggestions are welcome!

Steve

1 person likes this

Share this post


Link to post
Share on other sites



Great

I miss the other part ... How to send an OutputDebugString from AutoIt ? :P

Share this post


Link to post
Share on other sites

Hi all,

Quite an old post, but I'm wondering if anyone can get this to work still? I'm getting no debug lines being displayed - the debug DLL seems to be starting/ending the debug capture, but no strings are being returned on the debug event.

Any ideas?

Regards,

Andy

Share this post


Link to post
Share on other sites

It should still work. Just tested using the latest release version of AutoIt (v3.3.4.0) and found no problems. Also tested with Windows 7 and it looks like that is working fine also.

Are you sure that anything gets written using OutputDebugString?

Share this post


Link to post
Share on other sites

Hi,

Ah, that's strange. I just tested on this machine (which is different from the one I was testing on last night) and it works fine.

Must be my bad. I'll re-test on the original machine tonight and re-post here with an update.

Thanks autoitter,

Andy

Share this post


Link to post
Share on other sites

#8 ·  Posted (edited)

Try merging this registry entry on your problem machine and rebooting. This is a known change in Vista/7.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter]
"DEFAULT"=dword:ffffffff
Edited by wraithdu

Share this post


Link to post
Share on other sites

Oh I'm such an idiot. I was running the compiled older version of the script, not the newer version of which I was in mid-development. Guess which one didn't have the outputdebugstring function...?

Thanks for your help all, and sorry to be such a pain.

Wraithdu - that's good to know. I'm using a modified version of the debug viewer to capture only strings from my software, and giving it to customers to help diagnose problems (such as the infamous "error in line -1" error). It's always useful to know where things are different from XP, which I develop on. Much appreciated.

Regards,

Andy

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0