Debugging Your Pages

As you write script, you can test it to find errors. To help you, Microsoft Visual InterDev includes a full-featured debugger you can use to trace errors in client and server script.

To | See
Debug script being run by a browser (Microsoft Internet Explorer). | Debugging Client Script
Debug script in .asp files that are being processed by Microsoft Internet Information Server (IIS) 4.0. | Debugging Server Script
Debug pages containing both server and client script | Debugging Mixed Client and Server Script
Debug script in the Global.asa file that is run when an application or session starts on IIS 4.0. | Debugging a Global.asa file


Debugging Client Script

See Also

You can debug client script by running it from within your Microsoft Visual InterDev solution, or by responding to a syntax or run time error in a script, called just-in-time debugging.

Note To debug client script in Microsoft Internet Explorer, you must be using Internet Explorer 4.0. Debugging must also be enabled in Internet Explorer (this is the default). It is also highly recommended that you do not use Active Desktop mode of Internet Explorer when you are debugging.

If the script is in a file that belongs to a project in the current solution, you can fix the error, and then restart the debugging session to see the effect of your change. If the error is in a page that does not belong to the current solution, you can view the script in a read-only window.

Before you can debug client script in ASP pages, you must enable debugging.

To enable client script debugging in ASP pages

  1. In the Project Explorer, right-click the project and choose Properties to display the Property Pages dialog box.

  2. Choose the Launch tab.

  3. Under Server script, choose Automatically enable ASP client-side debugging on launch.

Note To debug script in ASP pages, you must be running version 4.0 or later of Microsoft Internet Information Server (IIS).

If a Web page contains a mixture of client and server script, you can use the Visual InterDev debugger to debug both. For details, see Debugging Mixed Client and Server Script.

To debug a script from within a solution

  1. In Visual InterDev, open the project containing the page you want to debug, and load the page into the editor.

  2. Make the page your project's start page. In the Project Explorer, right-click the page and choose Set as Start Page.

  3. Set a breakpoint in the script to debug. For details, see Setting Breakpoints.

  4. From the Debug menu, choose Start.

    Visual InterDev launches Internet Explorer and loads the page into it. If the breakpoint is in an event handler script, you might have to trigger the event. When Internet Explorer reaches the breakpoint, it stops and displays the source code in the editor window.

  5. If you find an error, fix it, and then save the file. If you do not have a working copy of the file, right-click the name of the file in the Project Explorer and choose Get Latest Version before you make modifications.

  6. From the Debug menu, choose Restart.

Tip You can also add a Stop statement (in VBScript) or a debugger statement (in JScript) to launch the debugger from within a script.

If a client script is already running in Internet Explorer and you detect a problem, you can stop the script and debug it on the spot.

To debug a running script

  • In Internet Explorer, choose Script Debugger from the View menu, and then choose Break at Next Statement. In Internet Explorer, trigger the event that calls the script you want to debug.

    –or–

  • In Internet Explorer, choose Script Debugger from the View menu, and then choose Open. This launches Visual InterDev and starts debugging the current document.

    –or–

  • In Visual InterDev, choose Processes from the Debug menu. In the Processes dialog box, choose Microsoft Internet Explorer, choose Attach, and then choose the script you want to debug.

    –or–

  • If you have already attached to a running document, in Visual InterDev, choose Break from the Debug menu. The debugger will stop at the script statement that is executed.

If Internet Explorer encounters a syntax or runtime error, you can use just-in-time debugging to find and fix it.

To debug in response to an error

  • When Internet Explorer displays an error message that allows you to debug the script, choose Yes.

    Visual InterDev starts, loads the document into the editor, and highlights the line of script that caused the error.

    Note If you are debugging a client script generated by an .asp file, the line numbers reported in error messages refer to lines in the HTML document currently displayed in the browser. These usually do not correspond to line numbers in the original .asp file, because server script does not appear in the HTML output of an .asp file. For more information, see Debugging Mixed Client and Server Script.


Debugging Server Script

From Visual InterDev you can debug server script that execute on Microsoft Internet Information Server (IIS). If IIS is running on your computer, you can debug server script in much the same way that you debug client script. If the server is on another computer, you can use remote debugging from your computer to find errors in the server script. For details, see Debugging Remotely.

Note To debug script in ASP pages, you must be running version 4.0 or later of Microsoft Internet Information Server (IIS).

Before you can debug server script in ASP pages, you must enable debugging.

To enable script debugging in ASP pages

  1. In the Project Explorer, right-click the project and choose Properties to display the Property Pages dialog box.

  2. Choose the Launch tab.

  3. Under Server script, choose Automatically enable ASP server-side debugging on launch.

If a Web page contains a mixture of client and server script, you can use the Visual InterDev debugger to debug both. For details, see Debugging Mixed Client and Server Script.

To debug script on the server, debugging must be enabled for the application containing the .asp files you are working with. For more details, refer to the documentation for Microsoft Internet Information Server.

To debug server script from within a solution

  1. In Visual InterDev, open the project containing the server script you want to debug.

  2. Make the page your project's start page. In the Project Explorer, right-click the page and choose Set as Start Page.

  3. Set a breakpoint in the server script you want to debug.

  4. From the Debug menu, choose Start to launch the project.

    Visual InterDev automatically attaches the debugger to the document running on the server. When server script execution reaches the line with the breakpoint, the debugger displays the page in the editor with that line highlighted.

  5. If the .asp file is part of your project, fix any errors, save the file, and then from the Debug menu choose Restart. If you do not have a working copy of the file, right-click the name of the file in the Project Explorer and choose Get Latest Version before you make modifications.

Tip You can also add a Stop statement (in VBScript) or debugger statement (in JScript) to launch the debugger from within a script.

If a server script is already running, and you detect a problem, you can debug it on the spot.

To debug a running script

  1. In Visual InterDev, choose Processes from the Debug menu. In the Processes dialog box, choose Active Server Pages, and choose Attach.

  2. In the Running Documents window, select the script you want to debug.

  3. Set breakpoints, and then choose Restart from the Debug menu, or refresh the document in the browser.

If debugging is enabled for an application on the server and the server encounters a syntax error or run-time error in a server script, it displays an error message in the requesting browser.

To debug server script in response to an error

  1. In response to the error, choose Yes.

    Visual InterDev is launched. The debugger attaches itself to the script with the error and displays the page in the editor.

  2. If the page is part of a project in Visual InterDev, open the project, get a working copy of the file, open it, fix any errors, save the file, and then deploy it to the server. Then in Internet Explorer, refresh the page.

If server debugging is not enabled for the application, errors are displayed in the browser as text in the page. In that case, open the project containing the page in Visual InterDev and start the debugger there, as described above.


Debugging Mixed Client and Server Script

Many ASP pages contain both client and server script. You can set breakpoints in both client and server script, and as each script executes, it can call the debugger at breakpoints.

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

Before you can debug script in ASP pages, you must enable debugging.

To enable script debugging in ASP pages

  1. In the Project Explorer, right-click the project and choose Properties to display the Property Pages dialog box.

  2. Choose the Launch tab.

  3. Under Server script, choose Automatically enable ASP server-side debugging on launch.

Note To debug script in ASP pages, you must be running version 4.0 or later of Microsoft Internet Information Server (IIS).

When you set a breakpoint in client script in a page that contains both server and client script, the debugger tracks the breakpoint even though the position of the breakpoint can change significantly in the file after server script has executed. If server script causes the client script to be written several times into the page, the debugger tracks each breakpoint separately.

You can set breakpoints in server script, client script, or both. If you set breakpoints in both, the debugger will stop at the server script breakpoints first. When you continue to run, the page is sent to the browser, and the debugger will then stop at breakpoints in client script.

To debug pages containing both client and server script

  1. In Visual InterDev, set breakpoints in the lines of client and server script that you want to debug.

  2. Make the page your project's start page. In the Project Explorer, right-click the page and choose Set as Start Page.

  3. From the Debug menu, choose Start.

    The server script executes and stops at any breakpoint you have set there.

  4. Step through the server script as needed.

    When you step out of server script, the page will continue executing until it gets to another server script. When the debugger has finished with server script, the server sends the page to the browser, which displays it.

  5. If necessary, trigger the event (such as a button click) that will run the client script you want to debug.

    The debugger stops at the breakpoint and displays the version of the page that is being processed by the browser.

When you are debugging pages that contain both server and client script, remember that server script can potentially insert HTML text and client script into the page. For example, a few lines of server script can dynamically create a large table out of database information, or can write or rearrange client script on the page. After processing the page, the server removes the server script. As a consequence, the page being processed by the browser can look quite different than it does in the Visual InterDev editor with both server and client script in it. For details about how server script is processed, see Understanding Script Processing.

Debugging Embedded Server Script

A special case occurs when you want to debug server script that appears inside a block of client script. In the following, server script first extracts a value from a form and stores it in a variable. Later, inside the block of client script, a block of embedded server script dynamically inserts the value of the variable into a client statement:

<%loginName = = Request.Form("loginName")%>
<!-- HTML text here -->

<SCRIPT LANGUAGE="VBScript">
Sub ShowWelcome
   txt = <%=loginName%>
   MsgBox("Welcome, " & txt)
End sub
</SCRIPT>

Note When you write server script inside of client script, the editor does not follow color-coding convention for server script.

If you set a breakpoint on the line with the embedded server script, it is not clear whether you want the debugger to stop on the server script (<%=loginName%>) or later in the client script (txt = ). Visual InterDev therefore offers you two options:

  • Client breakpoint only. By default, the breakpoint is interpreted as a client breakpoint, and the debugger does not stop when the server is processing the embedded server script.

  • Server and client breakpoint. The debugger stops twice — the first time when it processes the server script, and then again when it reaches the same line in client script.

The default is client breakpoint only. To stop both times, you enable a debugger option.

To enable breakpoints for embedded server script

  1. From the Tools menu, choose Options, and then open the Debugger node.

  2. Choose the option Set breakpoints on embedded server script.

When you are running the debugger and it breaks on embedded server script, it does not stop directly on the line containing the server script. Instead, it stops on the line of client script or HTML that immediately follows the preceding line of server script. In some cases, this can cause the breakpoint to appear many lines before the embedded server script.

For example, if you set a breakpoint on the embedded server script (<%=loginName%>) in the following example, the debugger will stop on the <HTML> tag.

<%loginName = = Request.Form("loginName")%>
<HTML>
<HEAD>
<SCRIPT LANGUAGE="VBScript">
Sub ShowWelcome
   txt = <%=loginName%>
   MsgBox("Welcome, " & txt)
End sub
</SCRIPT>
</HEAD>

This behavior occurs because when the server is processing the page, it ignores anything that isn't server script. The server doesn't "see" the lines of HTML and client script that precede the embedded server script. To the server, the beginning of the line containing the embedded server script is therefore the one immediately following the preceding line of server script.

To move to the embedded server script, use the debugger's Step Into command.


Debugging a Global.asa File

Debugging a Global.asa file differs from debugging .asp files in

these ways:

  • You cannot request a Global.asa file specifically in the client browser. Instead, the server executes its procedures automatically when you first request other files in the ASP-based application. Therefore, you cannot use a browser command to start the debugger.

  • Procedures in a Global.asa file are event-driven, unlike procedures in .asp files.

  • Procedures in a Global.asa file usually run only once per application or once per session:
    • The Application_OnStart procedure executes the first time that any user accesses any page in an ASP-based application.

    • The Application_OnEnd procedure executes only when the application is shut down.

    • The Session_OnStart procedure executes only once per user session.

    • The Session_OnEnd procedure executes only when a user’s session times out or when a script explicitly calls the Session object’s Abandon method.

Before you can debug script in the Global.asa page, you must enable debugging for ASP pages.

To enable script debugging in ASP pages

  1. In the Project Explorer, right-click the project and choose Properties to display the Property Pages dialog box.

  2. Choose the Launch tab.

  3. Under Server script, choose Automatically enable ASP server-side debugging on launch.

To debug the Global.asa file, you can call the debugger from a script or respond to an error.

To call the debugger from the Global.asa file

  • Open the Global.asa file in the editor, and then set a breakpoint in a script.

    –or–

  • Include a statement that starts the debugger explicitly, such as Stop in VBScript or debugger in JavaScript. Place the statement at the beginning of the procedure, before any statements that you will want to step through.

When the application starts or when a user starts a new session, the corresponding procedure in a Global.asa file will run. The debugger will start when the Stop or debugger statement is executed. You can then step through the procedure normally, use the Immediate window to evaluate expressions and set values, and so on.

If there is an error in a Global.asa file (either a syntax error or runtime error), the server stops the procedure containing the error. If the debugger is enabled for that ASP application, the server prompts you to start the debugger and displays an error message. If the debugger is not enabled for the ASP application, an error message is sent to the client browser. In either case, the procedure containing the error stops.

To debug Global.asa script in response to an error

  1. In response to the error, choose Yes.

    If Visual InterDev is not already running, it is launched. The debugger attaches itself to the script with the error and displays the page in the editor.

  2. If the page is part of a project in Visual InterDev, fix any errors, save the file, and then choose Restart from the Debug menu. If you do not have a working copy of the file in your project, right-click the Global.asa file in the Project Explorer and choose Get Latest Version before making modifications.

You cannot stop and restart the script by refreshing a Global.asa file. To rerun Application_OnStart or Session_OnStart procedures, you must refresh the file or trigger the events again or otherwise restart the application.

To rerun all procedures in the Global.asa

  • In the editor, change the Global.asa file, and then deploy it to the server.

    This restarts the application and session, which runs the procedures in the Global.asa file again.

To rerun Application_OnStart procedures

  • Stop the application and then restart it.

You can rerun Session_OnStart procedures by restarting a session.

To rerun Session_OnStart procedures

  • Restart your browser, which starts a new session and reruns the Session_OnStart event procedure.

    –or–

  • Request a page that includes a script to call the Session object’s Abandon method, and then start a new session.

Debugging Script

See Also Tasks

Debugging script allows you to find errors in your script, such as syntax errors, run-time errors, and logic errors, before you publish that script to the World Wide Web. You probably already know how to set breakpoints and how to step through lines of script. Now you can see how to accomplish these tasks using Microsoft Visual InterDev.

In Visual InterDev, debugging script consists of some or all of these steps, once you have added script to a page:

  • Setting Breakpoints

  • Stepping Through Lines of Script

  • Changing the Value of a Variable

Adding Client Script to an HTM Page

Debugging client script is an easy way to become familiar with debugging in Visual InterDev. Client-side script is processed on the browser, while server-side script is processed on the Web server. For more information about client- and server-side script, see Debugging Client Script and Debugging Server Script.

The sample client script, located between the <SCRIPT> </SCRIPT> tags in the example below, validates the length of password entries made in a simple form. The remaining HTML tags define the form and do not participate in the script debugging process.

To use the script below, copy and paste the script and HTML into a new .htm file using Source view of the HTML editor. For more information, see Editing Script.

<SCRIPT LANGUAGE="JavaScript">
function validatePassword(){
var password;
password = document.frm1.txtPassword.value;
alert("You entered " + password);
if (password.length < 4)
alert("You must enter 4 characters or more!");
else {
frm1.submit() ; }
}
</script>
<FORM NAME="frm1" METHOD="Post" ACTION="Process.asp" ONSUBMIT="validatePassword()">
   Please enter your password:<br>
   <INPUT TYPE="Password" NAME="txtPassword">
   <INPUT TYPE="Submit" NAME="btnSubmit">
</FORM>

Note JavaScript is case sensitive, so the sample script above must appear exactly as it does here in your .htm file.

The script checks that the password length is four characters or greater. The script generates a message box listing the password the user entered. If the password is four characters or greater the user is then redirected to the page called by the Action element of the Form tag.

If you haven't created Process.asp, the browser will display the object not found error. If the password is less than four characters, a message box appears indicating the character length requirement.

Setting Breakpoints

To specify a place in script where you want to stop and examine the state of the process, you can use breakpoints. Breakpoints indicate the line of script you want to stop on in the program. You can then step through, step into, or step over lines of script individually to find errors. Breakpoints show up as red octagons to the left of a line of script in Source view.

Note To debug client scripts in Microsoft Internet Explorer, you must be using Internet Explorer 4.0 and debugging must be enabled. For details, see the Internet Explorer documentation.

To set breakpoints

  1. Open the .htm file and select Source view.

  2. Place the cursor in the line of script you want to set a breakpoint in.

  3. From the Debug menu, choose Insert Breakpoint.

    A red octagon appears to the left of the line of script.

    Note You can also set or remove a breakpoint by placing the cursor in a line of script and pressing F9.

To launch the debugger

  4. In the Project Explorer, right-click the .htm file and select Set As Start Page.

  5. Launch Internet Explorer 4.0 and load the .htm page into the browser.

  6. From the Debug menu in Visual InterDev, choose Processes.

    The Processes dialog box appears.

  7. In the Process area, select Microsoft Internet Explorer and then select Attach.

    Microsoft Internet Explorer and your machine name appear in the Debugged Processes area.

  8. In Internet Explorer, enter a password and choose Submit.

The script executes until Internet Explorer reaches the breakpoint. When Internet Explorer reaches the breakpoint, it stops and displays the source script in Source view.

A yellow arrow superimposed over the breakpoint icon indicates the line of script where the debugger stopped.

For more information, see Breakpoints Dialog Box or Debugging Client Script.

Stepping Through Lines of Script

To execute script one line at a time, you can use Step Into. After stepping through each line, you can view the affects of the statement by looking at the page in Internet Explorer.

To step into lines of script

  9. Open the .htm file in Source view and set a breakpoint at the following line of script:
    <FORM NAME="frm1" METHOD="Post" ACTION="Process.asp" ONSUBMIT="validatePassword()">

    Note When you place a breakpoint in the line of HTML above, you are actually specifying that the script stop executing when you click the Submit button, ONSUBMIT="validatePassword()".

  10. Launch the debugger.

  11. Enter a two-character password and choose Submit.

    Internet Explorer reaches the breakpoint and switches to Source view. A yellow arrow appears superimposed over the breakpoint icon.

  12. From the Debug menu, choose Step Into and then choose Step Into a second time.

    The following line of script is highlighted:

    alert("You entered " + password);
  13. From the Debug menu, choose Step Into again.

    Internet Explorer executes the alert script and displays the message box.

  14. Choose OK.

    Internet Explorer reaches the next line of script and switches to Source view.

You can continue stepping into lines of script and view the results in Internet Explorer.

To execute procedures in script as a single unit, you can use Step Over. Step Over allows you to skip a procedure or function and step through the next procedure or function.

After stepping over a procedure, you can view the affects of the procedure by looking at the page in Internet Explorer.

To step over lines of script

  15. Open the .htm file in Source view and set a breakpoint at the following line of script:
    <FORM NAME="frm1" METHOD="Post" ACTION="Process.asp" ONSUBMIT="validatePassword()">

    Note When you place a breakpoint in the line of HTML above, you are actually specifying that the script stop executing when you click the Submit button, ONSUBMIT="validatePassword()".

  16. Launch the debugger.

  17. Enter a three-character password, then choose Submit.

    Internet Explorer reaches the breakpoint and switches to Source view. A yellow arrow appears superimposed over the breakpoint icon.

  18. From the Debug menu, choose Step Over.

    Internet Explorer executed the following script as a procedure unit:

    password = document.frm1.txtPassword.value;
alert("You entered " + password);
if (password.length < 4)
alert("You must enter 4 characters or more!");
  19. Choose OK in each alert message.

Internet Explorer reaches the line of script after the procedure unit and switches back to Source view. For more information, see Debugging Your Pages and Stepping Through Code to Trace Execution.

Changing the Value of a Variable

You can change the value of a variable from the Immediate window. When Internet Explorer reaches a breakpoint and switches to Source view, you can then change the value of a variable and view the results in the Locals window.

To change the value of a variable

  20. Open the .htm file in Source view and set a breakpoint at the following line of script:
    <FORM NAME="frm1" METHOD="Post" ACTION="Process.asp" ONSUBMIT="validatePassword()">
  21. Launch the debugger.

  22. Enter a three-character password and choose Submit.

    Internet Explorer reaches the breakpoint and switches to Source view. A yellow arrow appears superimposed over the breakpoint icon.

  23. From the Debug menu in Visual InterDev, choose Step Into.

  24. From the View menu, select Debug Windows and then select Immediate.

  25. In the Immediate window, type the following:
    password="test"
  26. Press Enter.

  27. From the View menu, select Debug Windows and then select Locals.

    The Locals window displays the new value of the variable you entered in the Immediate window.

For more information, see Executing Commands and Evaluating Expressions in the Immediate Window and Viewing Local Variables in the Locals Window.


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.


Topic Not Found

No matching topic was found. Some possible reasons and remedies are as follows:

  • The file (.chm) that contains the destination topic is not in the expected location.

    Remedy: Rerun the MSDN Library Setup.

  • The file (.chm) that contains the current topic or destination topic is out-of-date and the link is no longer valid.

    Remedy: Install the latest version of the MSDN Library.

  • The MSDN Library CD is not in the CD-ROM drive.

    Remedy: Insert the MSDN Library CD into the CD-ROM drive.