Article ID: 230305
This article was previously published under Q230305
This article has been archived. It is offered "as is" and will no longer be updated.
We strongly recommend that all users upgrade to Microsoft Internet Information Services (IIS) version 6.0 running on Microsoft Windows Server 2003. IIS 6.0 significantly increases Web infrastructure security. For more information about IIS security-related topics, visit the following Microsoft Web site:
This article contains a copy of the Script Debugger Release Notes included with the Windows NT 4.0 Option Pack. It is listed here so that the issues it covers will be included in queries that are performed against the Knowledge Base.
The file containing these Release Notes is located in <%SystemRoot%>\Help\Iis\Htm\Core\Scrdbgrm.htm.
Note: Knowledge Base articles may be distributed in either ASCII-text or HTML form. If you are viewing the ASCII-text version of this article, some formatting may have been lost when it was converted from the original HTML form of Scrdbgrm.htm
Following are the contents of the Readme file as it shipped with the products listed previously. It has not been edited by the Microsoft Developer Support Knowledge Base editing team.
Microsoft Script Debugger Release Notes
(C)Microsoft Corporation, 1997
This document provides information about using the Microsoft Script Debugger, including tips for installing and using the debugger successfully, and information that became available too late to be included in the documentation.
Using the Script Debugger with Microsoft Visual Studio 98In general, you should not install the Script Debugger if you have already installed Visual Studio 98 or any of its component products such as Microsoft Visual InterDev or Microsoft Visual J++. Visual Studio includes its own debugger that you can use to debug scripts and Java components. If you install the Script Debugger after installing any Visual Studio products and you will no longer be able to start the Visual Studio debugger in response to errors reported by Internet Explorer 4.0.
Using the correct versionMicrosoft Script Debugger works with Microsoft Internet Explorer 4.0 or with Internet Information Server 4.0. Because the Script Debugger is designed to be generic across script hosts, Setup does not check for specific versions of products being installed, so you must ensure that you are running the correct versions of these products. If you attempt to use the Script Debugger with earlier versions of Internet Explorer (such as Internet Explorer 3.0 or the Platform Preview release of Internet Explorer 4.0), or with earlier versions of Internet Information Server, the debugger will not work and could disrupt IIS service.
Uninstalling previous versions of the Script DebuggerIf you installed the Script Debugger for Internet Explorer 3.0, you must uninstall that version before proceeding with this installation.
Uninstalling IISIf you uninstall Internet Information Server 4.0, the uninstall process will also remove the Script Debugger, even if you installed the Script Debugger separately. You can reinstall the Script Debugger by running the IIS installation and choosing to install just the Script Debugger.
Starting a browser before displaying HelpHelp is displayed in the default Web browser. If you are running Internet Information Server, start Internet Explorer 4.0 before choosing Help Topics from the Help menu. If the browser is not already running when you display Help, the debugger might display a blank window, and the Script Debugger might hang.
Viewing Help if no browser is installed on the serverIf you are debugging on a server that has no browser installed, you might not be able to view Help, because Help is displayed in the default browser. However, if you have permission to access the Web server as a file server, you can try using a browser on another machine to view the Help file. Look for a file on the server called SDbug.htm, and use file protocol (file://), not HTTP protocol (http://).
Entering file names when opening HTML documentsWhen you choose Open from the File menu to open an existing document in the Script Debugger, you must provide a complete file name, including extension, in the File Name box.
Opening HTML documents from the Desktop in Microsoft Windows NTIn Windows NT, when you use the Open dialog box to open a file, you can display documents by selecting Desktop from the Look In list. However, in this version of the debugger, the content of the Open dialog box reflects the desktop setting for the default user, not for the current user.
Opening documents in Windows NT shared directoriesIn Windows NT, when you use the Open dialog box to open a file on a shared drive with password protection, use "\*" at the end of the path and file name, as in this example:
Debugging in the Active DesktopIf you use the Script Debugger when Internet Explorer is in Active Desktop mode, all programs that are integrated into the Active Desktop are controlled by the debugger. For example, because Windows Explorer is part of the Active Desktop, it will be suspended when the debugger is open and waiting at a breakpoint. When you run the current document or close the debugger, Windows Explorer will again work normally.
Browsing a document after closing the debuggerIf you finish a debugging session and close the Script Debugger, and then return to Internet Explorer and continue working with the document you were just debugging, the browser sometimes restarts the debugger.
Working with multiple documentsIf you open two documents in two windows in Internet Explorer, you can debug only one of them at a time. For example, if you are in break mode in one document (are at a breakpoint or are stepping through code), you cannot also be working in the other document.
Entering commands in the Command windowYou can display the Command window at any time while the Script Debugger is open, but commands that you type into the Command window have no effect unless you are in break mode.
Problems debugging after executing Document.WriteUsing the <CODE>Document.Write</CODE> command can cause problems under these circumstances:
Setting breakpoints on invalid linesIf you attempt to set a breakpoint on a line that does not contain script (such as a line of HTML code) the Script Debugger sets the breakpoint on the next valid code statement, even if that statement is many lines away from where you tried to set the breakpoint.
Calling functions with breakpointsIn the Command window, if you call a function that contains a breakpoint, Internet Explorer might hang.
Displaying the line indicator correctlyThe Script Debugger might not display the current line indicator properly if:
NoteIf the line indicator is not properly displayed, you can try stepping into the next line to restore the indicator.
Features not fully implementedThe following features are not fully implemented in this version of the Script Debugger:
Known issues when debugging client scriptsThe following are additional known issues with using this version of the Script Debugger in Internet Explorer 4.0:
NoteBe sure to review the information under Script Debugging in Internet Explorer 4.0 as well.
Inspecting variables after a run-time errorIf you invoke the debugger after a run-time error, the Command window cannot be used to inspect variable values in an ASP page. However, you can still evaluate expressions using the default language.
Debugging cached pagesIf you are using Internet Explorer 3.0 to request pages from the server, or you are using Internet Explorer 4.0 and have set the browser to cache pages (you set "Check for newer versions of stored pages" to "Never"), Stop and debugger command will be ignored.
Illegal object references in the Command windowIn the Command window, if you create an instance of an object and then use improper syntax to reference its properties or methods, the Script Debugger might hang. For example, in the following sequence of VBScript commands, the second is illegal because it is not preceded with a "?" operator, and will therefore hang the debugger:
Set myObj = Server.CreateObject("MSWC.Browsertype") myObj.frames
Debugging after IIS has been shut downIf you shut down Internet Information Server while a debugging session is running, and then attempt to continue debugging, the Script Debugger will generate a General Protection Fault.
Calling functions repeatedlyIf you are at a breakpoint, open the Command window, and call a function repeatedly that is defined in a script on the page, the debugger might hang when you continue running the document.
Debugging JavaThis release of the Script Debugger includes support for debugging Java code in client applications, including setting breakpoints, checking the call stack, and using the command window. However, debugging Java code on Internet Information Server is not fully supported, and can result in unexpected behavior.
Debugging Java applications on DEC Alpha computersThis version of the Script Debugger does not fully support debugging Java applications on DEC Alpha computers. If you attempt to debug Java applications, you might experience errors.
Debugging a multi-threaded Java applicationIf you break into a Java application that is using multiple threads, you can navigate to another thread by choosing it in the Call Stack window. When you do, the current line indicator is displayed in the thread to which you have navigated. However, debugger commands such as Step Into, Step Over, and so on, affect only to the thread where the Script Debugger broke, not the one to which you have navigated and which shows the current line indicator.
(C) 1997 Microsoft Corporation
These materials are provided "as-is," for informational purposes only.
Neither Microsoft nor its suppliers makes any warranty, express or implied with respect to the content of these materials or the accuracy of any information contained herein, including, without limitation, the implied warranties of merchantability or fitness for a particular purpose. Because some states/jurisdictions do not allow exclusions of implied warranties, the above limitation may not apply to you.
Neither Microsoft nor its suppliers shall have any liability for any damages whatsoever including consequential, incidental, direct, indirect, special, and lost profits. Because some states/jurisdictions do not allow exclusions of implied warranties, the above limitation may not apply to you. In any event, Microsofts and its suppliers entire liability in any manner arising out of these materials, whether by tort, contract, or otherwise shall not exceed the suggested retail price of these materials.
Contact us for more help
Connect with Answer Desk for expert help.