9.4.3- The Microsoft Script Debugger

<< 9.4.2- Conditional Tracing

Chapter9

9.4.4- Client-side versus Server-side Debugging >>

The Microsoft Script Debugger

There is also a ready-made tool that you can use to help you debug, namely the Microsoft Script Debugger. Why didn't you tell us about it earlier, I hear some of you cry exasperatedly? That's because you can still use the techniques I've just mentioned along with the Debugger. The Microsoft Script Debugger is a separate application to IIS 5.0 and comes with Windows 2000. We looked at its installation in Chapter 1 . This debugger seems quite basic at first, but don't be fooled – it is actually quite powerful. Before you can debug ASP script code you need to mark your virtual directory as an application and enable the server-side debugging option within IIS.

 

In addition to Windows 2000, the Script Debugger is also compatible with Windows Server 2003 and Windows XP. Although it is no longer a supported product, Microsoft does still have it available for download. Microsoft's newer version is now called Microsoft Script Editor and shipped with Office XP.

 

Enabling Debugging in IIS

An application is a virtual directory, with a few more features. As well as allowing debugging, it also allows ASP to know the whereabouts of your Global.asa file. You can tell whether a virtual directory is an application or not by looking at the icon in the Management Console (to start this up, from the Start menu, select Run; in the resulting dialog, type MMC and press OK). Normal virtual directories, such as Scripts and Printers, are shown as a folder with a tiny blue world, whereas applications, such as IISSamples and Webpub, are shown as a little open box.

 

In Chapter 1 we took our physical directory, BegASPFiles, and used the Virtual Directory Creation Wizard to create a virtual directory, BegASP. Our virtual directory appeared as a little open box. This is because the wizard automatically creates an application for us. To turn a normal folder into an application, without the wizard, right-click on the folder and select Properties; then on the Directory tab, click the Create button to turn the folder into an ASP application:

 

When you create an application it allows you to enter a name in the Name box, but more importantly, from the Properties Dialog in the Management Console, you can click on the Configuration button to access the application details, and then click on the App Debugging tab:

 

 

The Debugging Flags section is the one we are interested in. The first option is the most important as checking this allows the Script Debugger to be used for ASP script code. Make sure this is checked before you continue with the next example. We're not examining client-side debugging, so it doesn't matter whether this is checked or cleared.

 

Using the Script Debugger

Before we start debugging, let's look at the various windows in the script debugger:

 

 

The Call Stack window displays a list of active procedure calls. The combo box at the top of this window displays the current threads, and is generally only used if you are debugging Java applets.

 

The Running Documents window displays a list of applications, along with their documents, that are hosting scripting (non-hosting scripting documents are not included).

 

The Command Window allows you to inspect and modify variables during the execution of the script code.

Starting the Debugger

So you've set the application up for debugging, and we've shown you what the debugger windows look like. Now, how do you actually start the debugger? The debugger is actually located on the server-side, but can be run in one of four ways:

 

• The first is the most obvious, by selecting it from the Programs menu under Accessories.
• You can also use the Script Debugger option from the View menu in Internet Explorer (if you have MS Visual InterDev 6.0 installed, this command will start it).
• You can force the debugger to start by placing a Stop statement (or debugger in JScript) in your script code. Note that this statement will have no effect if debugging isn't enabled.
• Lastly, you can respond to an error. Remember the ASP error shown earlier, where a dialog popped up and asked us whether we wanted to debug the current page? Selecting Yes will start the debugger.

 

It's important to remember that to debug server-side ASP script the debugger needs to be open on the web server. So if you access an ASP page with an error from a client machine, then the debugger dialog will appear on the web server. Your client page will be blank, and will suspend operation until the error dialog is cleared or the page reaches its timeout value.

 

Now you know how to set up debugging and how to start the debugger, it's time to see how it works.

Using the Script Debugger

The best way to learn how to debug scripts is to actually try it, so we'll jump straight in now. What we're going to do is create a script with some errors and then you'll see exactly how this works.

During this Try It Out, don't worry if your browser displays a Timeout error message, stating it can't contact the server. It's lying. It can and has contacted the server, but we'll be using breakpoints, so the script may not complete before the time allocated for a timeout expires. You can just close the error dialog and continue.

 

1.    Create a new asp file, calling it Debug.asp.

 

2.    Add the following code. Note – copy this code exactly. There are deliberate errors in it, so don't correct them as you type it in.

 

<HTML>

<HEAD>

<TITLE>ASP Debugging with the Script Debugger</TITLE>

</HEAD>

<BODY>

 

<%

  strVar = Request.ServerVariables("HTTP_USER_AGEN") & "<P>"

  Response.Write "HTTP_USER_AGENT=" & strVsr

  ShowVariables

 

Sub ShowVariables

 

  For Each strVar In Request.ServerVariables

    Response.Write strVae & "<BR>"

  Next

 

End Sub

%>

</BODY>

</HTML>

 

3.    Run the file from your browser, and you should see this:

 

 

Now it doesn't work, but then you knew that already. So where are the errors, and how do you find them using the Script Debugger?

 

4.    Start the script debugger (on the server, if this is separate from the machine you're creating pages on), and from the View menu select Running Documents:

 

 

5.    Expand both the Microsoft Internet Explorer and the Microsoft Active Server Pages levels, by clicking on the small plus signs. You might have to keep expanding these items if there are more under the ASP branch:

 

 

This shows that the script debugger is now attached to both IE and IIS, and it shows the current documents. Two copies of Debug.asp are shown, highlighting the two places where scripting can take place – at the client, shown under Microsoft Internet Explorer, and at the Server, shown under Microsoft Active Server Pages. It also shows a global.asa file, which was used in a previous example and previous chapter and has no bearing in this example. If you can see any other .asps, then this is because the sessions involved on these pages haven't timed out yet.

 

6.    We are interested in ASP script so double click on the Debug.asp under Microsoft Active Server Pages. This will open the ASP page:

 

 

Notice that the title states that this is read only. This is because the Script Debugger only allows us to follow the script through and not actively change it. We can change variable contents though, as you'll see soon.

 

7.    Place the cursor on the first Response.Write line and press F9 to toggle a break point. Notice that the line is highlighted in red, with a large dot to show a breakpoint.

8.    Switch back to your browser and press the Refresh button. You are either automatically switched into the Script Debugger, with the current highlighted line the one on which there is a breakpoint, or the corresponding application on your task bar will flash, and you will be switched to debugger when you click on it.

9.    From your first run of this script you noticed that nothing was printed for strVar, but why? Well, you've probably spotted that the second time we use the variable we've spelt it incorrectly, putting strVsr instead of strVar. Because the script debugger only gives us read only access to the script we can't change the variable name, but we can check that strVar is correct.

10.  From the View menu select Command Window.

11.  Type ?strVar, pressing the enter key after you have typed this in:

 

 

The question mark is how we tell the debugger that we want to print out (in the command window) the value of a variable. Now look at what the value is. Not what was really expected, but that's because we've also made another spelling mistake in the name of the server variable we wanted to look at – there's a T missing from the end.

 

You don't need to use the question mark to print out values when you are debugging Jscript – you can just type the variable name.

 

12.  Once again we can't modify the script, but we can modify the contents of the variable, so type this in – note there's no question mark here. Don't forget to hit the Enter key after you've typed it in:

 

strVar = Request.ServerVariables("HTTP_USER_AGENT")

 

This assigns strVar to the value of the server variable, using exactly the same syntax as if you were typing the script in. In fact, you type using the syntax of the current script language – in our case this is VBScript. Now examine strVar again:

 

 

That's better – much more like we expected. You can also update strVsr, just so that the variable is returned to the browser, by typing:

 

strVsr = strVar

 

13.  Now you've updated this variable, click back into the main script window and press F8 to step onto the next line.

14.  Move the cursor to the second Response.Write line and press F9 to set another breakpoint. Now press F5 – this continues executing script until it finds another breakpoint, or it finishes the script.

15.  As the script has stopped at the second breakpoint we are now in a function, so it's a good time to look at the call stack. From the View menu select Call Stack.

 

This shows where we are in the code, with the most recent procedure at the top. You can see we started in a set of global code, with no procedure, and then moved into the ShowVariables procedure. You can double-click on an item to get the main script window to show you exactly where you are in the code. For example, if ShowVariables was called several times, but you'd lost track of which time it was, you could double-click on the VBScript global code line to show which call it was:

 

 

Notice the arrow in the margin, pointing to the calling routine. This doesn't change the currently executing line, so pressing F8 will switch you back into the ShowVariables routine and continue executing, one line at a time. As you're in a loop that iterates through the whole of the Server Variables collection, you'll have to hit Next quite a few times to get to the end of it!

 

16.  You'll also notice there is a spelling mistake on this Response.Write line, but because this is in a loop, it's not really practical to change this every time. At this stage you are best served by either continuing, even with the error, or stopping the script by selecting Stop Debugging from the Debug menu. These sort of spelling errors are much more easily caught by using Option Explicit to force all variable names to be declared, and any variable not declared generates a run-time error.

That's really all there is to using the Script Debugger. You can see that it's quite a simple tool, but very effective, allowing you almost everything you could expect from a more high-powered tool. If you make syntax errors in your script code, then the Script Debugger will be launched automatically, showing you the line with the problem.

<< 9.4.2- Conditional Tracing

Chapter9

9.4.4- Client-side versus Server-side Debugging >>