PRB: VBScript 'STOP' Statement in .wsc Components Does Not Start Script Debugger When Called from ASP (269827)

IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

SYMPTOMS

When you use Visual Basic Script's (VBScript) STOP statement within Windows Script Components (.wsc) called from an Active Server Page to halt and display script in the Microsoft Script Debugger or the Microsoft Visual InterDev 6.0 debugger, the STOP statement may fail to work.

CAUSE

This problem is caused by a modification to VBScript. In versions 5.0 and earlier, the STOP statement launches the Script Debugger. Occasionally, scripts that run unattended on servers can also launch the Script Debugger when they encounter a STOP statement. The scripts appear to stop responding ("hang"). In order to alleviate this problem, a registry key has been added. The new registry key indicates whether the user wants to launch the debugger. This key is turned off by default in version 5.1 of the script engines.

RESOLUTION

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

In order to re-enable the STOP statement, you can manually set the registry key to launch the Script Debugger when a STOP statement is encountered. Depending on the circumstances, the registry key is:

HKEY_CURRENT_USER\Software\Microsoft\Windows Script\Settings

-or-

HKEY_USERS\.DEFAULT\Software\Microsoft\Windows Script\Settings

In this key is a value called JITDebug. To re-enable the STOP statement, set the value of this key to "1." If the JITDebug key does not exist, you can add it as a decimal DWORD in the Settings key. In addition, give the appropriate users read permissions on this key.

MORE INFORMATION

If the process security token matches the interactive security token, then the process (Inetinfo.exe, Mtx.exe or Dllhost.exe) queries the HKEY_CURRENT_USER registry subtree for the JITDebug value. Otherwise, the process queries the HKEY_USERS registry subtree. The following table lists the specific scenarios:

Process	Console	Thread	Result
Inetinfo.exe(system)	TestUser1	IUSR	HKEY_USERS
Inetinfo.exe(system)	TestUser1	TestUser1	HKEY_USERS
Dllhost.exe(IWAM)	TestUser1	IUSR	HKEY_USERS
Dllhost.exe(TestUser1)	TestUser1	IUSR	HKEY_CURRENT_USER
Dllhost.exe(TestUser1)	TestUser1	TestUser1	HKEY_CURRENT_USER
Dllhost.exe(TestUser1)	Administrator	IUSR	HKEY_USERS
Dllhost.exe(TestUser1)	Administrator	Administrator	HKEY_USERS

The authenticating user (thread token) should also have read permissions to the appropriate registry key. For example, if you are using Anonymous authentication, and you set your Web application's Application Protection to High (Isolated), and you set the Identity of the corresponding COM+ Package to the IWAM account, then you should give the IUSR account read permissions to the following registry key:

HKU\.DEFAULT\Software\Microsoft\Windows Script\Settings\

If the authenticating user does not have read permissions to the appropriate registry key, you cannot debug your .wsc component.

REFERENCES

For additional information, click the article numbers below to view the articles in the Microsoft Knowledge Base:

252895 PRB: VBScript 'Stop' Statement Does Not Start Script Debugger

232394 HOWTO: Catch Run-time Errors in an ActiveX Script Host