Error occurs when you debug a COM+ component in the Visual Basic IDE with an ASP client (259725)
The information in this article applies to:
- Microsoft Active Server Pages, when used with:
- the operating system: Microsoft Windows 2000
- the operating system: Microsoft Windows XP
- Microsoft Visual Basic Enterprise Edition for Windows 6.0
This article was previously published under Q259725 SYMPTOMS When you debug a Microsoft COM+ version 1.0 Component in
Visual Basic 6.0 on a Microsoft Windows 2000-based computer, the following
error message may appear in the browser when the client is an Active Server
Pages (ASP) page: Server object, ASP 0178 (0x800A0005)
The call to Server.CreateObject failed while checking permissions. Access is
denied to this object. When you debug a Microsoft COM+ version 1.5
Component in Visual Basic 6.0 on a Microsoft Windows XP-based computer, the
following error message may appear in the browser when the client is an Active
Server Pages (ASP) page: Server object, ASP 0178
(0x800A0005) The call to Server.CreateObject failed while checking permissions.
Access is denied to this object. This behavior only occurs when you
run the COM+ Component from within the Visual Basic integrated development
environment (IDE). The error does not occur when you run the COM+ Component in
a compiled state within a COM+ application. CAUSE The authenticating user, usually the
IUSR_<machinename> account if you are using anonymous access, does not
have the appropriate permissions to access the DCOM Server (VB6.exe in this
case). When you are debugging COM+ Components in the Visual Basic IDE, the
launching user is the interactive user; the user that is accessing the DCOM
Server is the authenticating user.
Because there is no DCOM entry for
VB6.exe, DCOM uses the default permissions. In Windows 2000 and Windows XP, the
DCOM Default Access Permissions are only given to the System account and the
launching user by default. Because the launching user and the user accessing
the DCOM Server are not the same, the error message shown in the "Symptoms"
section occurs. RESOLUTION There are two suggested workarounds: Workaround 1 Add a DCOM entry for VB6.exe into the registry. This allows you
to set specific DCOM permissions for debugging COM+ Component in Visual Basic.
- Create the entry for VB ASP Debugging in DCOM:
- Start Microsoft Notepad or another text editor and type
the following case-sensitive syntax:
REGEDIT4
[HKEY_CLASSES_ROOT\CLSID\{70F214BA-94E2-4bdf-8F30-32CB4A905E4D}]
@="VB ASP Debugging"
[HKEY_CLASSES_ROOT\CLSID\{70F214BA-94E2-4bdf-8F30-32CB4A905E4D}\LocalServer32]
@="vb6.exe"
[HKEY_CLASSES_ROOT\AppID\vb6.exe]
"AppId"="{70F214BA-94E2-4bdf-8F30-32CB4A905E4D}" - Save the file as Vbaspdbg.reg.
- Locate the folder where you saved the Vbaspdbg.reg file
and double-click the file (it automatically registers itself in the Windows
registry).
- Add the Everyone account to the DCOM permissions for Visual Basic ASP
debugging.
Windows 2000- Start DCOMCNFG. On the Start menu, click Run, and then type dcomcnfg in the dialog
box.
- On the Distributed COM Configuration Properties page, click the Applications tab, select VB ASP Debugging from the list, and then click Properties.
- In the VB ASP Debugging Properties property sheet, click the Securities tab, and then click to select the Use custom access permissions check box. Click Edit.
- In the Registry Value Permissions window, click Add, and then add the Everyone account for Allow Access.
- Click OK, and then click Apply to apply the changes and exit the Distributed COM Configuration properties page.
- Restart the computer so that the changes take
effect.
Windows XP
- Start COM+ Explorer. On the Start menu, click Admin Tools, and then click Component Services.
- Click to expand Component Services, click to expand Computers, click to expand My Computer, and then click to expand DCOM Config.
- Right-click VB ASP Debugging, and the click Properties.
- On the Securities tab, under Access Permissions, select Customize, and then click Edit.
- In the Access Permission window, click Add, and then add the Everyone account for Allow Access option.
- Click OK, click Apply, and then click OK to apply the changes and exit the DCOM Configuration properties
page.
- Restart the computer so that the changes take
effect.
Workaround 2- For debugging purposes, configure the Application
Protection of Virtual Directory where the ASP page resides to "High
(Isolated)." This forces the ASP page to run in its own process, which allows
the security to be changed without affecting the rest of the Web site.
- Start Internet Services Manager.
- Right-click the Virtual Directory where the ASP page
resides, and then click Properties.
- Click the Virtual Directory tab, and then select High (Isolated) in the Application Protection drop-down list.
- Click Apply.
- Turn off Anonymous Access for this Virtual Directory and
make sure Integrated Windows authentication or Basic authentication is selected:
- On the Properties dialog box for the Virtual Directory, click the Directory Security tab.
- Click Edit for Anonymous access and authentication control.
- Make sure that the Anonymous access check box is
cleared.
- Click either Integrated Windows authentication or Basic authentication.
- If Integrated Windows authentication is used, then run the
client browser to access the ASP page under the same user account as the Visual
Basic IDE debug session. If Basic authentication is used, enter the username
and password for the same user account that the Visual Basic IDE debug session
is running under.
Note The second workaround assumes that the COM "Default Access
Permissions" have not been altered. If the "Default Access Permissions" have
never been altered, then COM constructs an access control list (ACL) that
grants permission to the System account and Server Identity. In this scenario,
the Server Identity is the user logged in running the Visual Basic IDE debug
session. If the DCOM "Default Access Permissions" have been altered, then the
second workaround requires that the user account that the Visual Basic IDE
debug session is running under be added to "Default Access Permissions". This
can be done by using DCOMCNFG. For additional information, see the "COM security" link in the "More Information" section.
STATUS This behavior is by design.
Modification Type: | Major | Last Reviewed: | 12/8/2004 |
---|
Keywords: | kbBug kbCOMPlus kbDebug kbprb kbVBp600 KB259725 kbAudDeveloper |
---|
|