Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

DCOMCNFG and AppID\.exe mapping and implications


Summary

This article explains entries that are made for AppID\.exe mapping under the HKEY_CLASSES_ROOT key in the registry by using the DCOMCNFG utility, and the implications of it.

↑ Back to the top


More Information

Component Object Model (COM) applications are identified by a Globally Unique Identifier (GUID) that is called AppID and represent a server process for one or more classes. The remote activation, security, and other application-specific settings are stored in the local registry under the following key:

HKEY_CLASSES_ROOT\AppID
All AppID settings can be manipulated by using the DCOMCNFG utility (Dcomcnfg.exe). The DCOMCNFG utility provides users with an easy-to-use interface for controlling these application-specific settings.

However, a few issues must be noted when you use DCOMCNFG to make entries under the AppID key in the registry:


  • AppID\.exe Mapping:
    • DCOMCNFG adds AppID\.exe mapping under HKEY_CLASSES_ROOT in the registry only if none of the following keys is present:

      • HKCR\CLSID\<Guid> (AppID key, named value)
      • HKCR\APPID\<Guid>
      • HKCR\APPID\Exename.exe

      In this case, DCOMCNFG automatically synthesizes an AppID by using the first CLSID it encounters in that server (as done for legacy servers that were implemented before Windows NT 4.0), and adds it in the registry.
    • If any of these AppID keys is present, DCOMCNFG does not add the HKCR\APPID\Exename.exe key and or its value if it is not already present.

      This AppID-to-.exe mapping is used by COM to get some of the application-specific settings. If this mapping missing, such settings as Custom Access Permission, static endpoint, Authentication level, and so on are not used by COM, because COM has no way to map the .exe file name to the AppID.
  • Setting Custom Access Permission:

    When you set Custom Access permission by using DCOMCNFG, DCOMCNFG does not make the entry under AppID\{GUID} in the registry unless you click Edit, and then click OK. To do this:
    1. Start DCOMCNFG, and then select your application properties.
    2. Click the Security tab.
    3. Click Custom Access permissions, click Edit, and then click OK. The Custom access permissions are registered.
    If permissions are removed or groups are denied from any one key under HKCR\AppID, the COM+ MMC snap-in may display no entries under DCOM Config. When the snap-in is looping through the list to see what it has to display, it seems to fail if it is denied access to any key. Therefore, the snap-in displays an empty list.
  • Long File Names for Applications:

    DCOM uses the GetModuleFileName function to map the .exe file name to AppID for access permissions.

    GetModuleFileName returns long or short file names, based on what was passed to the CreateProcess function. Therefore, if your localServer32 value (under HKEY_CLASSES_ROOT\CLSID\{guid}\LocalServer32) has a long file name, this AppID\.exe mapping needs to be a long file name, or vice versa, for a short file name.

↑ Back to the top


References

For more information about a DCOMCNFG bug in Windows NT 4.0 Service Pack 4 (SP4), click the following article number to view the article in the Microsoft Knowledge Base:

216051 FIX: DCOMCNFG Windows NT 4.0 Service Pack 4 does not write .exe name under HKCR\APPID

↑ Back to the top


Keywords: kb, kbbillprodsweep, kbinfo, kbdsupport, kbdcom

↑ Back to the top

Article Info
Article ID : 246054
Revision : 6
Created on : 8/20/2020
Published on : 8/20/2020
Exists online : False
Views : 196