PRB: DCOMCNFG Reports Multiple Copies of DCOM Server (180525)
The information in this article applies to:
- Microsoft Visual Basic Enterprise Edition for Windows 5.0
- Microsoft Visual Basic Enterprise Edition for Windows 6.0
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.
RESOLUTIONIMPORTANT: 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. - Start REGEDIT.EXE and locate the following key for your server:
HKEY_CLASSES_ROOT\AppID\<YourServer.exe>
- Select the AppID value in the right-hand pane. It should resemble a
standard class id (such as {1A113664-5B4D-11D1-A3F5-00AA00B7B36F}).
- Right-click the AppID value, and then select "Modify" from the shortcut
menu. The value should appear selected in an Edit String dialog box.
- 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.
- Click the Cancel button in the Edit String dialog box.
- Scroll the left pane in RegEdit back to the top and select
HKEY_CLASSES_ROOT.
- From the Edit menu, select Find (CTRL+F) to open the Find dialog box.
- Press the key combination CTRL+V to paste the value from above into
the Find dialog's text box.
- Click the Find Next button.
- 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.
- Select the default value in the right-hand pane. It should be the
name of the first class in your server.
- Right-click the default value, and then select "Modify" from the
shortcut menu. The value should appear selected in an Edit String dialog
box.
- Press the key combination CTRL+C to copy this value to the clipboard.
- Click the Cancel button in the Edit String dialog box.
- Scroll the left pane back to the top of the AppID section and click
on AppID in the left pane (HKEY_CLASSES_ROOT\AppID).
- From the Edit menu, select Find (CTRL+F) to open the Find dialog box.
- 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.
- Click the Find Next button. If the search takes you out of the AppID
section of HKEY_CLASSES_ROOT, then proceed to Step 21.
- 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.
- 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.
- Close Registry Editor and run DCOMCNFG.EXE.
- 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.
- 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.
REFERENCES
For more information regarding project compatibility, see the following
article in the Microsoft Knowledge Base:
161137
: HOWTO: Use Project and Binary Compatibility
(c) Microsoft Corporation 1998, All Rights Reserved.
Contributions by Randy Russell, Microsoft Corporation
Modification Type: | Minor | Last Reviewed: | 2/11/2005 |
---|
Keywords: | kbprb KB180525 |
---|
|