错误 ASP 0177:8007007e CreateObject 对于 COM DLL 失败 [英] Error ASP 0177: 8007007e CreateObject fails for COM DLL
问题描述
我们一直在尝试在新服务器上安装 COM DLL.界面是经典的ASP.Map Connector DLL 似乎是问题所在,但这是我所能得到的.
我们无法让 IIS 提供的页面出现 500 错误以外的任何错误.
在跟踪 ASP 时:
<前>127. -ASP_SCRIPT_TRACE_COM_CALL_END文件路径C:INETPUBWWWROOTMILERGLOBAL.ASA电话号码6当前声明set g_pcmsrv=Server.CreateObject("PCMServer.PCMServer")语句大小550 毫秒128. -ASP_LOG_ERROR电话号码6错误代码ASP 0177 : 8007007e描述Server.CreateObject 失败DLL 是 PCMSRV32.DLL
在 c:windows
GLOBAL.ASA:
Sub Application_OnStartset g_pcmsrv=Server.CreateObject("PCMServer.PCMServer")设置应用程序(g_pcmsrv")= g_pcmsrvset g_pcmmapmgr=Server.CreateObject("Pcmgole.PCMMapMgr")设置应用程序(g_pcmmapmgr")= g_pcmmapmgr结束子子会话_OnStartset Session("currentTrip") = application("g_pcmsrv").NewTrip("NA")set Session("map") = application("g_pcmmapmgr").createMap()结束子子会话_OnEnd设置会话(currentTrip")=没有设置会话(地图")= 没有结束子子应用_Onend设置应用程序(g_pcmsrv")=无设置应用程序(g_pcmmapmgr")=无结束子
下面的建议与 Server.CreateObject
和 CreateObject
在
Web 服务器部分特定于 asp-经典,但仍然值得一读.
<小时>是什么导致了这个错误?
<块引用>Server.CreateObject 失败
最常见的原因是当 Web 应用程序从一个 Web 服务器移动到另一个 Web 服务器时,而不了解正在使用和注册到 Web 服务器的外部 COM 组件.
<块引用>来自 PRB:Server.CreateObject 返回 HTTP 500.100 或 ASP 0177 错误 (0x8007007E)
当您尝试使用 Server.CreateObject 方法来实例化未在本地系统上注册的对象时,会发生此错误.
确定错误来源
如果您在 ASP Web 应用程序中使用 COM 组件,您将看到这样的一行
set g_pcmsrv=Server.CreateObject("PCMServer.PCMServer")
通常错误会指向 Set
行,这使得确定原因更容易(幸运的是你有一些很好的跟踪代码,所以它更好).>
如果您不知道 DLL 的位置怎么办?
<块引用>注意: 访问 Windows 注册表时请务必小心,因为无意中进行更改会对操作系统造成严重后果非常容易,在极端情况下需要还原或重新安装系统/修复.
CreateObject
方法中的字符串称为 ProgId
,用作 Windows 注册表中键的标识符,可在
注意:可以在大多数版本的 Windows 中使用 regedit.exe
(也称为注册表编辑器)浏览 Windows 注册表.使用此工具浏览 Windows 注册表时要非常小心.
HKEY_CLASSES_ROOT
并通过扩展
HKEY_LOCAL_MACHINEClasses
每当 ASP 处理器遇到 ProgId
时,它都会尝试与 Windows 注册表对话并找到一个对应的键,该键表示已注册的 COM 可访问 DLL 的位置.
HKEY_CLASSES_ROOTPCMServer.PCMServer
对此的一种常见方法是该键包含一个名为 CLSID
的子键,该子键指向关联的已注册 DLL 的类 GUID.一旦 GUID 键位于
HKEY_CLASSES_ROOTCLSID
hive 可用于通过查找子项来查找位置
HKEY_CLASSES_ROOTCLSID{来自 CLSID 的 GUID}InprocServer32
位置将存储在 (默认)
值中的位置.
使用 ProgId
的示例 - Scripting.FileSystemObject
在
中找到HKEY_CLASSES_ROOT
Scripting.FileSystemObject
子键HKEY_CLASSES_ROOTScripting.FilesystemObject
从子键
中识别GUIDCLSID
HKEY_CLASSES_ROOTScripting.FilesystemObjectCLSID(默认)-{0D43FE01-F093-11CF-8940-00A0C9054228}"
使用 GUID 在
中查找已注册的 DLL 子项HKEY_CLASSES_ROOTCLSID
HKEY_CLASSES_ROOTCLSID{0D43FE01-F093-11CF-8940-00A0C9054228}
检查子键
InprocServer32
(默认)
DLL 位置的值HKEY_CLASSES_ROOTCLSID{0D43FE01-F093-11CF-8940-00A0C9054228}InprocServer32(默认)-C:WindowsSystem32scrrun.dll"
注册表中没有 PCMServer.PCMServer
的 ProgId
?
如果您在注册表中找不到相应的 ProgId
,可能是由于我们将在此处详细说明的两个原因之一.
- DLL 未注册.
- DLL 在错误的区域注册.
如何在 Windows 中注册 COM DLL
COM DLL 可以注册并创建相应的注册表项,方法是使用提升的权限从 Windows 命令提示符运行 regsvr32.exe
工具(这因 Windows 版本而异).
在我们继续之前,操作系统的架构和 ASP Web 应用程序使用的模式非常重要.
大多数较新的硬件是 64 位,这在 Windows 中造成了一个难题,因为它现在必须支持较新的 64 位架构,并且仍然保持对 32 位架构的支持.微软提出的解决方案是将操作系统一分为二,所以我们有 64 位元素和 32 位元素.主要的操作系统程序分为两个文件夹(仅在 64 位操作系统上,因为 32 位操作系统不必与 64 位竞争,即使硬件有能力).><块引用>
注意:在仅限 32 位的系统上,只需将 64 位位置用于系统文件和 Windows 注册表.
在 64 位操作系统上,系统程序位于
对于 64 位程序
%SystemRoot%System32
对于 32 位程序
%SystemRoot%SysWOW64
这也适用于 Windows 注册表
64 位
HKEY_CLASSES_ROOT
32 位
HKEY_CLASSES_ROOTWow6432Node
例如,在 64 位版本的 Windows 上,以下命令将在 32 位注册表中注册 PCMSRV32.DLL
并创建关联的 COM DLL 注册表项.
C:WindowsSysWOW64>regsvr32 "C:WindowsPCMSRV32.DLL"
IIS 应用程序池
随着一切开始支持 64 位,包括 IIS,您仍然需要能够支持仅支持 32 位 COM 的旧应用程序,因此 IIS 引入 IIS 6.0 (从 Windows Server 2003,Service Pack 1 开始) 在应用程序池设置下,可配置属性 Enabled32BitAppOnWin64
允许应用程序池在 64 位版本的 Windows 上以 32 位模式运行.
考虑到这一点,在您注册 COM DLL 以了解您应该在哪里注册它之前,您需要知道应用程序池是否在 32 位模式下运行.在 IIS 7.0 及更高版本中,您可以从 IIS 管理器应用程序内的应用程序池属性中检查这一点.该设置位于 General
部分下的 Advanced Settings
中,称为 Enable 32-Bit Applications
(也可以在applicationHost.config
使用
部分下的 enable32BitAppOnWin64
).
如果
Enable 32-Bit Applications
设置为False
IIS 应用程序池在本机 64 位模式下运行,任何需要由 ASP Web 应用程序使用的 COM DLL 都需要支持 64 位并使用
regsvr32.exe 的 64 位版本注册
将被添加到 64 位注册表中.C:WindowsSystem32>regsvr32 "C:WindowsPCMSRV32.DLL"
如果
Enable 32-Bit Applications
设置为True
IIS 应用程序池在 32 位模式下运行,ASP Web 应用程序需要使用的任何 COM DLL 都需要是 32 位 COM DLL 并使用 32 位版本的
regsvr32.exe 进行注册
要添加到 32 位注册表中.C:WindowsSysWOW64>regsvr32 "C:WindowsPCMSRV32.DLL"
使用错误版本的regsvr32.exe
例如,使用
C:WindowsSysWOW64>regsvr32 "C:WindowsPCMSRV32.DLL"
当 IIS 应用程序池不在 32 位模式下时,在 64 位版本的 Windows 上使用 32 位注册表注册 COM DLL 将导致 ASP 500.100
内部服务器错误
服务器对象错误ASP 0177: 8007007e"
Server.CreateObject 失败
<小时>
COM DLL 清单
IIS 应用程序池高级设置
Enable 32-Bit Applications
设置为什么,因为它会影响您注册 COM DLL 的方式?DLL 是否使用架构特定版本的
regsvr32.exe
注册(如果 Windows 版本不是 64 位,则使用默认版本),这反映了Enable 32-Bit Applications
? 的设置Windows 注册表是否包含
的体系结构特定位置中 DLL 的ProgId
HKEY_CLASSES_ROOT
反映
Enable 32-Bit Applications
的设置?InprocServer32
键是否包含 DLL 的正确位置?在我用来访问 COM DLL 的帐户上下文中(ApplicationIdentity、LocalSystem、NetworkService 等),我是否有权访问物理 DLL 文件和注册表项?
<小时>
有用的链接
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.
We are unable to get the pages served by IIS to give anything other than a 500 error.
When tracing the ASP:
127. -ASP_SCRIPT_TRACE_COM_CALL_END FilePath C:INETPUBWWWROOTMILERGLOBAL.ASA LineNumber 6 CurrentStatement set g_pcmsrv=Server.CreateObject("PCMServer.PCMServer") SizeOfStatement 55 0 ms 128. -ASP_LOG_ERROR LineNumber 6 ErrorCode ASP 0177 : 8007007e Description Server.CreateObject Failed
The DLL is PCMSRV32.DLL
in c:windows
GLOBAL.ASA:
Sub Application_OnStart
set g_pcmsrv=Server.CreateObject("PCMServer.PCMServer")
set application("g_pcmsrv") = g_pcmsrv
set g_pcmmapmgr=Server.CreateObject("Pcmgole.PCMMapMgr")
set application("g_pcmmapmgr") = g_pcmmapmgr
End Sub
Sub Session_OnStart
set Session("currentTrip") = application("g_pcmsrv").NewTrip("NA")
set Session("map") = application("g_pcmmapmgr").createMap()
End Sub
Sub Session_OnEnd
set Session("currentTrip") = Nothing
set Session("map") = Nothing
End Sub
Sub Application_Onend
Set application("g_pcmsrv")=Nothing
Set application("g_pcmmapmgr")=Nothing
End Sub
The advice below relates to both Server.CreateObject
and CreateObject
use in
The Web Server sections are specific to asp-classic but still worth reading.
What Causes This error?
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.
Identifying the Source of the Error
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).
What If You Don't Know Where the DLL Is Located?
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_MACHINEClasses
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_ROOTPCMServer.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_ROOTCLSID
hive it can be used to find the location by looking in the subkey
HKEY_CLASSES_ROOTCLSID{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_ROOTScripting.FilesystemObject
Identify GUID from subkey
CLSID
HKEY_CLASSES_ROOTScripting.FilesystemObjectCLSID (default) - "{0D43FE01-F093-11CF-8940-00A0C9054228}"
Use GUID to find registered DLL subkey in
HKEY_CLASSES_ROOTCLSID
HKEY_CLASSES_ROOTCLSID{0D43FE01-F093-11CF-8940-00A0C9054228}
Check subkey
InprocServer32
(default)
value for the DLL locationHKEY_CLASSES_ROOTCLSID{0D43FE01-F093-11CF-8940-00A0C9054228}InprocServer32 (default) - "C:WindowsSystem32scrrun.dll"
No 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.
- The DLL is not registered.
- The DLL is registered in the wrong area.
How to register COM DLL with Windows
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_ROOTWow6432Node
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:WindowsSysWOW64>regsvr32 "C:WindowsPCMSRV32.DLL"
IIS Application Pool
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 toFalse
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:WindowsSystem32>regsvr32 "C:WindowsPCMSRV32.DLL"
If
Enable 32-Bit Applications
is set toTrue
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:WindowsSysWOW64>regsvr32 "C:WindowsPCMSRV32.DLL"
Registering the COM DLL Using the Wrong Version of regsvr32.exe
For example, using
C:WindowsSysWOW64>regsvr32 "C:WindowsPCMSRV32.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
COM DLL Checklist
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 ofEnable 32-Bit Applications
?Does the Windows Registry contain a
ProgId
for the DLL in the architecture-specific location ofHKEY_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?
Useful Links
这篇关于错误 ASP 0177:8007007e CreateObject 对于 COM DLL 失败的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!