Read Me
The purpose of this blog is to provide you with information that will help you during debugging sessions. The debugging toolbox I provide is a collection of Windbg scripts I created to help me on a daily basis. The collection expands whenever I develop a script to replace manual debugging.
The Windbg programming language looks like Perl.
To use the scripts you need to download Windbg and setup the public symbols. Actually not all scripts demand symbols, but it’s good to have them for your debugging session.
Most of the scripts should be executed using the following command from Windbg:
$$><path\scriptname.txt
The default directory I use is MyScripts, located inside the Windbg folder. If you want to use another location or another script file name, just change the source code to reflect the new location and/or file name.
In my machine the scripts are located at:
C:\Debuggers\MyScripts
You can think about the scripts like commands or extensions. My goal is not to teach you how to create Windbg scripts; however, if you want to learn how, check the Windbg documentation.
Although you have the source code, the commands and logic aren’t fully described. The reasons for this are the following:
- Sometimes I’m going to use pointers or offsets that are strictly related to our products, so I won’t discuss these. Besides, they can change anytime and break the script.
- Sometimes I’m going to use commands that aren’t clearly documented.
- Sometimes I’m going to work around the script limitations using some of my techniques. Although unlikely, I may change the Windbg scripts from time to time to make them use the new commands/instructions, thus avoiding work around.
- I also prefer not to explain the source code details for security reasons.
Common problems you may have:
- Syntax error: Usually happens when you have a line break in the wrong place.
- Syntax error when executing a script twice that uses custom alias: it’s a problem related to an alias. It will be fixed in the future, anyway, just call the script one more time and it'll run fine.
- Some rare scripts must be called using $$< not $$><. Check the header file comments; otherwise, you won’t have the correct results from the script.
- When you read something like “should work on 64 bits,” it means I didn’t test it on 64 bit machines, but it should work based just on my guess.
- Some scripts are strictly version dependents so any product or OS update can break their functioning.
- I couldn’t test them on different Windows versions; therefore, you could have problems in some OS versions. Most of the time I create and use them on Windows XP SP 2 and Windows Vista.
- For scripts that requires symbols use: .reload /f just once before running the script.
Before running a script you should read the header information in the source code.
Also remove any extra spaces between lines after copying the source code.
If you have problems or find a bug let me know.
If you have an idea you think might be cool for scripting let me know, too. J I’m interested! I just cannot promise I’ll implement all suggestions.
I hope you enjoy my little toys as much as I enjoy creating them! J
