OCXAfxOleRegisterTypeLibがエラー0x80040200で失敗する

OCXライブラリをVS2010 / Win7からVS2019 / Win10にアップグレードしました。プロジェクトはビルドされRegSvr32.exeますが、管理者特権のコマンドプロンプトから使用しようとすると、エラー0x0040200が表示されます。少しデバッグを行いましたが、問題のある呼び出しはへの呼び出しAfxOleRegisterTypeLibです。

はい、「dllの近くにtlbファイルがない」と述べているこのSOの記事を見ました。その他の検索状態では、管理コマンドプロンプトから実行します。

OCXコントロールの近くにTLBがありません。を使用して作成しようとするとtlbexp.exe、次のエラーが発生します。

TlbExp：エラーTX0000：ファイルまたはアセンブリ 'file：/// C：\ pathto.ocx'またはその依存関係の1つを読み込めませんでした。モジュールには、アセンブリマニフェストが含まれている必要がありました。

TlbExpコマンドライン（すべてのcmd.exeの管理者として実行を使用）：

"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\tlbexp.exe" /VERBOSE "<path to OCX file>" /out:"<path to .tlb output file>"

ダウンロードResource Tunerしたところ、マニフェストがうまく表示されています。マニフェストにはTLB情報がありません。

OCXマニフェストには、必要なTlbExp情報を取得するのに役立つ何かが必要だと思います。考えてみてください。

<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity version="1.0.0.0" name="DriveOps.ocx"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
        <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
      <!-- Windows 10 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
    </application>
  </compatibility>
  <application xmlns="urn:schemas-microsoft-com:asm.v3">
        <windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </windowsSettings>
  </application>
</assembly>

私はDepends64（別名Dependency Walker 64-bit）を使用しましたが、不足しているコンポーネントDLLはありません。RegSvr32.exeと同様に、それらすべてが適切に検出されます。

OCXファイルをC：\ Windows \ System32に配置しても役に立ちません。

DLLを見ている人なら誰でも、これらの同じDLLはWin7ボックスで正常に機能します。Windows以外のDLLに関する詳細情報は次のとおりです。

• PlxApi720_x64.dll: PLX v7.2 API (The Broadcom PLX chip is a PCIe switch (think USB/network switch, just w/PCIe lanes)
• LSIDirectAccess.dll: The LSI API is a self-contained DLL that allows the software to talk to the LSI HBA RAID adapter
• Ipp*.dll: The Ipp prefix are the DLLs used by the Intel Code Composer Studio redistribution (x64) files, here version 2011, an older one that needs to be updated to the latest and greatest, not to mention now free API. These are all in the System32 folder.

Here is the code:

// DllRegisterServer - Adds entries to the system registry
STDAPI DllRegisterServer(void)
{
    AFX_MANAGE_STATE(_afxModuleAddrThis);

    if (!AfxOleRegisterTypeLib(AfxGetInstanceHandle(), _tlid))
        return ResultFromScode(SELFREG_E_TYPELIB);           // <- failure line, through debugging

    if (!COleObjectFactoryEx::UpdateRegistryAll(TRUE))
        return ResultFromScode(SELFREG_E_CLASS);

    return NOERROR;
}

The Intel Code Composer Studio 2011 files are in the C:\Windows\System32 directory, just like on the Win7 box.

For what it is worth, TlbExp fails on the Win7 box too, just it registers, which is probably why the UI can add the control. As I recall, I once replaced the OCX on the Win7 project and VS2010 automatically created the TLB and prefixed Ax in front, but that was a couple of years ago, so my memory may not be the most accurate. Attempting to add the OCX to the UI (.Net WinForms) fails miserably and just says could not be added.

The OCX does use the latest platform tool set (Visual Studio 2019 (v142)).

A comment for developer newbies, regasm.exe is for .Net Assemblies. RegSvr32.exe is for ActiveX Controls (OCX/DLL), which is what I have. RegSvr32 is for dynamically loaded modules, hence the DllRegister entry point.

Thoughts?

Notes From Further Testing

1. (Saturday 9/21/2019) When I upgraded, I created an empty C++ DLL project and then added all the files, changing the target extension to OCX going through the old project settings and when reasonable aligning them to the new project file wanting to keep things the same. I wanted to do a test and see what happens with a brand new OCX project. I saw that there was such a thing as "MFC ActiveX Control" for a project type in VS2019. I created that and saw that I got different base files, but more importantly RegSvr32.exe works. That means that either the mistake was the initial project file, so I need to import to a clean project or import piece by piece, if that is possible, and see where things break.

2. (Saturday 9/21/2019) The new test project did not come with a manifest file and TlbExp.exe failed with the same error message like my real project. I went to add new item and saw "Package Manifest". That manifest file, though still produces the same TlbExp.exe error, looks quite different from the application manifest file from above. I created yet another new MFC ActiveX Control project and added in the manifest from above just changing names and saw that the project refused to build throwing 1) Error c1010001 Values of attribute "level" not equal in different manifest snippets. and 2) LNK1327 failure during running mt.exe. That tells me that the original Win7 project and my Win10 project files probably have some error in it, otherwise VS should have thrown these errors to me. That does not answer why even on the test project TlbExp.exe fails. Maybe some attributes in the manifest are required. I just left the defaults.

Package Manifest (It is the first time that I ever saw one of these. I always saw the app.manifest kind.)

<?xml version="1.0" encoding="utf-8"?>
<!-- TODO: Make sure to set the Package attributes -->
<Package xmlns="urn:Microsoft.WindowsPhone/PackageSchema.v8.00"
  Owner=""
  OwnerType="OEM"
  Platform=""
  Component=""
  SubComponent="Package"
  ReleaseType="Test" >

  <Components>
    <Driver InfSource="$(_RELEASEDIR)$(TARGETNAME).inf">
      <Reference Source="$(_RELEASEDIR)$(TARGETNAME)$(TARGETEXT)" />
      <Files>
        <!-- For kernel mode drivers, $(DRIVER_DEST) evaluates to "drivers" by default -->
        <!-- For user mode drivers, $(DRIVER_DEST) evaluates to "drivers\umdf" by default -->
        <File Source="$(_RELEASEDIR)$(TARGETNAME)$(TARGETEXT)" DestinationDir="$(runtime.system32)\$(DRIVER_DEST)" />
      </Files>
    </Driver>

  </Components>
</Package>

3. This article has an interesting approach, namely create a C++ DLL and then call LoadLibrary(dll) and after that GetProcAddress(module, "DllRegisterServer") to see which one fails. Well, in my case the both functions succeed. That means that the author missed one other failure branch and these two API calls are not the only thing that RegSvr32.exe does.