错误 ASP 0177:8007007e CreateObject 对于 COM DLL 失败 [英] Error ASP 0177: 8007007e CreateObject fails for COM DLL

查看:16
本文介绍了错误 ASP 0177:8007007e CreateObject 对于 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.DLLc: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.CreateObjectCreateObject

中的使用有关

Web 服务器部分特定于 ,但仍然值得一读.

<小时>

是什么导致了这个错误?

<块引用>

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

  1. HKEY_CLASSES_ROOT

    中找到Scripting.FileSystemObject子键

    HKEY_CLASSES_ROOTScripting.FilesystemObject

  2. 从子键CLSID

    中识别GUID

    HKEY_CLASSES_ROOTScripting.FilesystemObjectCLSID(默认)-{0D43FE01-F093-11CF-8940-00A0C9054228}"

  3. 使用 GUID 在 HKEY_CLASSES_ROOTCLSID

    中查找已注册的 DLL 子项

    HKEY_CLASSES_ROOTCLSID{0D43FE01-F093-11CF-8940-00A0C9054228}

  4. 检查子键 InprocServer32 (默认) DLL 位置的值

    HKEY_CLASSES_ROOTCLSID{0D43FE01-F093-11CF-8940-00A0C9054228}InprocServer32(默认)-C:WindowsSystem32scrrun.dll"

注册表中没有 PCMServer.PCMServerProgId?

如果您在注册表中找不到相应的 ProgId,可能是由于我们将在此处详细说明的两个原因之一.

  1. DLL 未注册.
  2. 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 位操作系统上,系统程序位于

  1. 对于 64 位程序

    %SystemRoot%System32

  2. 对于 32 位程序

    %SystemRoot%SysWOW64

这也适用于 Windows 注册表

  1. 64 位

    HKEY_CLASSES_ROOT

  2. 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

注册COM DLL

例如,使用

C:WindowsSysWOW64>regsvr32 "C:WindowsPCMSRV32.DLL"

当 IIS 应用程序池不在 32 位模式下时,在 64 位版本的 Windows 上使用 32 位注册表注册 COM DLL 将导致 ASP 500.100 内部服务器错误

<块引用>

服务器对象错误ASP 0177: 8007007e"

Server.CreateObject 失败

<小时>

COM DLL 清单

  1. IIS 应用程序池高级设置 Enable 32-Bit Applications 设置为什么,因为它会影响您注册 COM DLL 的方式?

  2. DLL 是否使用架构特定版本的 regsvr32.exe 注册(如果 Windows 版本不是 64 位,则使用默认版本),这反映了Enable 32-Bit Applications?

  3. 的设置
  4. Windows 注册表是否包含

    的体系结构特定位置中 DLL 的 ProgId

    HKEY_CLASSES_ROOT

    反映Enable 32-Bit Applications的设置?

  5. InprocServer32 键是否包含 DLL 的正确位置?

  6. 在我用来访问 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 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

  1. Locate Scripting.FileSystemObject subkey in HKEY_CLASSES_ROOT

    HKEY_CLASSES_ROOTScripting.FilesystemObject
    

  2. Identify GUID from subkey CLSID

    HKEY_CLASSES_ROOTScripting.FilesystemObjectCLSID
    
    (default) - "{0D43FE01-F093-11CF-8940-00A0C9054228}"  
    

  3. Use GUID to find registered DLL subkey in HKEY_CLASSES_ROOTCLSID

    HKEY_CLASSES_ROOTCLSID{0D43FE01-F093-11CF-8940-00A0C9054228}
    

  4. Check subkey InprocServer32 (default) value for the DLL location

    HKEY_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.

  1. The DLL is not registered.
  2. 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

  1. For 64 Bit programs

    %SystemRoot%System32
    

  2. For 32 Bit programs

    %SystemRoot%SysWOW64
    

This is also applies to the Windows Registry

  1. 64 Bit

    HKEY_CLASSES_ROOT
    

  2. 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 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:WindowsSystem32>regsvr32 "C:WindowsPCMSRV32.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: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

  1. What is the IIS Application Pool Advanced Setting Enable 32-Bit Applications set to, as it impacts on how you register the COM DLL?

  2. 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?

  3. 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?

  4. Does the InprocServer32 key contain the correct location for the DLL?

  5. 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屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆