The Script Debugging Process

See Also   Tasks

You can use the Microsoft Visual InterDev debugger to test scripts written in Microsoft Visual Basic Scripting Edition (VBScript) and Microsoft JScript. Debugging Web pages can be different than debugging in traditional development environments in these ways:

• Most Web applications consist of scripts that run on the client (in .htm) and on the server (in .asp files, the Global.asa file, and .cdf files).
  
  
• Scripts can be in different languages.
  
  
• Scripts can be mixed with HTML text.
  
  
• Many Web applications include not just scripts, but Java components such as applets and COM objects.

The Visual InterDev debugger allows you to debug in all of these scenarios. You can debug client script running in your local version of Internet Explorer.

Note   It is highly recommended that you do not use Active Desktop mode of Internet Explorer 4.0 when you are debugging.

To debug script running in Microsoft Internet Information Server (IIS) 4.0, you can run the debugger on your computer and attach it to a script running on the server. If the server is running on another computer, you can use remote debugging to debug script running there.

Note   For information about debugging Java components on your Web page, see the Java documentation on debugging.

Types of Errors

Debugging is about finding errors. When you work with script, you might encounter the following types of errors that require debugging:

• A syntax error occurs if you mistype a keyword, forget to close a multi-line command (such as DO à LOOP), or introduce a similar syntax error. If a script includes a syntax error, the script will not execute and an error message is displayed as soon as the browser or server processes the page.

  Note   In some programming environments, syntax errors are referred to as pre-processor, compilation, or compile-time errors.

• A run-time error occurs when a command attempts to perform an action that is invalid. For example, a run-time error occurs if you try to perform a calculation using a variable that has not been initialized. If a run-time error occurs, the script either stops or performs an exception routine.
  
  
• A logic error occurs when a script executes without syntax or runtime errors, but the results are not what you intended. For example, a script might prompt the user for a password, but then allows access to the application even if the password is wrong.

Working in the Debugger

The basic process of debugging scripts consists of these tasks:

• Start debugging by running the document you are currently working with in your web project, or by attaching the debugger to a document that is already running in a browser or on a server. You can also launch the debugger in response to an script error, which is called just-in-time debugging.
  
  
• Stop script execution by issuing a break command. You can also set a breakpoint in the script where the debugger will stop automatically. When you stop a procedure, its source is displayed.
  
  
• Inspect the state of the script by examining the values of variables or properties and the list of running procedures (the call stack).
  
  
• Control the execution of individual statements or procedures (stepping) and watch the effect both in your application and by watching the values of variables or properties.
  
  
• Skip over (step over) or walk through (step into) procedures called by the current procedure. If multiple procedures or threads are active, you can move to another one and proceed from there.

Note   You can't work with the debugger in Design view or Quick view of the HTML editor. To debug, switch to Source view.

To allow you to perform these tasks, the debugger includes these commands and windows:

• The Processes dialog box allows you to attach the debugger to a document that is already running in a browser or on a server, which can include scripts in pages that are not part of your Visual InterDev project. You can debug scripts running locally on your computer or attach to processes running on remote computers, such as an .asp file running on a server.
  
  
• The Running Documents window allows you to view a list of documents that are available to the debugger.
  
  
• The Source view window of the HTML Editor displays source code of the script or component you are debugging. If the script or component you are debugging is part of your current Visual InterDev project, you can fix errors, and then rerun the document to test it again.
  
  
• In the Visual InterDev HTML editor, you can set and clear breakpoints. After the debugger has reached a breakpoint, you can use commands on the Debug menu to step into individual lines in your script. If you reach a point in your script that calls another procedure (a function, subroutine, or applet) you enter (step into) the procedure or run (step over) it and stop at the next line. At any point, you can jump to the end (step out) of the current procedure and proceed to the next breakpoint.
  
  
• In the Locals window you can see the values of variables within the scope of the current procedure. You can also specify that you want the debugger to display the values of specific expressions, such as properties, by setting up watch expressions in the Watch window.

  To set and change values, you use the Immediate window. You can evaluate any expression in the window and can enter script commands and see their effect. You can also view and change values in the Watch window.

• Using the Call Stack window, you can move to any currently active procedure.

Understanding Script Processing

Understanding how client scripts are processed and how errors are handled can help you debug client scripts successfully.

Processing Client Script

Client script is processed by Microsoft Internet Explorer. The browser calls the appropriate runtime module to process VBScript scripts or JavaScript scripts.

Client scripts are initially parsed when the Web document is loaded into the browser. During this parsing phase, the browser reports any syntax errors that it finds.

After parsing a section of script, the browser executes it. Global or inline scripts, which are scripts that are not part of an event-handling subroutine or function, are executed immediately. Event-handling subroutines or functions, and procedures that are called by other procedures, are parsed immediately but are not executed until triggered by an event or called by another procedure.

Client script processing

If a run-time error occurs when a client script is executed, an error message is displayed and the script containing the error stops. Other client scripts in the document can still run (unless you use start the debugger). If the script containing the error is called again, the error message is displayed again.

Depending on the language you are using, you might be able to include statements in your scripts to trap runtime errors and run your own error procedures. For example, in VBScript, you can use the ON ERROR statement to establish error trapping. For more details, see the documentation for your scripting language.

Processing Server Script

Most server script is not event-driven. Instead, when an .asp file is requested, the server reads the page and processes all server script from top to bottom. This includes script that is inline with HTML text, as shown in the following diagram.

Server script processing

Not all server script is executed immediately. As with client script, server script can include functions and subroutines that are executed only when they are called from other procedures.

Global.asa files are a special case. The Application_OnStart and Session_OnStart procedures in these files are executed only once for an application and for a session. Therefore, to debug these events easily, you must embed debugging statements in the file. For details, see Debugging a Global.asa File.

Debugging Remotely

See Also

In addition to debugging scripts and processes that are running on your computer, you can debug those that are running on another computer. This is referred to as remote debugging. In Microsoft Visual InterDev, remote debugging is useful for debugging server scripts running in ASP pages on Microsoft Internet Information Server (IIS).

Ordinarily, to debug a server script in an ASP page, you would have to install Visual InterDev on the server and then debug scripts locally on that server. However, with remote debugging, you can attach the debugger running on your computer to a script running on the server and issue debugging commands across the network.

Note   If IIS and Visual InterDev are running on the same computer, you can debug server scripts without remote debugging.

For the most part, remote debugging is similar to debugging locally, except for these differences:

• You must perform some extra setup steps before you can use remote debugging.
  
  
• Only one user can use remote debugging on a server at a time.

The information below explains how to set up remote debugging, and then how to establish a remote debugging session.

Setting Up Remote Debugging

Remote debugging uses distributed COM (DCOM) to communicate between the client and server computers. You must therefore configure DCOM to allow a remote user to attach the debugger to a process there.

Note   To use remote debugging, you must have installed Microsoft Internet Information Server (IIS) 4.0 and configured it for remote debugging. You can do this from the server setup portion of the Visual InterDev installation process.

To configure DCOM for remote debugging

28. From the Windows Start menu choose Run, and then in the Open box type Dcomcnfg.exe at the prompt.
    
    
29. In the Distributed COM Configuration Properties window, select Machine Debug Manager, and then choose Properties to display the Machine Debug Manager Properties dialog box.
    
    
30. In the Security tab, choose Use custom access permissions, and then choose Edit.
    
    
31. In the Registry Value Permissions dialog box, choose Add to add users who have permission to use remote debugging.
    
    
32. On Microsoft Windows NT computers, return to the Security tab, choose Use custom launch permissions, and then choose Edit. Choose Add, and then add the users you added in Step 4.
    
    
33. Return to the Distributed COM Configuration Properties window, select MTS Client Export, and then choose Properties.
    
    
34. Repeat Steps 3 through 6.

IIS applications must also be configured correctly so that they can be debugged remotely, but Visual InterDev does this automatically when you start debugging a project that uses remote debugging. Specifically, Visual InterDev:

• Enables the IIS application's debugging options.
  
  
• Specifies that the IIS application runs in its own memory space (in COM terms, it runs "out of process").
  
  
• Sets up Microsoft Transaction Server (MTS) to allow you to attach the debugger to the Web application.

Running the Debugger Remotely

After configuring the server for remote debugging, you can debug on the server in much the same way you do locally.

Note   It is highly recommended that you do not use Active Desktop mode of Internet Explorer 4.0 when you are debugging.

There are two ways to start remote debugging:

• Launch a project using the debugger   This works just like debugging locally, except that Visual InterDev automatically attaches the debugger to the server and starts remote debugging.
  
  
• Attach to a process that is already running on the server   This is useful if you become aware of a server script problem while the application is running. You can detect an error in server script if the server returns error text instead of your page, or if the browser appears hung when you request an .asp file.

If you launch a project using the debugger, you can start debugging at the first line of script. Otherwise, you will only be able to debug script that runs after you attach to the process. In addition, if you launch a project, you will be able to edit the files you are debugging. When you attach to a process, you can see the files you are debugging, but cannot edit them there.

Note   Because remote debugging ties up process threads on the server, it is recommended that while a remote debugging session is in progress, other users avoid using the server.

If you want to launch a project using the debugger, you must make sure first that debugging is enabled for ASP pages.

To enable remote debugging in ASP pages

35. In the Project Explorer, right-click the project and choose Properties to display the Property Pages dialog box.
    
    
36. Choose the Launch tab.
    
    
37. Under Server script, select both options, Automatically enable ASP server-side debugging on launch and Automatically enable ASP client-side debugging on launch, and then choose OK.

After enabling remote debugging, you can launch the debugger.

To launch a project using the debugger

38. In Visual InterDev, open the file to debug, and if needed, set breakpoints.
    
    
39. Make the page your project's start page. In the Project Explorer, right-click the page and choose Set as Start Page.
    
    
40. From the Debug menu in Visual InterDev, choose Start.

    Visual InterDev starts the project and automatically attaches the debugger to the remote page. If another user is already debugging, Visual InterDev displays an error message.

    Note   The first page displayed will be the project's start page, which is not necessarily the page you were editing when you launched the project.

41. Navigate to the page you want to debug, which will execute the scripts on that page. When the script gets to a breakpoint, it will stop and display the page in the debugger. You can step through scripts and test variables and expressions normally.

If you detect an error while the application is running, you can attach the debugger to it.

To attach to a running process

42. If it is not already open, start Visual InterDev.
    
    
43. From the Debug menu, choose Processes.
    
    
44. In the Processes dialog box, type the name of the computer to attach to. If you don't know the computer name, choose Machine and use the Browse for Computer dialog box to locate the server where you want to debug.
    
    
45. In the machine processes list, select the choice that says Microsoft Active Server Pages followed by the process ID of the process you want to debug, and then choose Attach.

    The process you selected appears in the Debugged Processes list.

46. Close the Processes dialog box and use the Running Documents window to select the ASP page to debug.

    You can step through scripts and test variables and expressions normally. However, to run a page you must navigate to it in your browser. In addition, you cannot edit the pages that you are debugging.

Debugging Stored Procedures and Triggers

See Also

Visual InterDev includes a SQL debugger that you can use to debug Microsoft SQL Server stored procedures and triggers in much the same way that you debug other kinds of scripts or programs.

Before debugging stored procedures and triggers in Visual InterDev, you must set up both SQL Server and Visual InterDev properly by:

• Installing the server debugging components in SQL Server. For details, refer to the SQL Server documentation.
  
  
• Configuring Visual InterDev for remote debugging. For details, see Debugging Remotely.

Unlike debugging other types of processes, you don't debug stored procedures or triggers while they are running. Instead, you open the procedure in the editor and debug it from there.

To debug a stored procedure

• In the Data View window, right-click the stored procedure to debug, and then choose Debug.

  The editor window opens with the stored procedure text in it and the debugging commands enabled on the Debug menu.

After you've opened the editor window in Debug mode, you can use debugger commands as usual. For example, you can set breakpoints and step through the procedure. You can view the values of variables and passed parameters in the Locals window. You can also drag expressions to the Watch window to track them as you step through or run the procedure. The results of SQL PRINT statements are displayed in the Output window.

However, the SQL debugger has the following differences from the debugger used for script:

• The Auto and Immediate windows are not functional while you are debugging stored procedures. Although you can display them, the Auto window will be empty and the Immediate window will not allow you to enter expressions.
  
  
• You cannot change the execution sequence using the Set Next Statement command.

If you are working with simple SELECT statements ù ones that return only a single value ù the return value is in a variable that you can inspect in the Locals window. However, if the SELECT statement returns a result set, it is not displayed in the debugger. Instead, you can view the result set in the Output window.