The Microsoft Script Debugger (MSD) lets you look at Web-based code to find errors and determine optimizations. MSD is a debugging application that works with any application that utilizes ActiveX, such as Internet Explorer (IE), Internet Information Server (IIS), or even Excel and Word. In this Daily Drill Down, I’ll walk through the installation and basic functions of MSD.

What can MSD do for me?
MSD is a debug environment that allows you to walk through code that is currently running on the system. If you’re familiar with debuggers, you might have a good understanding of what this will give you in your programmer’s bag of tricks. If you’ve installed IIS on your server, the script debugger is an option that Setup installs automatically. If you’re dealing with the basic installation on a Windows workstation running IE, you’ll need to install it via a download, which I’ll explain below.

The main question that MSD helps to answer is “Why isn’t my script working?” Or, more precisely, “On what line is it not working?” If MSD could answer the question fully, there wouldn’t be a need for programmers—computers could fix themselves, and we could all go on vacation.

Within IE and IIS, you can use MSD to browse your source code, edit the code, and debug HTML that contains scripts on both the client and server side. This will allow you to produce better scripts and it will give you a better understanding of the underlying system and how user input can affect your scripting.

But that’s not all MSD does. Using keywords in your scripts, you can control the speed at which your script runs, depending on the type of script you use. You can also make the script pause to see where it waits for debugger input. You can create input variables at these stop points or prior to the initialization of the script. With some add-ons, you can debug PerlScript and Jscript. It’s also possible to use MSD to debug HTML and XML, however I’ve found that the HTML debugger in Mozilla (www.mozilla.org) is better adapted to that chore.

You should test scripts on a test server and not on a production site. Script debugging adds overhead to the server, which you don’t need. Also, you’ll want to use passwords to protect the sites that you send ASP-client debug information to. Leaving them unprotected could create a security hole for your applications. After you’ve tested your scripts in a test environment, you can move them to production.

Where can I get MSD?
There are two versions of MSD available for the Windows operating systems: one for Windows 98/ME and one for NT4, 2000, and XP. For 98/ME, you’ll need to download the software from Microsoft. You can download both versions from MSDN online. For Windows 2000 and XP, you can install the MSD from the Control Panel. Select Add/Remove Programs and then click Add/Remove Windows Components. Follow the Windows Components Wizard as shown in Figure A.

Figure A
Select the 1.1 MB Script Debugger application.

Give the debugger access
After you install MSD, you must configure IE to support it. In IE 6, the debugger is activated by default; however, your settings may have changed due to a policy statement or an administrator deactivating it. To make sure that script debugging is enabled in your browser, click Tools | Internet Options | Advanced. You’ll then see the screen shown in Figure B. Remove the check from Disable Script Debugging. The debugger is now installed on your system for client debugging.

Figure B
Uncheck Disable Script Debugging in IE 6 under Tools | Internet Options | Advanced.

As for IIS, the debugger is usually installed by default on the server. If not, check the same location as above in Control Panel to make sure that it’s installed, and then activate it on the server. You must also enable debugging for each application, or the debugger won’t have access to the data from the application. This might seem a bit odd, but it also keeps others from running the debug application without proper permission.

You can activate debugging for your scripts in IIS 5.0 by going to the IIS MMC snap-in. Right-click your Web site and select Properties. When the Properties page for your Web site appears, click Home Directory. Click the Configuration button. This will display the Application Configuration dialog box shown in Figure C. Under the App Debugging tab, activate the Debugging Flags.

Figure C
These options are located in the IIS MMC of the Web site in which you want to enable debugging.

Sample debugging of a VBSCRIPT
There are two ways to use the debugger. One way is for client-side code. The other is by using server-side ASP and your global.asa file, which I’ll explain below.

On the client side, you can launch the debugger from within IE’s View toolbar, either automatically by using code keywords or by a debug prompt from broken code. On the server side, after you enable debugging for the application, you’ll open the debugger from the Start menu. To run the debugger on the client system, select View | Script Debugger | Open in IE. This will load the current HTML page into the debugger application. Your HTML and script code will load into a window in the debugger application.

If you’re looking at ASP code on the server side, you’ll need to launch the debugger from the Start button. Click Start | Programs | Accessories | Microsoft Script Debugger | Microsoft Script Debugger to start the debugger for your script. Once the debug application has started, you can use the File menu to open an existing document that contains the script to be examined, or use the Running Documents toolbar icon to get a list of currently active application scripts. When you load the script, you’ll see the screen shown in Figure D.

Figure D
MSD helps you discover errors in scripts.

The debug toolbar consists of three sections: File, Edit, and Debug. The File section is self explanatory as if offers the common Windows file operations. The Edit section is also familiar as it offers the basic options of Cut, Copy, and Paste, as well as selecting all and searching through the code that is currently highlighted. Other choices in the debug toolbar are:

  • Run—This allows you to execute your code from the beginning.
  • Stop Debugging—Yes, this will stop the debugging process, and applications that are running in memory will cease. If you have an HTML page loaded with your example, you won’t see much happen as this is for timer-looped code.
  • Break At Next Statement—This is to stop the execution of your code at the next line of code, which allows you to step through your code line-by-line to make sure all is well.
  • Step Into/Step Over/Step Out—These three buttons allow you to go into subroutines within your code. If you’re satisfied the problem doesn’t lie in the subroutine, you can step over them and not execute them. Since you have control over your variables, you shouldn’t have to execute your subroutines.
  • Toggle Breakpoint/Clear All Break Points—This allows you to set where the code will stop working once you execute it in the debugger. This is helpful because, if you know approximately where the error is occurring, you can set your break prior and jump to that point without executing your entire script again.
  • Running Documents—This allows you to select the ActiveX script running on your system from any debugging host application, such as IIS, IE, or even Microsoft Outlook. If you’re debugging a Java script, you can select the function that is currently running in memory.
  • Call Stack—This will give you a list of the called procedures that are currently running in your script. These procedures are subroutines, functions, event handlers, and other called functions in your program.
  • Command Window—This window gives you the ability to execute commands directly and get feedback on syntax and functionality. From this window you can query or change variable values while the script is running. If you halt the script, you can also change the running values defined in the script. You can also do a call object methods and execute procedures, just as in the script, without adding code to your script. Also, when this window is open, you’ll get debug output when the script is running memory. You can execute commands when you step to a breakpoint to pass on to the next set of code.

You can use comments in your script to track errors in logic. In a VBSCRIPT, you can issue the statement STOP. This will cause the debugger to automatically stop the execution of the program and load that VBSCRIPT into the main window. In JAVASCRIPT you would issue the debugger command for the same response. With Javascript, you must have the developer’s version of the VM loaded in order to get correct debugger output.

When you encounter a script error in IE, you’ll be prompted about the error and asked if you want to open the debugger and determine what’s wrong with the code. This is sometimes fun when you stumble across a page on the Internet that has broken script code. You can use this option to determine what the Web author was doing incorrectly.

Here is some sample VBSCRIPT that you can use to see how the debugger works:
<HTML |
<HEAD |
<TITLE | Sample Code to get browser information via VBScript</TITLE |
</HEAD |
<SCRIPT LANGUAGE=vbscript |
<!– Begin
document.write navigator.appVersion
// End — |
</SCRIPT |
</BODY |
</HTML |

Just paste this simple code into Notepad, name it Sample.html, and open it with IE. You should see your browser version information displayed. Now click on View | Script Debugger | Open and the code will load into the debugger.

As mentioned earlier, if you enter the keyword STOP in the script section, IE will open the debugger and highlight the STOP that you issued. If there are multiple STOP keywords, you can step through each one, as shown in Figure E.

Figure E
In this example, I added the STOP keyword after the VBSCRIPT code, and you see it highlighted here.

Once the code is stopped, you can use the command window to look at variables. If necessary, you can change the values of variables to get a desired result. By stepping through each line of your code, you can determine where things are going wrong and the best way to fix them. If you copy each line that is next in line to be executed into the command window, you’ll get a response for the line of code. From this, you’ll know to continue with the next line or fix that broken line.

Debugging a global.asa file
The global.asa file is the grand script file for your IIS server. It’s an optional set of code for all of your scripts. This file contains the object declarations and methods that will be set for every ASP application. It’s also the default source for any type of scripting that you’re doing on your server, such as Javascript, VBSCRIPT, or PerlScript.

I won’t go too far into the syntax of the global.asa file’s settings, but you can create it using notepad.exe in the root of your application directory. You must restart the IIS server after you make any changes to this file for the server to detect the differences.

When debugging this type of file, there are a few things you should be aware of. First, you can’t call it from the client; it’s executed when you call the ASP application. This means you must be on the server to debug the file. The sections of the file are event-activated, unlike the procedures in an .asp file. Some of the events to be aware of include:

  • Application_OnStartruns when a user calls an ASP application.
  • Application_OnEndruns on the termination of the ASP application.
  • Session_OnStartand Session_OnEnd serve the same purpose, but on a session-by-session basis.

Second, if there’s an error in your global.asa file, the server stops the procedure containing the error. If script debugging is enabled for your application, the debugger will start and show the error message that it’s receiving in the debugger. If you don’t have debugging enabled for your application, the error is passed to the client system.

You can also include a VBSCRIPT STOP keyword or JSCRIPT debugger keyword to enact the debugger from the global.asa file. You debug your global.asa file in the same manner as your other scripts—just watch out for the small differences, like restarting the server.

After all that
It’s as simple as that. The real skill is your knowledge of your scripting language, and knowing how to access the relevant reference materials to evaluate what might be happening in each command. That’s where things get a little complicated.

Hopefully you’ll use MSD on a daily basis to determine what’s wrong with your code, and where. This application is invaluable for cranking out production-ready script code.