Microsoft KB Archive/259725

= Error occurs when you debug a COM+ component in the Visual Basic IDE with an ASP client =

Article ID: 259725

Article Last Modified on 12/8/2004

-

APPLIES TO

 Microsoft Active Server Pages 4.0, when used with:  Microsoft Windows 2000 Standard Edition

 Microsoft Windows XP Professional  Microsoft Visual Basic 6.0 Enterprise Edition

-



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.

<div class="cause_section">

CAUSE
The authenticating user, usually the IUSR_ 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 &quot;Symptoms&quot; section occurs.

<div class="resolution_section">

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. <ol> Create the entry for VB ASP Debugging in DCOM: <ol style="list-style-type: lower-alpha;"> Start Microsoft Notepad or another text editor and type the following case-sensitive syntax:

<pre class="fixed_text">REGEDIT4 [HKEY_CLASSES_ROOT\CLSID\{70F214BA-94E2-4bdf-8F30-32CB4A905E4D}] @=&quot;VB ASP Debugging&quot; [HKEY_CLASSES_ROOT\CLSID\{70F214BA-94E2-4bdf-8F30-32CB4A905E4D}\LocalServer32] @=&quot;vb6.exe&quot; [HKEY_CLASSES_ROOT\AppID\vb6.exe] &quot;AppId&quot;=&quot;{70F214BA-94E2-4bdf-8F30-32CB4A905E4D}&quot;

</li> Save the file as Vbaspdbg.reg.</li> Locate the folder where you saved the Vbaspdbg.reg file and double-click the file (it automatically registers itself in the Windows registry).</li></ol> </li> Add the Everyone account to the DCOM permissions for Visual Basic ASP debugging.

Windows 2000 <ol style="list-style-type: lower-alpha;"> Start DCOMCNFG. On the Start menu, click Run, and then type dcomcnfg in the dialog box.</li> On the Distributed COM Configuration Properties page, click the Applications tab, select VB ASP Debugging from the list, and then click Properties.</li> 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.</li> In the Registry Value Permissions window, click Add, and then add the Everyone account for Allow Access.</li> Click OK, and then click Apply to apply the changes and exit the Distributed COM Configuration properties page.</li> Restart the computer so that the changes take effect.</li></ol>

Windows XP

<ol style="list-style-type: lower-alpha;"> Start COM+ Explorer. On the Start menu, click Admin Tools, and then click Component Services.</li> Click to expand Component Services, click to expand Computers, click to expand My Computer, and then click to expand DCOM Config.</li> Right-click VB ASP Debugging, and the click Properties.</li> On the Securities tab, under Access Permissions, select Customize, and then click Edit.</li> In the Access Permission window, click Add, and then add the Everyone account for Allow Access option.</li> <li>Click OK, click Apply, and then click OK to apply the changes and exit the DCOM Configuration properties page.</li> <li>Restart the computer so that the changes take effect.</li></ol> </li></ol>

Workaround 2
<ol> <li>For debugging purposes, configure the Application Protection of Virtual Directory where the ASP page resides to &quot;High (Isolated).&quot; 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. <ol style="list-style-type: lower-alpha;"> <li>Start Internet Services Manager.</li> <li>Right-click the Virtual Directory where the ASP page resides, and then click Properties.</li> <li>Click the Virtual Directory tab, and then select High (Isolated) in the Application Protection drop-down list.</li> <li>Click Apply.</li></ol> </li> <li>Turn off Anonymous Access for this Virtual Directory and make sure Integrated Windows authentication or Basic authentication is selected: <ol style="list-style-type: lower-alpha;"> <li>On the Properties dialog box for the Virtual Directory, click the Directory Security tab.</li> <li>Click Edit for Anonymous access and authentication control.</li> <li>Make sure that the Anonymous access check box is cleared.</li> <li>Click either Integrated Windows authentication or Basic authentication.</li></ol> </li> <li>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 &quot;Default Access Permissions&quot; have not been altered. If the &quot;Default Access Permissions&quot; 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 &quot;Default Access Permissions&quot; 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 &quot;Default Access Permissions&quot;. This can be done by using DCOMCNFG. For additional information, see the &quot;COM security&quot; link in the &quot;More Information&quot; section.</li></ol>

<div class="status_section">

STATUS
This behavior is by design.

<div class="moreinformation_section">

MORE INFORMATION
This behavior does not occur in Microsoft Windows NT 4.0 and IIS 4.0. For additional information regarding the ASP 0178 error on a Windows NT 4.0-based computer, click the article number below to view the article in the Microsoft Knowledge Base:

198432 PRB: Server Object Error 'ASP 0178' Instantiating COM Object

For additional information about COM security, visit the following Microsoft Developer Network (MSDN) Web site:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/security_0icz.asp

Keywords: kbbug kbcomplus kbdebug kbprb kbvbp600 KB259725

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.