Debugging ASP Web Applications

Although the primary focus of Visual Studio .NET Web debugging is ASP.NET, you can also debug ASP Web applications.

ASP Web applications consist of scripts that run on the client in .htm files and on the server in .asp files, the Global.asa file, and .cdf files. Scripts can be in VBScript, JScript, or a mixture. They may also be mixed with HTML code and COM objects. With Visual Studio .NET, you can debug ASP Web applications containing all of these elements.

To debug an ASP Web application, you should consider the following:

• ASP Remote Debugging Setup
• Attaching
• Types of Errors
• Working in the Debugger
• Understanding ASP Script Processing
• Debugging a Global.asa File
• Debugging Script Objects in ASP Pages

  Note   It is highly recommended that you do not use the Active Desktop mode of Microsoft Internet Explorer when you are debugging. If you try to debug script in Active Desktop mode, you will be unable to interact with the desktop process while debugging.

Attaching

You can debug client-side script running on your local machine by attaching to a local copy of Internet Explorer.

To debug script running Microsoft Internet Information Services, you can attach to IIS on a remote server or your local machine. For more information, see Attaching to a Running Program or Multiple Programs.

When you attach to an ASP Web application, make sure you select the appropriate program types in the Attach To Process dialog box. To debug a mix of script and managed code, for example, you need to select both Script and Common Language Runtime program types when you attach. You can then set and hit breakpoints in script and managed code, step between script and managed code, and so on. For more information, see Attach To Process Dialog Box.

Types of Errors

When you work with ASP 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 multiline 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.
• 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 run-time 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 process of debugging ASP 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 a script error (for more information, see Just-In-Time Debugging).
• Stop script execution using the Break command or by setting a breakpoint. 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.

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 process such as IIS or Internet Explorer. For more information, see Attaching to a Running Program or Multiple Programs.
• The Running Documents window allows you to view a list of documents that are loaded by the script host you are debugging. (Internet Explorer or IIS/ASP, for example). For more information, see Using the Running Documents Window.
• You can use Visual Studio source windows to display source code for the script or component you are debugging. If the script or component you are debugging is part of your current Visual Studio project, you can fix errors, and then rerun the document to test the fix. You can set and clear breakpoints in the source editor.
• When the debugger breaks execution at a breakpoint, you can use Debug menu commands 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 can enter the procedure (Step Into) or run the procedure and stop at the next line (Step Over). At any point, you can jump out of the current procedure and step to the next line (Step Out).
• 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. For more information, see Using the Locals Window and Using the Watch Window.
• You can set and change values in the Command window (Immediate mode). 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). For more information, see Command Window.
• Using the Call Stack window, you can move to any currently active procedure. For more information, see using the Using the Call Stack Window.

Understanding ASP Script Processing

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

Processing Client Script

Microsoft Internet Explorer processes the client script. The browser calls the appropriate run-time module to process VBScript scripts or JScript 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.

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 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 run-time 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. Inline script embedded in HTML text is passed back to the client for handling.

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 more information, see Debugging a Global.asa File.

Debugging ASP Web Applications on a Machine Running Windows Server 2003

On a machine running Windows Server 2003, the default ASP worker process is w3wp.exe. The w3wp.exe process normally runs under the NETWORK SERVICE account but can be configured to run under SYSTEM SERVICE or a user account. To debug ASP pages on a Windows Server 2003 machine, you must add the account w3wp.exe is running under to the Debugger User group on that machine.

If w3wp.exe runs under the NETWORK SERVICE or SYSTEM SERVICE account, you must be Administrator on the server to debug ASP on it. If w3wp.exe runs under your account, you do not need Administrator privileges, but still need to be a member of the Debugger User group.

To add a user to the Debugger User group on a server

1. Log onto the server as Administrator.
2. Right-click My Computer and choose Manage from the shortcut menu.
3. Under System Tools, Local Users and Groups, open the Groups folder.
4. Double-click Debugger Users.
5. In the Debugger User Properties dialog box, you will see a list of members. If the user does not appear in the Members list, click the Add button.
   1. In the Select Users or Groups dialog box, select the name of the user you want to add from the list and click Add

      -or-

      Type the name of the user in the lower box.

   2. Click OK.
6. Click OK.

For more information about adding users and groups, click the Help button at the top of the Computer Management console.

See Also

Debugging Script and Web Applications | ASP Remote Debugging Setup