470,815 Members | 1,106 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,815 developers. It's quick & easy.

Erratic Sever Side Script Debugging ASP 3.0/.NET DLLs: Problems and Solution

This is about debugging server side scripts that make calls to
middle-tier business DLLs. The server side scripts are legacy ASP 3.0
pages, and the DLLs are managed DLLs converted/developed with VB.NET.
What I want from debugging is to be able to step into the methods in
the DLLs called from ASP scripts using Visual Studio .NET.

For typical script debugging issues, you can read and follow the two
documents on debugging: "The VS7 Debugger doesn't work. What can I
do?" by Min Kwan Park
and "How to Debug Script Code Using Visual Studio .NET" by Monica
Rosculet (use google search to find it). Both authors are a member of
the VC# Debugger QA Team from Microsoft. If you are just like me,
still having problems with debugging ASP server side scripts after
reading these two docs, then this piece of advice may be for you. Hey,
what a surprise! We've never expected that, as demonstrated in the two
Microsoft documents, debugging could be such a big issue with Visual
Studio .NET developed by the 800 pound gorilla. Debugging issues are
causing not only pains somewhere in your body, but also negative
impacts in your project schedule.

If you are lucky enough working on developing web applications within
the managed code domain such as based on ASP.NET with DLL written
entirely in VB.NET, you are blessed with easy and straightforward code
debugging using VS.NET. However, if you are straddled in a
half-managed world working on legacy ASP scripts with managed DLLs, it
turns out it is absolutely non-trivial to succeed in debugging the
method calls between the ASP scripts and DLLs using VS.NET IDE. Part
of the reason for this misfortune is that there are quite a few
settings here and there, each needed to be set up/configured properly,
and other part of the reason is due to some strange behaviors probably
due to interactions between IIS and .NET so that a proper execution
sequence is necessary to follow, and some other part of the reason is
due to some known issues in the IE explorer that cause unpredictable
behaviors. The difficulty or erratic behavior in debugging server side
script ought to be caused, as illustrated below, by some (unknown)
BUGs created on the Microsoft side.

Configuration of My PC:
Brand new Dell Precision M60, XP professional, VS.NET 2003 Enterprise
Architect (MSDN Subscriber Download version), IIS 5.1

Preparation for debugging:
1. The login/debug user needs to be a member of the Debugger Users
2. In web.config, debug="true";
3. ASP Debugging in Configuration Properties dialog is enabled;
4. Set Application Protection mode to Low (IIS Process) (Never set to
Medium (Pooled) or High(Isolated)) (As it turned out, this setting was
crucial for ASP server side script debugging, even though the
Microsoft technical help people rarely mentioned or emphasized it).
(To set the Application Protection, open Computer Management window
using mmc.exe or go to administrative tools. Under Internet
Information Service folder, expand Default Web Site node, and
right-click your web application and select properties. Under
Directory tab, choose Low from the Application Protection comboBox.)

Irrelevant settings:
There are several settings that are irrelevant to enable the server
side script debugging. Here is a list of those settings I've found:
1. Uncheck Disable script debugging option in Internet Explorer
2. Change userName from "machine" to "system" in the processModel tag
of machine.config in folder
"C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONF IG"
3. Adding users in the Debugger Users group: ASPNET, IWAM_MACHINENAME
4. Check Enable ASP server-side script debugging, and check Enable ASP
client-side script debugging in the web application in IIS (They are
not needed if the web pages are part of a web application project)
5. Check Caches ISAPI applications in the properties dialog for the
web application in the mmc console tree (Default Web
Site->properties->Configuration->Mapping tab)

Debugging problem symptoms:
1. After a project with ASP scripts and .NET DLLs was installed in my
PC from SourceSafe, the Step Into debugging From ASP to DLLs' methods
was not working;
2. Using the modules window to view which dlls were loaded, the window
was always empty without showing any dlls, even after Show Modules For
All Programs was selected;
3. Using Deubg|processes... to view debugged processes, only
dllhost.exe and iexplore.exe were attached for debugging. inetinfo.exe
was never attached. In fact, inetinfo.exe with the Script type was no
where to be found even in the list of Available Processes;
4. The break points set in .NET DLLs either had or had not a question
mark in them. For those with question marks, a tip message stated "The
breakpoint will not currently be hit. No symbols have been loaded for
this document.";
5. Worst of all, you may think using system's Diagnostics classes may
help to break or write a trace info to the log file for debugging
purpose if the Step Into is not working. The fact is that the methods
in Diagnostics' Debugger and Debug classes such as
System.Diagnostics.Debugger.Break(), and
System.Diagnostics.Debug.Write() are not working at all inside DLLs if
the Step Into is not functioning. You can also forget Console.Write()
here: It doesn't work either. Essentially one is completely shut off
any debugging capability inside DLLs;
6. Debugging of the same project was working however in other PCs,
even though it was noticed that debugging was in a hit-and-missed
state, meaning debugging may or may not work in a seemingly
unpredictable fashion. When debugging was working in other PCs,
inetinfo.exe was the program loading all the DLLs in the modules
window, and was one of the attached debug processes (alongside with

More debugging problem symptoms:
7. I examined the Application Protection mode for the web application
before and after the debugging session, the mode displayed the preset
Low state. So it seemed everything was deceptively fine with IIS at
the first look. However, after the debug session has started, it was
noticed (by accident) that the Application Protection mode switched to
the High value inexplicably. This weird switching proves to be very
troublesome. In IIS, inetinfo process (inetinfo.exe) is used if you
are in low protection/isolation mode and DLLhost (dllhost.dll) is used
if you are in medium and high. Since we need inetinfo.exe to help to
debug ASP/.NET Dlls, the switching of the protection mode from Low to
High when debugging is running changes the IIS process from
inetinfo.exe to dllhost.exe and prevents one from debugging into the
methods in .NET Dlls using inetinfo.exe. This explains why I saw no
inetinfo.exe with type Script appearing in the Available Processes
List and no DLLs loaded by inetinfo.exe in the modules window when the
debugging session is running. So my goal is clear: Do whatever to have
inetinfo.exe attached as one of debugging processes. I tried and
failed, and tried and failed..., and it proved getting inetinfo.exe
attached was still evasive. I need someone from Microsoft to explain
why the protection mode setting is changed from Low to High when a
debugging process is initiated by VS.NET IDE.
8. It was noticed even in the PCs where debugging was working that
there was no guaranttee that when you pressed F5 the debugging with
Step Into functioning would work. If debugging was not working, the
modules window also showed no loaded DLLs (both system and application
specific). Once this was happening, we had the project or any
components checked out from VSS and happily saw that the debugging
started working, and ever working from that moment on even when the
project was checked back in into VSS. This behavior repeated itself
every time you re-started the PC. It might (deceptively) lead one to
conclude that by changing write/read attribute of any components in
the project one may magically have debugging working. This plausible
thought seemed even more far-fetched.

New Findings:
9. ASP web pages are often categorized and placed under sub-folders as
determined by business/logical requirements. These folders inherit the
property settings of those of the web application under IIS. For
example, the Application Protection mode of these folders by default
takes the same value as that of the main web application. During
debugging, the Protection mode of these folders is also switched from
Low to High state inexplicably just like that of the main web. As such
debugging of the ASP scripts in the sub-folders suffer the same fate
of failing to Step Into. The good news is that under IIS, you can
configure the properties of the sub-folders independently and treat
them as though they were individual web apps. To do that, in the mmc
console window you right-click on a sub-folder and select properties
from the dropdown list, click the Create button to create a web
application for this sub-folder. Then you can set the Application
Protection mode to Low for the sub-folder. As it turns out, starting a
debugging session DOES NOT change the protection mode setting of the
sub-folder. VOILA, we have a chance to use inetinfo.exe as the debug
process for the ASP scripts placed under the subfolders! At last,
debugging under IIS is doing what it supposes to do, albeit for
subfolders only. Now, as F5 is pressed I can see inetinfo.exe appears
as one of the attached debugged processes. But wait: I still can't
step into the methods in the called .NET DLL and I don't see any DLLs
loaded on the modules window. What is going on here?

More new findings:
10. I really don't know what is going on behind the scene and why I
can't step into the DLLs. The only thing I know by accident is that I
need to immediately stop the first debug session, and start a new
debug session right away. And here you go, all the needed DLLs (both
system and application specific) are appearing on the modules window,
and I can step into every corner of the called DLLs without sweat. All
of sudden, the methods in Diagnostics' Debugger and Debug classes such
as System.Diagnostics.Debugger.Break(), and
System.Diagnostics.Debug.Write() are now working. It is pretty sure
that I don't need any help from VSS to enable Step Into. But still,
this dependency of next debugging on the history of the previous
debugging sessions is beyond one's imagination, and I hope someone
from Microsoft can show me why.

My Solution:
In summary for the solution of fixing the Step-Into debugging problem
(assuming every relevant settings have been configured properly),
1. you need to have a proper design of ASP scripts and those ASP
scripts have to be placed in a subfolder to allow for Step-Into
debugging, and
2. you need to start the debug session more than once to be able to
invoke Step Into debugging.

Questions to Microsoft:
This is an ideal case of the saying "I know how to do but I don't know
why". Here I post two questions to Microsoft:
1. Why is the Application Protection setting changed from Low to High
in the main web application but not in its sub-folders, once F5 is
2. Why do I need to start debug session more than once to load DLLs
and to enable Step Into debugging?
Nov 18 '05 #1
0 2990

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Poul M | last post: by
3 posts views Thread by Brian Bischof | last post: by
6 posts views Thread by Brian Bischof | last post: by
1 post views Thread by ramendra | last post: by
6 posts views Thread by den 2005 | last post: by
5 posts views Thread by =?Utf-8?B?dXNmaW5lY2F0cw==?= | last post: by
reply views Thread by mihailmihai484 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.