Microsoft KB Archive/180525

= PRB: DCOMCNFG Reports Multiple Copies of DCOM Server =

Article ID: 180525

Article Last Modified on 2/11/2005

-

APPLIES TO


 * Microsoft Visual Basic 5.0 Enterprise Edition
 * Microsoft Visual Basic 6.0 Enterprise Edition

-



This article was previously published under Q180525



SYMPTOMS
When running DCOM Config (DCOMCNFG.EXE) to configure your DCOM server, you find several copies of your server on the Applications tab that have been indexed using a number in parenthesis:

MyServer.MyClass(1) MyServer.MyClass(2) ...

Only one of these entries will function correctly.



CAUSE
This is caused by an AppID registry key that is left over from a previous build of the server project. This key did not get removed from the server machines registry when the server was either unregistered using REGSVR32.EXE and CLIREG32.EXE, or when a new build of the server was created without having binary compatibility setup for the server project, thus creating a new set of registry keys and leaving an extra copy of the AppID key structure.

DCOMCNFG.EXE uses the AppID keys to determine if a registered class is available as a remote component. If more than one AppID key is present for the same server, then DCOMCNFG.EXE will display them all on the Applications tab as available remote components. Only one of the listed server entries will work correctly because the rest of the entries are missing the key structure required for remote component creation.



RESOLUTION
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

To Resolve the Issue if the Problem Has Occurred
You will need to remove the extra AppID keys from the server machines registry manually using Registry Editor (Regedit.exe).

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.


 * 1) Start REGEDIT.EXE and locate the following key for your server:

HKEY_CLASSES_ROOT\AppID\
 * 1) Select the AppID value in the right-hand pane. It should resemble a standard class id (such as {1A113664-5B4D-11D1-A3F5-00AA00B7B36F}).
 * 2) Right-click the AppID value, and then select "Modify" from the shortcut menu. The value should appear selected in an Edit String dialog box.
 * 3) Press the key combination CTRL+C to copy this value to the clipboard. NOTE: Also record this value to another place for use in step 19.
 * 4) Click the Cancel button in the Edit String dialog box.
 * 5) Scroll the left pane in RegEdit back to the top and select HKEY_CLASSES_ROOT.
 * 6) From the Edit menu, select Find (CTRL+F) to open the Find dialog box.
 * 7) Press the key combination CTRL+V to paste the value from above into the Find dialog's text box.
 * 8) Click the Find Next button.
 * 9) You should now see this value selected as an open key under the AppID section of HKEY_CLASSES_ROOT. The default value for this key should be the name of your server's first class.

NOTE: If you do not see this value in the AppID section of HKEY_CLASSES_ROOT, then close REDEDIT.EXE and proceed to the section titled "To Avoid This Issue in the Future" later in this article.

The AppID selected is the valid AppID that you will want to keep. Make a note of the values listed in this key for a comparison with the invalid AppID keys you will find in the following steps. Typical entries for this key are AccessPermission, LaunchPermission, and RunAS.
 * 1) Select the default value in the right-hand pane. It should be the name of the first class in your server.
 * 2) Right-click the default value, and then select "Modify" from the shortcut menu. The value should appear selected in an Edit String dialog box.
 * 3) Press the key combination CTRL+C to copy this value to the clipboard.
 * 4) Click the Cancel button in the Edit String dialog box.
 * 5) Scroll the left pane back to the top of the AppID section and click on AppID in the left pane (HKEY_CLASSES_ROOT\AppID).
 * 6) From the Edit menu, select Find (CTRL+F) to open the Find dialog box.
 * 7) Press the key combination CTRL+V to paste the value from step 13 into the Find dialog's text box.

WARNING: This is where you need to be very careful. You are going to delete all occurrences of this value in the AppID section that do not match the AppID recorded in step 4. Make absolutely certain that any entries you delete containing this name are limited to the AppID section of HKEY_CLASSES_ROOT. As an extra precaution, you may want to Export each registry key before deleting. For more information on Exporting registry keys, see the Online documentation for RegEdit.Exe.
 * 1) Click the Find Next button. If the search takes you out of the AppID section of HKEY_CLASSES_ROOT, then proceed to Step 21.
 * 2) If you find an entry in the AppID section of HKEY_CLASSES_ROOT, whose default value is the name of your server's first class, and it does not match the AppID value recorded in step 4, then delete the key by selecting Delete from the Edit menu.

NOTE: These invalid AppID keys are usually missing their RunAS value.
 * 1) Repeat steps 18 and 19 until the only entry left in the AppID section, with a default value matching the value obtained in step 13, is the value obtained in step 4.
 * 2) Close Registry Editor and run DCOMCNFG.EXE.
 * 3) You should now see only one instance of your server on the Applications tab.

To Avoid This Issue in the Future
Set up your server project to use binary compatibility.

 After you have built your server project the first time, immediately create a new folder in the project folder named "Compat" or something meaningful to you. Copy the EXE that you just created to this new folder, leaving the original in the build folder. Open the Projects Properties dialog and select the Component tab. Check the binary compatibility option and browse to the new copy of the EXE in the Compat folder. Make sure you compile all future builds to the project folder, not to the Compat folder which is storing the original .exe, to maintain binary compatibility. If you must break binary compatibility (changing an existing interface) then Visual Basic will create a new GUID for the project, creating a new set of registry keys, thus leaving the old build showing in DCOMCNFG.EXE.</li> You should unregister the existing server BEFORE compiling the incompatible build. You can unregister the server .exe using the following commands at the Command Prompt or in the Windows Run dialog:

REGSVR32.exe /u <yourDCOMserver.exe>"

-and-

CLIREG32.exe /u <yourDCOMserver.vbr>"

NOTE: You will still see the old server in DCOMCNFG.exe. Please refer to the above section for information regarding removing the old server from the list of applications in DCOMCNFG.EXE.</li></ol>

<div class="moreinformation_section">

Steps to Reproduce Behavior

 * 1) Open an existing DCOM server project in Visual Basic.
 * 2) From the Project menu, select the Projects Properties. On the Component tab, select "No compatibility."
 * 3) Rebuild the server project into a new .exe.
 * 4) Run DCOMCNFG.EXE. You will see a second copy of your server on the Applications tab with a number in parenthesis appended to the end of the class name. This entry will have only two tabs when you select its properties instead of the usual four tabs. These entries can be left here safely, just make sure that you configure the one with all four tabs.

<div class="references_section">