Debugging Your First Script

Microsoft offers a free script debugger from www.Microsoft.com/scripting. After you download and install the debugger, it will be available for the scripts that you write. In Figure 2.17, I've started the debugger, loaded WhoHas.vbs, and started execution. As you can see, the first line of code is highlighted, meaning the debugger is waiting to execute that code (it automatically skipped the very first line of text, which is just a comment line).

At this point, I can press F8 to execute just the highlighted line of text. Doing so displays an input box requesting the server name; after I provide that and click OK, the debugger jumps to the next line of text. A distinct disadvantage of the Microsoft Debugger is its lack of access to variable contents; in the VbsEdit debugger, I could hover my mouse over the varServer variable to verify that it contains whatever server name I had typed.

I can keep pressing F8 to execute each line of code, one at a time, until I run into the error again-as I do on line 10. Time to look at line 10 more carefully.

The problem, in fact, is the word lamanserver. It should be lanmanserver, with an "n" after the initial "la." Correcting that lets the script continue normally.

Often times, the debugger is the best way to see what "path" VBScript is taking. For example, your script might be behaving unexpectedly because you entered an incorrect logical comparison, perhaps typing ">" instead of "<" in a numeric comparison. Those types of errors won't necessarily generate errors-at least, not ones you'd be able to track down easily-but using the debugger can let you "walk" through script one line at a time as it executes and spot the location where the script's logic begins to go wrong.