Debugging ASP Applications in IIS

Regardless of your level of experience, you will encounter programmatic errors, or bugs, that will prevent your server-side scripts from working correctly. For this reason, debugging, the process of finding and correcting scripting errors, is crucial for developing successful and robust ASP applications, especially as the complexity of your application grows.

The Microsoft Script Debugger Tool

The Microsoft Script Debugger is a powerful debugging tool that can help you quickly locate bugs and interactively test your server-side scripts. You can do the following things using the features of Microsoft Script Debugger:

• Run your server-side scripts one line at a time.

• Open a command window to monitor the value of variables, properties, or array elements, during the execution of your server-side scripts.

• Set pauses to suspend execution of your server-side scripts (using either the debugger or a script command) at a particular line of script.

• Trace procedures while running your server-side script.

Enabling Debugging

Before you can begin debugging your server-side scripts, you must first configure your Web server to support ASP debugging.

To enable server-side debugging using IIS Manager:

1. In the Properties pages for any Web site or Web virtual directory, click the Home Directory or Virtual Directory tab.

2. Under Application Settings, click Configuration. An application must be created for the button to be active.

3. Click the Debugging tab.

4. Select the Enable ASP server-side script debugging check box.

To enable server-side debugging programmatically using ADSI in a VBScript script, use the following code example:

' Connect to an object for the Web service, Web site, virtual directory or Web file. 
' In this case, we're connecting to the root virtual directory of the Default Web Site. 
Set IIsWebVirtualDirObj = GetObject("IIS://localhost/W3SVC/1/Root") 

WScript.Echo("Before: AppAllowDebugging = " & IIsWebVirtualDirObj.AppAllowDebugging) 

' There are multiple ways to set a property: 
'IIsWebVirtualDirObj.AppAllowDebugging = True 
IIsWebVirtualDirObj.Put "AppAllowDebugging", True 
IIsWebVirtualDirObj.SetInfo 

IIsWebVirtualDirObj.GetInfo 
WScript.Echo("After: AppAllowDebugging = " & IIsWebVirtualDirObj.AppAllowDebugging) 

After enabling Web server debugging, you can use either of the following methods to debug your scripts:

• Open Script Debugger and use it to run and debug your ASP server-side scripts.

• Use Internet Explorer to request an .asp file. If the file contains a bug or an intentional statement to halt execution, Script Debugger will automatically start, display your script, and indicate the source of the error.

Scripting Errors

While debugging your server-side scripts you might encounter several types of errors. Some of these errors can cause your scripts to execute incorrectly, halt the execution of your program, or return incorrect results.

Syntax Errors

A syntax error is a commonly encountered error that results from incorrect scripting syntax. For example, a misspelled command or an incorrect number of arguments passed to a function generates an error. Syntax errors can prevent your script from running.

Run-Time Errors

Run-time errors occur after your script commences execution and result from scripting instructions that attempt to perform impossible actions. For example, the following script contains a function that divides a variable by zero (an illegal mathematical operation) and generates a run-time error:

<SCRIPT Language= "VBScript" RUNAT=SERVER> 
  Result = Findanswer(15) 
  Document.Write ("The answer is " &Result) 

  Function Findanswer(x)  
  'This statement generates a run-time error. 
   Findanswer = x/0       
  End Function 
</SCRIPT> 

Bugs that result in run-time errors must be corrected for your script to execute without interruption.

Logical Errors

A logical error can be the most difficult bug to detect. With logical errors, which are caused by typing mistakes or flaws in programmatic logic, your script runs successfully, but yields incorrect results. For example, a server-side script intended to sort a list of values may return an inaccurate ordering if the script contains a > (greater than) sign for comparing values, when it should have used a < (less than) sign.

Just-In-Time (JIT) Debugging

When a run-time error interrupts execution of your server-side script, the Microsoft Script Debugger automatically starts, displays the .asp file with a statement pointer pointing to the line that caused the error, and generates an error message. With this type of debugging, called? Just-In-Time (JIT) debugging, your computer suspends further execution of the program. You must correct the errors with an editing program and save your changes before you can resume running the script.

Breakpoint Debugging

When an error occurs and you cannot easily locate the source of the error, it is sometimes useful to preset a breakpoint. A breakpoint suspends execution at a specific line in your script. You can set one or many different breakpoints in Microsoft Script Debugger before a suspect line of script and then use the debugger to inspect the values of variables or properties set in the script. After you correct the error, you can clear your breakpoints so that your script can run uninterrupted.

To set a breakpoint, open your script with Script Debugger, select a line of script where you want to interrupt execution, and from the Debug menu choose Toggle Breakpoint. Then use your Web browser to request the script again. After executing the lines of script up to the breakpoint, your computer starts the Script Debugger, which displays the script with a statement pointer pointing to the line where you set the breakpoint.

The Break at Next Statement

In certain cases, you may want to enable the Script Debugger Break at Next Statement if the next statement that runs is not in the .asp file that you are working with. For example, if you set Break at Next Statement in an .asp file residing in an application called Sales, the debugger will start when you run a script in any file in the Sales application, or in any application for which debugging has been enabled. For this reason, when you set Break at Next Statement, you need to be aware that whatever script statement runs next will start the debugger.

VBScript Stop Statement Debugging

You can also add breakpoints to your server-side scripts written in VBScript by inserting a Stop statement at a location before a questionable section of server-side script. For example, the following server-side script contains a Stop statement that suspends execution before the script calls a custom function:

<%  
  intDay = Day(Now()) 
  lngAccount = Request.Form("AccountNumber") 
  dtmExpires = Request.Form("ExpirationDate") 

  strCustomerID  =  "RETAIL" & intDay & lngAccount & dtmExpires 

  'Set breakpoint here. 
  Stop 

  'Call registration component.              
  RegisterUser(strCustomerID) 
%> 

When you request this script, the debugger starts and automatically displays the .asp file with the statement pointer indicating the location of the Stop statement. At this point you could choose to inspect the values assigned to variables before passing those variables to the component.

Important Note:
Remember to remove Stop statements from production .asp files.

JScript Debugger Statement Debugging

To add breakpoints to your server-side scripts written in JScript, insert a debugger statement before a suspect line of script. For example, the following script includes a debugger statement that interrupts execution and automatically starts Script Debugger each time the script loops through a new value.

<%@ Language= "JScript" %> 
<% 
  for (var count = 1; count <= 10; count++) 
  {         
    var eventest = count%2 
    //Set breakpoint so that user can step through execution of script. 
    debugger                             
    if (eventest == 0) 
          Response.Write("Even value is " + count + "<br>") 
   } 
%> 

Remember to remove debugger statements from production .asp files.