We have been trying to install a COM DLL on a new server. The interface is Classic ASP. The Map Connector DLL seems to be the problem but that is as far as I am able to get.
The advice below relates to both Server.CreateObject
and CreateObject
use in
vbscript jscript vba
The Web Server sections are specific to asp-classic but still worth reading.
Server.CreateObject Failed
is caused most commonly when Web Applications are moved from one Web Server to another without an understanding of external COM components that are in use and registered with the Web server.
From PRB: Server.CreateObject Returns HTTP 500.100 or ASP 0177 Error (0x8007007E)
This error occurs when you attempt to use the Server.CreateObject method to instantiate an object that is not registered on the local system.
If you are using COM components inside a ASP Web application you will see a line like this
set g_pcmsrv=Server.CreateObject("PCMServer.PCMServer")
Usually the error will point to the Set
line which makes identifying the cause easier (luckily you have some nice trace code in place so it's even better).
Note: Please be careful when accessing the Windows Registry as it is very easier to inadvertently make changes that have serious consequences for the Operating System and in extreme cases will require a system restore or re-install / repair.
The string inside the CreateObject
method is known as a ProgId
and is used as an identifier to a key inside the Windows Registry that can be found inside the
Note: Windows Registry can be browsed in most versions of Windows using the
regedit.exe
also known as the Registry Editor. Be very careful when using this tool to browse the Windows Registry.
HKEY_CLASSES_ROOT
and by extension
HKEY_LOCAL_MACHINE\Classes
Whenever the ASP processor encounters a ProgId
it attempts to talk to the Windows Registry and find a corresponding key that denotes the location of the registered COM accessible DLL.
HKEY_CLASSES_ROOT\PCMServer.PCMServer
A common approach to this is the key contains a subkey called CLSID
which points to the Class GUID for the associated registered DLL. Once the GUID key is located in the
HKEY_CLASSES_ROOT\CLSID
hive it can be used to find the location by looking in the subkey
HKEY_CLASSES_ROOT\CLSID\{GUID from CLSID}\InprocServer32
where the location will be stored in the (default)
value.
Example Using the
ProgId
-Scripting.FileSystemObject
Locate
Scripting.FileSystemObject
subkey inHKEY_CLASSES_ROOT
HKEY_CLASSES_ROOT\Scripting.FilesystemObject
Identify GUID from subkey
CLSID
HKEY_CLASSES_ROOT\Scripting.FilesystemObject\CLSID (default) - "{0D43FE01-F093-11CF-8940-00A0C9054228}"
Use GUID to find registered DLL subkey in
HKEY_CLASSES_ROOT\CLSID
HKEY_CLASSES_ROOT\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228}
Check subkey
InprocServer32
(default)
value for the DLL locationHKEY_CLASSES_ROOT\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228}\InprocServer32 (default) - "C:\Windows\System32\scrrun.dll"
ProgId
for PCMServer.PCMServer
in the Registry?If you cannot find the corresponding ProgId
in the registry it is likely due to one of two reasons we will elaborate on here.
COM DLLs can be registered and have the corresponding Registry entries created by running the regsvr32.exe
tool from the Windows Command Prompt using elevated permissions (this varies from version to version of Windows).
Before we continue though the architecture of both the Operating System and the mode used by the ASP Web application are very important.
Most newer hardware is 64 Bit this creates a conundrum in Windows as it now has to support newer 64 bit architecture and still maintain support for 32 bit architecture. The solution Microsoft came up with was to split the OS in two, so we have 64 bit elements and 32 bit elements. The main OS programs are broken down into two folders (only on 64 bit OS because a 32 Bit OS doesn't have to contend with 64 Bit, even if the hardware is capable of it).
Note: On 32 Bit only systems just use the 64 Bit locations for both System Files and the Windows Registry.
On a 64 Bit OS the System Programs are located in
For 64 Bit programs
%SystemRoot%\System32\
For 32 Bit programs
%SystemRoot%\SysWOW64\
This is also applies to the Windows Registry
64 Bit
HKEY_CLASSES_ROOT
32 Bit
HKEY_CLASSES_ROOT\Wow6432Node
So for example on a 64 Bit version of Windows, the following command will register the PCMSRV32.DLL
in the 32 Bit Registry and create the associated COM DLL registry keys.
C:\Windows\SysWOW64>regsvr32 "C:\Windows\PCMSRV32.DLL"
As everything begins to support 64 Bit including IIS you still need to be able to support legacy applications that only support 32 Bit COM, so IIS introduced in IIS 6.0 (starting with Windows Server 2003, Service Pack 1) under the Application Pool settings the configurable property Enabled32BitAppOnWin64
which allows the Application Pool to run in 32 Bit mode on 64 Bit versions of Windows.
With this in mind before you register the COM DLL to know where you should be registering it you need to know whether the Application Pool is running in 32 Bit Mode. In IIS 7.0 and above you can just check this from the Application Pool properties inside the IIS Manager application. The setting is in the Advanced Settings
under the General
section and is called Enable 32-Bit Applications
(can also be configured in the applicationHost.config
using enable32BitAppOnWin64
under the <ApplicationPools>
section).
If Enable 32-Bit Applications
is set to False
The IIS Application Pool is running in native 64 Bit mode and any COM DLLs that need to be used by the ASP Web Application will need to support 64 Bit and be registered using the 64 Bit version of regsvr32.exe
to be added into the 64 Bit registry.
C:\Windows\System32>regsvr32 "C:\Windows\PCMSRV32.DLL"
If Enable 32-Bit Applications
is set to True
The IIS Application Pool is running in 32 Bit Mode and any COM DLLs that need to be used by the ASP Web Application will need to be 32 Bit COM DLLs and be registered using the 32 Bit version of regsvr32.exe
to be added into the 32 Bit registry.
C:\Windows\SysWOW64>regsvr32 "C:\Windows\PCMSRV32.DLL"
Registering the COM DLL Using the Wrong Version of regsvr32.exe
For example, using
C:\Windows\SysWOW64>regsvr32 "C:\Windows\PCMSRV32.DLL"
to register the COM DLL with the 32 Bit registry on a 64 Bit version of Windows when the IIS Application Pool is not in 32 Bit Mode will cause the ASP 500.100
Internal Server error
Server object error 'ASP 0177: 8007007e'
Server.CreateObject Failed
What is the IIS Application Pool Advanced Setting Enable 32-Bit Applications
set to, as it impacts on how you register the COM DLL?
Is the DLL registered using the architecture-specific version of regsvr32.exe
(if Windows version isn't 64 Bit use the default) that reflects the setting of Enable 32-Bit Applications
?
Does the Windows Registry contain a ProgId
for the DLL in the architecture-specific location of
HKEY_CLASSES_ROOT
that reflects the setting of Enable 32-Bit Applications
?
Does the InprocServer32
key contain the correct location for the DLL?
In the context of the account I'm using to access the COM DLL (ApplicationIdentity, LocalSystem, NetworkService etc), do I have permission to access both the physical DLL file and the registry entries?