Server.CreateObject 报错 Can't Create ActiveX Object

2026-10-24支付小周

结论

Server.CreateObject("e24PaymentPipe.e24PaymentPipe.1") 失败，表示 IIS 无法实例化这个 COM/ActiveX 组件。错误发生在属性赋值之前，所以与 ResourcePath、金额或回调地址无关。

即使 DLL 提示“注册成功”，仍可能存在以下问题：

DLL 位数与 IIS 应用程序池位数不匹配；
注册 DLL 时使用了错误版本的 regsvr32.exe；
ProgID 不正确，或未在当前系统中注册；
DLL 依赖的运行库缺失；
IIS 应用程序池账号缺少组件运行所需的权限；
该 DLL 不是可以直接通过 regsvr32 注册的原生 COM 组件。

最常见的是前两种情况。

首先检查 32 位和 64 位是否匹配

许多早期支付网关组件只有 32 位版本。如果组件是 32 位，而 IIS 应用程序池运行在 64 位模式下，Server.CreateObject 将无法创建对象。

在 IIS 管理器中找到网站使用的应用程序池，打开“高级设置”，将：

Enable 32-Bit Applications

设置为：

True

回收应用程序池后，再测试页面。

如果组件明确是 64 位，应将该选项保持为 False，并按 64 位方式注册组件。Windows 是 64 位并不代表 DLL 也是 64 位，DLL 位数应以供应商提供的组件说明为准。

使用正确的 regsvr32 注册组件

在 64 位 Windows 中，下面两个命令的名称很容易引起误解：

C:\Windows\System32\regsvr32.exe：注册 64 位组件；
C:\Windows\SysWOW64\regsvr32.exe：注册 32 位组件。

C:\Windows\SysWOW64\regsvr32.exe "C:\Payment\e24paymentpipe.dll"

C:\Windows\System32\regsvr32.exe "C:\Payment\e24paymentpipe.dll"

需要以管理员身份运行命令提示符。注册完成后，回收对应的 IIS 应用程序池。

不要用两个版本的 regsvr32 反复注册同一个 DLL。先确认组件位数，再运行对应的命令。

确认 ProgID 是否正确

代码中使用的 ProgID 是：

e24PaymentPipe.e24PaymentPipe.1

它必须与组件实际注册的 ProgID 完全一致。可以检查以下注册表项：

HKEY_CLASSES_ROOT\e24PaymentPipe.e24PaymentPipe.1

如果找不到，说明组件没有使用这个 ProgID 正确注册，也可能是注册在了另一个位数的注册表视图中。

还要检查注册表中的 CLSID 是否存在，以及对应的 InprocServer32 是否指向实际的 DLL 文件。不要自行猜测或修改 CLSID，应优先使用支付网关供应商提供的安装程序和部署文档。

用最小页面取得完整错误信息

暂时移除其他业务逻辑，只测试对象创建：

<%
Option Explicit

Dim pipe

On Error Resume Next
Set pipe = Server.CreateObject("e24PaymentPipe.e24PaymentPipe.1")

If Err.Number <> 0 Then
    Response.Write "Err.Number: " & Err.Number & "<br>"
    Response.Write "Err.Source: " & Server.HTMLEncode(Err.Source) & "<br>"
    Response.Write "Err.Description: " & Server.HTMLEncode(Err.Description) & "<br>"
    Err.Clear
Else
    Response.Write "COM object created successfully."
    Set pipe = Nothing
End If

On Error GoTo 0
%>

记录好 Err.Number、Err.Source 和 Err.Description。常见的 800A01AD 或运行时错误 429 都表示组件无法创建，但要确定具体原因，仍需结合 IIS 位数、组件依赖和权限进行判断。

这些诊断信息只能显示在测试环境中。生产环境不应向访问者暴露服务器路径、组件信息或支付配置。

检查组件依赖项

regsvr32 成功只说明 DLL 的注册入口执行成功，并不表示运行时所需的依赖全部可用。组件可能还依赖：

Microsoft Visual C++ Runtime；
其他支付网关 DLL；
Java Runtime 或供应商自带的运行库；
配置文件、证书或许可证文件；
特定版本的系统组件。

缺少依赖项时，COM 注册信息可能依然存在，但组件实例化会失败。应使用支付网关提供的服务器部署包安装组件，不要只复制和注册单个 DLL。

如果供应商确认它是 .NET 程序集，部署方式可能涉及 RegAsm.exe、COM 可见性设置或专用安装程序，此时不应继续使用 regsvr32。具体操作取决于 DLL 的组件类型和供应商说明。

检查 IIS 应用程序池账号权限

ASP 页面通常使用应用程序池身份运行，并不是以执行注册操作的管理员身份运行。该身份至少需要：

读取和执行组件 DLL；
读取组件依赖的其他 DLL；
读取 ResourcePath 指向的目录和配置文件；
如果组件需要写入日志或临时文件，具备对应目录的写入权限；
如果组件需要使用证书私钥或许可证文件，具备相应的访问权限。

不要直接给目录授予 Everyone: Full Control。先确认应用程序池名称，例如：

IIS AppPool\YourAppPoolName

然后只授予组件运行所需的最小权限。

ResourcePath 要在对象创建成功后才会设置。如果错误发生在 Server.CreateObject，它通常不是本次失败的直接原因。不过，对象创建成功后，如果组件会立即读取默认配置，ResourcePath 仍可能引发后续问题。