How to Debug Script Code Using Visual Studio .

NET

By
Monica Rosculet
[email protected]
Visual C# Debugger QA Team

Introduction..........................................................................................................................1
Setting up your machine for script debugging.....................................................................1
Who can do script debugging?.............................................................................................2
Client side script debugging.................................................................................................2
What is client side script?................................................................................................3
How to debug it?..............................................................................................................3
Client-side script inside .aspx pages in a web application...............................................4
Server side script debugging................................................................................................4
What is server side script?...............................................................................................4
If the page is not inside a web application.......................................................................5
If the page is part of a web application project................................................................6
If the page is part of a web application project created on a remote machine.................6
Using JIT Debugging for Script...........................................................................................7
Debugging Both Script and Managed Code........................................................................8
Troubleshooting...................................................................................................................8
“Application debugging is disabled” in the Running Documents window....................9
There is no “Script” option for attaching to the script host.............................................9
The JIT Dialog doesn’t come up....................................................................................10
Can’t Hit Breakpoints in Client-side code in a Web Form............................................10
Your Web Application is created at a Non-Default Port ..............................................10
Random weird debugging failures.................................................................................10

Introduction
While trying to help the internal and external customers that are posting questions on the
newsgroups I have noticed that a lot of them have problems with debugging client side
script code or classic ASP server side script code. Hence I summarized in this document
the possible scenarios in which a user could debug script code and some troubleshooting
tips that might help in case the user encounters a problem.

This document covers:

• Client side script debugging
• Server side script debugging
• Troubleshooting

Setting up your machine for script debugging

-1-
The first thing you need to do before being able to debug script code on your machine is
enable this feature in Internet Explorer. To do this, go to Tools | Internet Options and on
the Advanced tab make sure that the Disable script debugging box is unchecked.

!!! Note: Unchecking the Disable script debugging box might open some security
vulnerabilities.

Who can do script debugging?

In order to be able to debug script code running on your machine you need to be a
member of the Debugger Users group. If the owner of the process the script is running in
is a different user than you, you will have to be an administrator on the machine to be
able to debug it. Also, the user account that the script host is running as needs to be a
member of the Debugger Users group or of the Administrators group.

Client side script debugging

-2-
What is client side script?

By client side script code we mean any VB script or JScript code that is loaded by client
application running on your local machine. For example, such code could be embedded
inside a .html, .asp or .aspx page loaded in Internet Explorer or could reside inside a .js or
.vbs file loaded into wscript.exe, cscript.exe or some other script host.

How to debug it?

To debug such code:

1. Run your script code by loading it inside Internet Explorer or the script host of
your choice.
2. Attach to the script host specifying Script as the program to be debugged:

3. Open the Debug | Windows | Running Documents window. There you will see all
the files containing client side script code that are loaded into the script host that
you are attached to.
4. In the Running Documents window double-click on the file containing the code
you want to debug. That file will be opened and you will be able to set
breakpoints in it that will be hit when the code will be executed.

-3-
!!! Note: Don’t open the file using the File | Open | File command because breakpoints
set this way will not be hit. This is a very common mistake that users do.

If your script code resides in a .js or .vbs file that will be run inside wscript.exe or
cscript.exe, make sure that you specify the /D or /X switch in order to enable debugging:

wscript.exe myscript.vbs /D

Client-side script inside .aspx pages in a web application

If your client side script is embedded in an .aspx page that’s part of a web application, all
you will have to do in order to debug it is to F5 the web application project so the
debugger will be attached automatically to Internet Explorer and then to open the .aspx
page from the Running Documents window and set breakpoints in it that will be hit the
next time you refresh the page.

Server side script debugging

What is server side script?

By server-side script we mean any VBScript or JScript code embedded in a classic .ASP
or .ASA page between the <script runat=server></script> or <%%> tags. Such code will
be run on the server where the page is located inside a script worker process like mtx.exe,

-4-
inetinfo.exe, dllhost.exe or w3wp.exe depending on the OS and on the settings inside IIS.
Depending on whether the page containing the server-side script is part of a web
application project or not, there are some settings that need to be changed in order to be
able to debug it.

If the page is not inside a web application

Then it is under a virtual directory inside IIS. In order to debug it, you have to configure
that virtual directory so that ASP debugging will be enabled for it.
This is what you need to do for this:

1. Open IIS Manager

2. Open the properties window for the directory under which your page is located.
3. Go to the Directory tab and push the Configuration button.
4. Go to the Debugging tab and check the Enable ASP server-side and client-side
script debugging boxes.
5. Reset IIS so that the setting will be applied.

-5-
After this change, load your page and attach to the ASP worker process having the Script
option checked inside the Attach to Process dialog box. Again, you will have to use the
Debug | Windows | Running Documents window for opening the page containing the
code you need to debug. You will have to be an administrator in order to be able to attach
to the ASP worker process in this case.

If the page is part of a web application project

Then all you need to do is make sure that ASP debugging is enabled in the Properties
pages for that project:

1. Open the Project Properties window for the project.

2. Go to the Configuration Properties node and open the Debugging page.
3. Set Enable ASP debugging to true.

This is true for both C# and VB web applications.

After this, make sure that your page is set as a start-up page for your application. Next
time you will hit F5 to debug your application, you will be prompted to enter a user-name
and password of a user with rights to configure IIS on that machine. Such a user needs to
be an administrator. After you provide this information, the VS.NET debugger will attach
automatically to the ASP worker process and you will be able to debug your script code.

Note: Unless you really need it enabled, it’s good to disable ASP.NET debugging in the
Project Properties window in this case. This way the debugger will not have to attach to
the ASP.NET worker process in the same time.

If the page is part of a web application project created on a

remote machine

Then simply doing F5 to debug your server-side script will not do the trick. You will
have to apply the following work-around on the machine where the web application is
located:

With the Visual Studio .NET debugger, you can debug an ASP Web application on the
local machine or a remote server. For remote debugging to work properly, there are some
prerequisite steps to perform:

1. First, the Visual Studio .NET Remote Debugging Components must be installed
on the server you want to debug (if not the whole Visual Studio .NET product).
2. You must be a Debugger User on the remote server.
3. Using regedit.exe, you must set these two registry keys on the remote machine:
4. [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{6EB22881-8A19-11D0-
81B6-00A0C9231C29}]

-6-
 5. @="Catalog Class"
6. "DllSurrogate"=""
7.
8. [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{6EB22881-8A19-11D0-
81B6-00A0C9231C29}]
9. @="Catalog Class"
"AppID"="{6EB22881-8A19-11D0-81B6-00A0C9231C29}"

10. Finally, you must configure DCOM permissions on the Web server.

To configure DCOM permissions on the Web server

1. From the Start menu, choose Run.

2. In the Run dialog box, type dcomcnfg.exe and click OK.
3. In the Distributed COM Configuration Properties dialog box, on the
Applications tab, select Catalog Class and click Properties.
4. In the Catalog Class Properties dialog box, choose the Security tab.
5. Select Use custom access permissions, and then click Edit.
6. Add the users that you want to give debugging permission to by granting them
Allow Access rights (or add the Administrators group to this list).
7. Click OK.
8. Select Use custom launch permissions, and then click Edit.
9. Add the users that you want to give debugging permission to by granting them
Allow Launch rights (or add the Administrators group to this list).
10. Click OK.
11. On the Identity tab, select The interactive user.
12. Click Apply, and then click OK to close the Catalog Class Properties dialog
box.
13. Click OK to close the Distributed COM Configuration Properties dialog box.

After this, the next time you use F5 to start debugging the remote application you will see
the dialog for entering your credentials and everything should work as in the local case.

Using JIT Debugging for Script

Whenever there is a run-time error generated by your code (like an unhandled exception,
syntax error etc) you will have the chance to use the JIT (Just-in-Time) mechanism to
attach to the running process and to see where did the error occur. You will see a dialog
telling you that an error occurred and asking you if you want to debug. If you choose
Yes, the JIT dialog will come up.
There is not much difference between JITting client and server side script except that in
the case of server side script the JIT dialog will come up on the machine where the
server-side code is running. In order to JIT debug script code you need the same
privileges as for regular script debugging (Debugger users can debug script code running

-7-
in processes that they own and administrators can debug any script code running on that
machine).

Debugging Both Script and Managed Code

If your script code calls into a managed DLL you will be able to debug both of them at
the same time if you attach to the script host in both Script and Common Language
Runtime modes. For this, all you need to do is select both of these in the Attach to
Process dialog:

After this, you will be able to step into and hit breakpoints inside the managed dll and to
see a merged call stack showing both script and managed frames.

Note: You will not be able to debug both script and native code at the same time. This
feature is not supported.

Troubleshooting
I am going to list here the most common problems the users run into when debugging
script and give some possible ways to fix these problems. Again, most of these problems
were brought up on the newsgroups by our customers. Thanks to Gregg Miskelly and to
M. K. Park for finding solutions to most of these problems.

-8-
“Application debugging is disabled” in the Running Documents
window

If you are trying to debug server-side script and you see such a message in the Running
Documents window, it means that you forgot to enable ASP debugging in IIS for the
virtual directory there your page is located (see the “If the page is not inside a web
application” section).

There is no “Script” option for attaching to the script host

If in the Processes window there is no “Script” option in the Type column for the script
host you are trying to attach, there might be several possible causes for this:

• If you are trying to debug client-side script, did you remember to enable script
debugging on your machine (see the “Setting up your machine for script
debugging” section in the beginning of this document)?
• If you are trying to debug server-side script, is the user account the script host is
running under (dllhost.exe, inetinfo.exe, mtx.exe, w3wp.exe) a member of the
Debugger Users group? This is a common scenario when the user installed IIS
after installing VS.NET. Adding the IWAM_MachineName account to the
Debugger Users group usually solves this problem.
• pdm.dll or scriptle2.dll might not be correctly registered on your machine. First
make sure there’s just one copy of each of these dll’s on your machine and then
use regsvr32.exe to register them.
• Make sure that you have the default DCOM permissions on your machine. For
this, you can check if the
HKLM/Software/Microsoft/Ole/DefaultAccessPermission registry key exists on
your machine and if it does, just delete or rename it. This will restore the default
settings. If you made any intentional change to the DCOM Access permissions
and you don’t want the default to be restored, just add the Local System and the
user who is running the script host process to the DCOM Access permissions. To
do this:
1. Run dcomcnfg.exe
2. Go to Component Services | Computers | My Computer and open the
Properties dialog for My Computer.
3. Go to the Default COM Security tab and edit the Default Access
permissions. Add the System account and the account of the user the script
host is running as.

Note: Editing the default DCOM permission on your machine affect any
DCOM applications running on it. Make sure that you trust the users you are
adding to the Default Access permissions, otherwise this could open a security
hole.

-9-
 Also, it is recommended that you don’t modify the default settings on the
Default Properties tab either.

The JIT Dialog doesn’t come up

Make sure that JIT debugging is enabled in VS.Net. Go to Tools | Options | Debugging |
Just-In-Time and make sure that Script is checked there.

Can’t Hit Breakpoints in Client-side code in a Web Form

Are you attached to Internet Explorer and did you open the .aspx page from the Running
Documents window? If so, you might want to check the “There is no “Script” option for
attaching to the script host” section above.

Your Web Application is created at a Non-Default Port

If your ASP page is in a web application that was created at a different port than the
default port 80 and you enable ASP debugging for your project, you will not be able to
F5 the application. This is a known issue and the only work-around is to use the default
port 80.

Random weird debugging failures

If while you are debugging client side script in Internet Explorer you are encountering
different random debugging failures like discrepancies between the source code and the
location where the execution is stopped while stepping, some breakpoints not being hit all
the time or if you’re getting an unexpected error message saying that we that the
debugger cannot show source code for the location where execution is stopped, this is
another known issue. It is due to a timing bug in Internet Explorer 6. One possible work
around could be to have all your script code in one block, although this could not be
applicable or convenient all the time.

- 10 -