Debugging Your Pages

As you write script for your Web application, 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
Debug script running on the server while you are working on a client workstation | Debugging Remotely
Debug stored procedures and triggers in databases | Debugging


Debugging Client Script

You can debug client script in any of these ways:

  • Run a page containing the script to debug from within your Microsoft® Visual InterDev™ solution.

  • Attach the Visual InterDev debugger to a process (page) already running in Microsoft® Internet Explorer.

  • Respond to a syntax or run-time error in a script, called just-in-time debugging.

  • Include a statement in script that starts the debugger.

Note To debug client script in 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, or set the option in Internet Explorer to launch each new instance of the browser in a new process.

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.

Enabling Client Script Debugging for ASP Pages

Before you can debug client script in ASP pages, you must enable debugging. You can manually enable debugging for your ASP application as described under "Enabling ASP Debugging on the Server" in the Troubleshooting topic. Alternatively, Visual InterDev can automatically enable debugging on the server as needed.

Note If you intend to work exclusively with client script in .htm files, you do not need to enable server debugging or perform the following procedure.

To automatically 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, make sure that Automatically enable ASP client-side debugging on launch is checked.

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

When this option is set, each time you start a debugging session Visual InterDev checks that the server is configured for debugging. This includes:

  • Setting the IIS application to run in its own memory space (in COM terms, it runs "out of process").

  • Enabling the IIS application's debugging options.

  • Setting up a Microsoft® Transaction Server (MTS) package to allow you to attach the debugger to the Web application. The package's identify is set when you first start the debugging session by asking you to provide your name and password.

When you quit your debugging session, Visual InterDev restores the server debugging settings and out-of-process setting to their previous values.

Debugging Client Script Within a Solution

If you are working in a Visual InterDev solution, you can debug a file by launching the debugger.

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.

  5. If debugging for client script in ASP pages has not been enabled as described above, Visual InterDev displays a message. Your options are:
    • If you are working with client script in an .htm file (not an .asp file) and you will not be navigating to an ASP page during your debugging session, choose Yes to proceed with debugging.

    • If you are working in an .asp file, or if you will be navigating to an .asp file during your debugging session, choose Yes to proceed only if you are certain that debugging has already been manually enabled on the server for your project. Otherwise, choose No and enable debugging as described above. For details about setting debugging options in IIS, see "Performance Issues While Debugging Server Script" in the Troubleshooting topic.
  6. If client debugging in ASP pages is enabled, and if this is the first time you have launched a debugging session since opening the project, you are prompted to provide user information that identifies the debugging process on the server. (You are prompted even if you are currently working with an .htm file, in case you navigate to an ASP page.) Enter your domain and name in the form domain\name and your password.

    Note You might experience a delay the first time you launch a debugging session for the current project while Visual InterDev establishes the proper debugging configuration on the server.

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

  7. 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.

  8. From the Debug menu, choose Restart.

Debugging Client Script in a Running Document

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. You can debug a running document from within Visual InterDev or from within Internet Explorer.

Note If you are working with an ASP page, debugging must be enabled on the server. For details, see "Enabling ASP Debugging on the Server" in the Troubleshooting topic.

You can attach to a running document only if attaching is enabled.

To enable just-in-time debugging

  1. From the Tools menu, choose Options.

  2. In the Options dialog box, choose Debugger.

  3. Under Script, check Attach to programs running on this machine.

You can attach to a document directly in Visual InterDev.

To debug a running document in Visual InterDev

  • 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 next script statement that is executed.

If Visual InterDev is not already running, you can launch the debugger from Internet Explorer.

To debug a running document from Internet Explorer

  1. In Internet Explorer, choose Script Debugger from the View menu, and then choose Break at Next Statement. In the browser, 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.

  2. A new instance of Visual InterDev is launched and you are prompted to open a project. If Visual InterDev is already running, a second instance is launched.

  3. Open the project containing the file to debug. If the project is already open in another instance of Visual InterDev, you cannot open it again, so Visual InterDev creates a new solution and project instead.

  4. The page to debug is loaded into the editor. If necessary, get a working copy of the page. If the project was already open, the page is loaded as read-only file in the new project.

If you make changes to the file, save it and re-deploy it to the server. Refresh the file in Internet Explorer before running the script again.

Debugging Client Script in Response to an Error or Debugger Statement

If Internet Explorer encounters a syntax or run-time error, you can use just-in-time debugging to find and fix it. You can also include a statement in your script, such as a Stop statement in Visual Basic®, Scripting Edition (VBScript) or a debugger statement in JScript™, to launch the debugger from within a script.

You can launch the debugger in response to an error or debugger statement only if just-in-time debugging is enabled.

To enable just-in-time debugging

  1. From the Tools menu, choose Options.

  2. In the Options dialog box, choose Debugger.

  3. Under Script, check Just-In-Time debugging.

To debug in response to an error or debugger statement

  1. When Internet Explorer encounters an error or a statement that starts the debugger, it displays an error message prompting you to debug. Choose Yes.

  2. A new instance of Visual InterDev is launched. If Visual InterDev is already running, a second instance is launched.

  3. Open the project containing the file to debug. If the project is already open in another instance of Visual InterDev, you cannot open it again, so Visual InterDev creates a new project instead.

    The page to debug is loaded into the editor. If necessary, get a working copy of the page. If the project was already open, the page is loaded as a read-only file in the new project.

    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.

If you make changes to the file, save it and re-deploy it to the server. Refresh the file in Internet Explorer before running the script again.


Debugging Server Script

From Microsoft® Visual InterDev™ you can debug server script that executes 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.

You can debug server script in any of these ways:

  • Run a page containing the script to debug from within your Microsoft Visual InterDev solution.

  • Attach the Visual InterDev debugger to a process (page) already running in Microsoft® Internet Explorer.

  • Respond to a syntax or run-time error in a script, called just-in-time debugging.

  • Include a statement in script that starts the debugger.

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.

Enabling Server Script Debugging for ASP Pages

Before you can debug client script in ASP pages, you must enable debugging. You can manually enable debugging for your ASP application as described under "Enabling ASP Debugging on the Server" in the Troubleshooting topic. Alternatively, Visual InterDev can automatically enable debugging on the server as needed.

To automatically 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, make sure Automatically enable ASP server-side debugging on launch is checked.

When this option is set, each time you start a debugging session Visual InterDev checks that the server is configured for debugging. This includes:

  • Setting the IIS application to run in its own memory space (in COM terms, it runs "out of process").

  • Enabling the IIS application's debugging options.

  • Setting up a Microsoft® Transaction Server (MTS) package to allow you to attach the debugger to the Web application. The package's identify is set when you first start the debugging session by asking you to provide your name and password.

    Note You can perform the first two steps manually on the server. For details, see "Enabling ASP Debugging on the Server" in the Troubleshooting topic.

When you quit your debugging session, Visual InterDev restores the server debugging settings and out-of-process setting to their previous values.

Debugging Server Script Within a Solution

If you are working in a Visual InterDev solution, you can debug server script by launching the debugger.

Note Before debugging server script, make sure debugging is enabled as described above or under "Enabling ASP Debugging on the Server" in the Troubleshooting topic.

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 attempts to attach the debugger to the document running on the server.

  5. If this is the first time you have started the debugger since opening the current project, you are prompted to provide user information used to identify the debugging process on the server. Enter your domain and name (in the form domain\name) and password.

  6. The browser opens, and you can proceed with debugging. When server script execution reaches the line with the breakpoint, the debugger displays the page in the editor with that line highlighted.

  7. 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.

Debugging Server Script in a Running Document

If debugging has been enabled on the server for your project and you detect an error while the application is running, you can attach the debugger to it. For details about enabling debugging on the server, see "Enabling ASP Debugging on the Server" in the Troubleshooting topic.

You can attach to a running document only if attaching is enabled.

To enable just-in-time debugging

  1. From the Tools menu, choose Options.

  2. In the Options dialog box, choose Debugger.

  3. Under Script, check Attach to programs running on this machine.

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.

Debugging Server Script in Response to an Error or Debugger Statement

If debugging is enabled for an IIS application on the server and the server encounters a syntax error or run-time error in a server script, you can use just-in-time debugging to find and fix it. You can also include a statement in your script, such as a Stop statement in VBScript or a debugger statement in JScript, to launch the debugger from within a script. For details about enabling debugging on the server, see "Enabling ASP Debugging on the Server" in the Troubleshooting topic.

Note If a debugger is installed on the server computer, the server does not pass error information through to the client. Instead, it displays an error message on the server computer's monitor. For more information, see "Just-in-Time Debugging of Server Pages" in the Troubleshooting topic.

You can launch the debugger in response to an error or debugger statement only if just-in-time debugging is enabled.

To enable just-in-time debugging

  1. From the Tools menu, choose Options.

  2. In the Options dialog box, choose Debugger.

  3. Under Script, check Just-In-Time debugging.

To debug server script in response to an error or debugger statement

  1. When an error message appears prompting you to start the debugger, choose Yes.

  2. A new instance of Visual InterDev is launched and you are prompted to open a project. If Visual InterDev is already running, a second instance is launched.

  3. Open the project containing the file to debug. If the project is already open in another instance of Visual InterDev, you cannot open it again, and Visual InterDev creates a new solution and project instead.

    The page to debug is loaded into the editor. If necessary, get a working copy of the page. If the project is already open, the page is loaded as read-only file in the new project.

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.

If the server is not running on your computer, you use remote debugging to debug the server script in the page. For details about how to set up remote debugging, see Debugging Remotely.

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

Enabling Debugging for ASP Pages

Before you can debug script in ASP pages, you must enable debugging. You can manually enable debugging for your ASP application as described under "Enabling ASP Debugging on the Server" in the Troubleshooting topic. Alternatively, Microsoft® Visual InterDev™ can automatically enable debugging on the server as needed.

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

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, make sure Automatically enable ASP server-side debugging on launch and Automatically enable ASP client-side debugging on launch are checked.

When these options are set, each time you start a debugging session Visual InterDev checks that the server is configured for debugging. This includes:

  • Setting the IIS application to run in its own memory space (in COM terms, it runs "out of process").

  • Enabling the IIS application's debugging options.

  • Setting up a Microsoft® Transaction Server (MTS) package to allow you to attach the debugger to the Web application. The package's identify is set when you first start the debugging session by asking you to provide your name and password.

When you quit your debugging session, Visual InterDev restores the server debugging settings and out-of-process setting to their previous values.

Debugging Pages Containing Client and Server Script

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.

    Visual InterDev attempts to attach the debugger to the document running on the server.

  4. If this is the first time you have started the debugger since opening the current project, you are prompted to provide user information used to identify the debugging process on the server. Enter your domain and name (in the form domain\name) and password.

  5. Proceed with debugging. When server script execution reaches the line with the breakpoint, the debugger displays the page in the editor with that line highlighted.

    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.

  6. 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")%>

<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. 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 Insert breakpoints in Active Server Pages for breakpoints in client 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:

  • The Global.asa file cannot be a start page. To debug the Global.asa, you must request an ASP page. When the ASP page is requested, the server processes the Global.asa page.

  • Procedures in a Global.asa file are event-driven, unlike inline script 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 page in an ASP-based application is accessed.

    • 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.

Enabling Debugging in the Global.asa File

Before you can debug script in the Global.asa file, you must enable debugging for ASP pages. You can manually enable debugging for your ASP application as described under "Enabling ASP Debugging on the Server" in the Troubleshooting topic. Alternatively, Visual InterDev can automatically enable debugging on the server as needed.

To automatically 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, make sure Automatically enable ASP server-side debugging on launch is checked.

When this option is set, each time you start a debugging session Visual InterDev checks that the server is configured for debugging. This includes:

  • Setting the Microsoft® Internet Information Server (IIS) application to run in its own memory space (in COM terms, it runs "out of process").

  • Enabling the IIS application's debugging options.

  • Setting up a Microsoft® Transaction Server (MTS) package to allow you to attach the debugger to the Web application. The package's identify is set when you first start the debugging session by asking you to provide your name and password.

    Note You can perform the first two steps manually on the server. For details, see "Enabling ASP Debugging on the Server" in the Troubleshooting topic.

When you quit your debugging session, Visual InterDev restores the server debugging settings and out-of-process setting to their previous values.

Debugging Scripts in the Global.asa File

To debug the Global.asa file, you set up a debugger call from script in the file, and then start an ASP application.

To call the debugger from the Global.asa file

  1. 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.

  2. Request an ASP page from the current project in the browser. This causes the IIS to run the Global.asa file.

Debugging the Global.asa File in Response to an Error

If there is an error in a Global.asa file (either a syntax error or run-time error), the server stops the procedure containing the error. If debugging is enabled for that ASP application, the server prompts you to start the debugger and displays an error message. If debugging 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.

Note If a debugger is installed on the server computer, the server does not pass error information through to the client. Instead, it displays an error message on the server computer's monitor. For more information, see "Just-In-Time Debugging of Server Pages" in the Troubleshooting topic.

You can launch the debugger in response to an error or debugger statement only if just-in-time debugging is enabled.

To enable just-in-time debugging

  1. From the Tools menu, choose Options.

  2. In the Options dialog box, choose Debugger.

  3. Under Script, check Just-In-Time debugging.

To debug Global.asa script in response to an error

  1. When an error message appears prompting you to start the debugger, choose Yes.

  2. A new instance of Visual InterDev is launched and you are prompted to open a project. If Visual InterDev is already running, a second instance is launched.

  3. Open the project containing the Global.asa file to debug. If the project is already open in another instance of Visual InterDev, you cannot open it again, and Visual InterDev creates a new solution and project instead.

    The Global.asa file is loaded into the editor. If necessary, get a working copy of the page. If the project was already open, the Global.asa file is loaded as read-only file in the new project.

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.

Restarting the Global.asa File

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 file

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

    –or–

  • Stop and restart the Web server.

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


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.