管理者で実行しているのに「モジュール xxxxx.ocx は読み込まれましたが、DllRegisterServer への呼び出しはエラーコード 0x800040200 により失敗しました。」が発生する

Question

■ドライバ作成環境
OS: Windows 10 Pro (64bit) (ver.1803)
Tools: Visual Studio Professional 2017 (ver.15.7.4)+WDK10

ドライバ作成環境にてビルドした 32bit用ドライバ(2 projects: xxxxx.ocxとxxxxx.dll)を、
同じソリューション内で作成したインストーラを使用し、
Windows 10 (64bit)(ver.1803)(他PC)にインストールを行いました。
インストールは問題なく動作し、32bit用ドライバは %windir%\syswow64 フォルダ内に格納されています。

その後、手動でドライバのレジストリ登録を行うべく、
%windir%\syswow64\cmd を「管理者として実行」で起動し、
regsvr32 xxxxx.dll
を実行。問題なく完了します。
しかし、次に
regsvr32 xxxxx.ocx
を実行すると
「モジュール xxxxx.ocx は読み込まれましたが、DllRegisterServer への呼び出しは
エラーコード 0x800040200 により失敗しました。
この問題の詳細については、エラーコードを検索語として入力してオンラインで検索してください。」
とエラーが発生してしまいます。

このエラーコードでNET検索を行っても、解決策は「管理者として実行する」というものばかりで
本件の解決方法が見つかりません。

本現象の解決策をご存知の方がいらっしゃいましたら、ご教授をお願い致します。

また、インストール時に直接レジストリ登録する方法もあるのであれば、ご教授いただきたいです。

宜しくお願い致します。

Answer 1

自分だったらこう調べるという方針を記載します。

DllRegisterServerの実装を行っている(もしくはATLなどで自動で生成されてた)ソースが
あるはずなのでそれを見つける。

HRSEULT WINAPI DllRegisterServer(){
    ::DebugBreak();
    //後続の処理
}

こんな感じでDebugBreakをしかける。

Windbgを管理者権限で起動する。
メニューの[Open Executable]からregsvr32を問題のocxを引数に指定して起動する。
仕掛けておいたDebugBreakで停止するのであとはステップ実行して調べる。

Windbgの使い方が分からない場合はC++でDllRegisterServerを実行するEXEを作成してVisual Studioなどでデバッグする。

---

確認するポイントの追記

タイプライブラリは.idlから生成されます。
生成された.tlbファイルは.rcファイル内で
1 TYPELIB "MFCActiveXControl1.tlb"
のような命令でリソースIDが1として埋め込まれます。

まずは.idlファイルがなければプロジェクトに追加します。
これはもともとのvc6.0のプロジェクト内にあったはずです。
プロパティでファイルの種類がidlになっていることを確認します。

次にプロジェクトのプロパティでMIDLの設定を見ます。
タイプライブラリが生成する設定になっていることを確認します。

リソースファイルのプロパティでファイルの種類を確認します。

もともとrcファイルに TYPELIBを埋め込む命令が書いてあって
.tlbファイルがない場合リソースコンパイラでエラーになるはずです。
ですので、.rcファイルも怪しい気がします。
.rcファイルをコードの表示で直接開きます。(もしくはメモ帳などで直接開く)

//最初のほうに以下のようなブロックがあります。
//これは[リソースファイルのインクルード]の[コンパイル時に追加するファイル]
//の内容が登録されます。
3 TEXTINCLUDE 
BEGIN
    "1 TYPELIB ""MFCActiveXControl1.tlb""\r\n"
    "\0"
END

//終わりのほうに以下のようなインクルードの内容が展開された内容があります。
//こちらが実際にリソースコンパイラによって処理される命令です。
//これはリソースファイルをGUIから変更すると3 TEXTINCLUDE
//の内容をもとに自動生成されます。
//これが存在しないような気がします。

#ifndef APSTUDIO_INVOKED
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 3 resource.
//
1 TYPELIB "MFCActiveXControl1a.tlb"

/////////////////////////////////////////////////////////////////////////////
#endif    // not APSTUDIO_INVOKED

一度ActiveXを作成するプロジェクトを作成して
自動で生成されるファイルや設定を見比べてみるといいと思います。

Comments

[cpp_beginner]

hmmm 様
ご回答有難う御座います。

Windbg 機能というものの存在は知りませんでした。
Netで検索しながら、ご教授いただいた方法を実践してみました。
ntdll!LdrLoadDll+0xa7　mov　eax, dword ptr [ecx+18h] ds:002b:02bc730={対象.ocxファイル (6a5f0000)}
にて、
*** WARNING: Unable to verify checksum for C:\Windows\SysWOW64\対象.ocx
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\SysWOW64\対象.ocx -
となっておりました。

上記のエラー内容から、.ocx ビルド時の設定でなにかしら足りていないように思えますが、
今のところ特定には至っておりません。

解決方法をご存知でしたら、さらなるご教授を宜しくお願い致します。

[hmmm]

checksum は気にしなくていいです。Symbol file could not be foundはpdbファイルが見つからないエラーです。両方ともデバッガのエラーメッセージなのでDllRegisterServerのエラーとは関係ないです。
Windbgの使い方はhttps://docs.microsoft.com/ja-jp/windows-hardware/drivers/debugger/getting-started-with-windbg
あたりを読んでください。
目的はDllRegisterServer関数をデバッグすることなので、WindbgではなくVisual StudioでもOKです。
具体的にデバッグを進めてどの部分の処理が0x800040200 のエラーコードを引き起こすかを調べてください。
現状で提示されている情報から私がアドバイスできるのはここまです。

[cpp_beginner]

hmmm 様
ご丁寧にご教授いただき、誠に有難う御座います。

ご教授通り、windbgにてステップ実行をしてみました。

まず、実際の DllRegisterServer () 関数のコードは以下の通りとなっております。

STDAPI DllRegisterServer(void)
{
AFX_MANAGE_STATE(_afxModuleAddrThis);

if (!AfxOleRegisterTypeLib(AfxGetInstanceHandle(), _tlid))
return ResultFromScode(SELFREG_E_TYPELIB);

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

return NOERROR;
}

windbgでステップ実行していった結果、 AfxOleRegisterTypeLib () 関数が、戻り値 10h で終了しておりました。
※ステップ実行時のログは以下の通りです。

mfc140!AfxOleRegisterTypeLib:
6ae8f270 6a2c push 2Ch
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x2:
6ae8f272 b8e2c5f46a mov eax,offset mfc140!___guard_check_icall_thunk+0x10da2 (6af4c5e2)
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x7:
6ae8f277 e874c10a00 call mfc140!_EH_prolog3_GS (6af3b3f0)
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0xc:
6ae8f27c 8b450c mov eax,dword ptr [ebp+0Ch] ss:002b:000ee6c8=6b7b08d8
0:000:x86> p
mfc140!ATL::CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t> > >::{ctor} [inlined in mfc140!AfxOleRegisterTypeLib+0xf]:
6ae8f27f 8d4ddc lea ecx,[ebp-24h]
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x12:
6ae8f282 8b7508 mov esi,dword ptr [ebp+8] ss:002b:000ee6c4={co_lineprint (6b7a0000)}
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x15:
6ae8f285 33db xor ebx,ebx
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x17:
6ae8f287 8b7d10 mov edi,dword ptr [ebp+10h] ss:002b:000ee6cc=00000000
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x1a:
6ae8f28a 8945cc mov dword ptr [ebp-34h],eax ss:002b:000ee688={USER32!MessageBoxA (76377e90)}
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x1d:
6ae8f28d 8b4514 mov eax,dword ptr [ebp+14h] ss:002b:000ee6d0=00000000
0:000:x86> p
mfc140!ATL::CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t> > >::{ctor}+0x11 [inlined in mfc140!AfxOleRegisterTypeLib+0x20]:
6ae8f290 68dcebf76a push offset mfc140!afxStringManager (6af7ebdc)
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x25:
6ae8f295 8945c8 mov dword ptr [ebp-38h],eax ss:002b:000ee684=025ad6c8
0:000:x86> p
mfc140!ATL::CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t> > >::{ctor}+0x19 [inlined in mfc140!AfxOleRegisterTypeLib+0x28]:
6ae8f298 e8639ae5ff call mfc140!ATL::CSimpleStringT<char,1>::CSimpleStringT<char,1> (6ace8d00)
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x2d:
6ae8f29d 215dfc and dword ptr [ebp-4],ebx ss:002b:000ee6b8=ffffffff
0:000:x86> p
mfc140!ATL::CSimpleStringT<wchar_t,1>::GetBuffer [inlined in mfc140!AfxOleRegisterTypeLib+0x30]:
6ae8f2a0 8d4ddc lea ecx,[ebp-24h]
0:000:x86> p
mfc140!ATL::CSimpleStringT<wchar_t,1>::GetBuffer+0x3 [inlined in mfc140!AfxOleRegisterTypeLib+0x33]:
6ae8f2a3 6804010000 push 104h
0:000:x86> p
mfc140!ATL::CSimpleStringT<wchar_t,1>::GetBuffer+0x8 [inlined in mfc140!AfxOleRegisterTypeLib+0x38]:
6ae8f2a8 e8a3f5e5ff call mfc140!ATL::CSimpleStringT<wchar_t,1>::PrepareWrite (6acee850)
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x3d:
6ae8f2ad 6804010000 push 104h
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x42:
6ae8f2b2 50 push eax
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x43:
6ae8f2b3 56 push esi
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x44:
6ae8f2b4 ff1508e3f86a call dword ptr [mfc140!_imp__GetModuleFileNameW (6af8e308)] ds:002b:6af8e308={KERNEL32!GetModuleFileNameWStub (75d24dc0)}
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x4a:
6ae8f2ba 6aff push 0FFFFFFFFh
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x4c:
6ae8f2bc 8d4ddc lea ecx,[ebp-24h]
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x4f:
6ae8f2bf e8cc01f1ff call mfc140!ATL::CSimpleStringT<wchar_t,1>::ReleaseBuffer (6ad9f490)
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x54:
6ae8f2c4 215dd8 and dword ptr [ebp-28h],ebx ss:002b:000ee694=025ad6c8
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x57:
6ae8f2c7 85ff test edi,edi
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x59:
6ae8f2c9 744d je mfc140!AfxOleRegisterTypeLib+0xa8 (6ae8f318) [br=1]
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0xa8:
6ae8f318 8d45d8 lea eax,[ebp-28h]
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0xab:
6ae8f31b 50 push eax
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0xac:
6ae8f31c ff75dc push dword ptr [ebp-24h] ss:002b:000ee698=0262f178
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0xaf:
6ae8f31f ff15a0e5f86a call dword ptr [mfc140!_imp__LoadTypeLib (6af8e5a0)] ds:002b:6af8e5a0={OLEAUT32!LoadTypeLib (76d741c0)}
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0xb5:
6ae8f325 85c0 test eax,eax
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0xb7:
6ae8f327 0f88cd000000 js mfc140!AfxOleRegisterTypeLib+0x18a (6ae8f3fa) [br=1]
0:000:x86> p
mfc140!ATL::CSimpleStringT<wchar_t,1>::GetData [inlined in mfc140!AfxOleRegisterTypeLib+0x18a]:
6ae8f3fa 8b4ddc mov ecx,dword ptr [ebp-24h] ss:002b:000ee698=0262f178
0:000:x86> p
mfc140!ATL::CSimpleStringT<wchar_t,1>::GetData+0x3 [inlined in mfc140!AfxOleRegisterTypeLib+0x18d]:
6ae8f3fd 8d49f0 lea ecx,[ecx-10h]
0:000:x86> p
mfc140!ATL::CSimpleStringT<wchar_t,1>::{dtor}+0x6 [inlined in mfc140!AfxOleRegisterTypeLib+0x190]:
6ae8f400 e8fd9de5ff call mfc140!ATL::CStringData::Release (6ace9202)
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x195:
6ae8f405 8bc3 mov eax,ebx
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x197:
6ae8f407 e88ebf0a00 call mfc140!_EH_epilog3_GS (6af3b39a)
0:000:x86> t
mfc140!_EH_epilog3_GS:
6af3b39a 8b4df0 mov ecx,dword ptr [ebp-10h] ss:002b:000ee6ac=c856d9b4
0:000:x86> p
mfc140!_EH_epilog3_GS+0x3:
6af3b39d 33cd xor ecx,ebp
0:000:x86> p
mfc140!_EH_epilog3_GS+0x5:
6af3b39f f2e86be1ffff bnd call mfc140!__security_check_cookie (6af39510)
0:000:x86> p
mfc140!_EH_epilog3_GS+0xb:
6af3b3a5 f2e9daffffff bnd jmp mfc140!_EH_epilog3 (6af3b385)
0:000:x86> p
mfc140!_EH_epilog3:
6af3b385 8b4df4 mov ecx,dword ptr [ebp-0Ch] ss:002b:000ee6b0=000ef784
0:000:x86> p
mfc140!_EH_epilog3+0x3:
6af3b388 64890d00000000 mov dword ptr fs:[0],ecx fs:0053:00000000=022dc000
0:000:x86> p
mfc140!_EH_epilog3+0xa:
6af3b38f 59 pop ecx
0:000:x86> p
mfc140!_EH_epilog3+0xb:
6af3b390 5f pop edi
0:000:x86> p
mfc140!_EH_epilog3+0xc:
6af3b391 5f pop edi
0:000:x86> p
mfc140!_EH_epilog3+0xd:
6af3b392 5e pop esi
0:000:x86> p
mfc140!_EH_epilog3+0xe:
6af3b393 5b pop ebx
0:000:x86> p
mfc140!_EH_epilog3+0xf:
6af3b394 8be5 mov esp,ebp
0:000:x86> p
mfc140!_EH_epilog3+0x11:
6af3b396 5d pop ebp
0:000:x86> p
mfc140!_EH_epilog3+0x12:
6af3b397 51 push ecx
0:000:x86> p
mfc140!_EH_epilog3+0x13:
6af3b398 f2c3 bnd ret
0:000:x86> p
mfc140!AfxOleRegisterTypeLib+0x19c:
6ae8f40c c21000 ret 10h

その後、上記 DllRegisterServer () 関数の終了時に eaxレジスタに 80040200h を設定していました。

何度もお手を煩わせて申し訳ありませんが、お気づきの点がございましたら、
さらなるご教授を宜しくお願い致します。

[hmmm]

AfxOleRegisterTypeLibのソースコードは以下
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\atlmfc\src\mfc\ctlreg.cpp
ステップ実行の結果と見比べるとLoadTypeLibで失敗しているのが分かるので
mfc140!AfxOleRegisterTypeLib+0xb5:
6ae8f325 85c0 test eax,eax
ここのeaxの値を調べて
https://docs.microsoft.com/ja-jp/previous-versions/windows/desktop/api/oleauto/nf-oleauto-loadtypelib
LoadTypeLibの戻り値が何なのかを調べてください。

[cpp_beginner]

hmmm 様
度重なるご丁寧なご教授、誠に有難う御座います。

ご教授いただいた箇所の eax レジスタの値を調べましたところ、
eax=0x80029c4a (TYPE_E_CANTLOADLIBRARY) でした。

本エラーコードにてNET検索を行い、解決方法を探しましたが見つけることができませんでした。

Type Library ID の値がVC++6.0のときとは変わっているのかと思い、そちらのほうからも検索をしてみましたが
なにも手掛かりらしきものは見つけられませんでした。

現状、AfxOleRegisterTypeLib () 関数call時に渡している TypeLibID は以下の通りです。
const GUID CDECL BASED_CODE _tlid =
{ 0x3876c4e3, 0xd1f8, 0x11d5, { 0xa9, 0xa0, 0, 0x80, 0xad, 0x82, 0x41, 0x1f } };

また、今回の問題に関係するかわかりませんが、問題が発生している .ocx が依存している .dll の中で、
VC++6.0のときは mfc42.dll であったのが、現在は mfc140.dll に変わってしまっています。
（ソリューションをVS2017に移植したことで変わってしまったようです）

大変恐れ入りますが、さらなるご教授をいただけますようお願い申し上げます。
なにとぞ宜しくお願い致します。

[hmmm]

単純にタイプライブラリがocxに埋め込まれてないんじゃないでしょうか？
手元で試したところTYPE_E_CANTLOADLIBRARYになりました。

リソースファイル(.rc)をダブルクリックしてリソースビューに切り替えて
rcファイルを右クリックして[リソースファイルのインクルード]
[コンパイル時に追加するファイル]に
1 TYPELIB "MFCActiveXControl1.tlb"
みたいな命令が書かれていますか？
また、rcファイルをエディタで直接開いて上記のような命令が展開されているでしょうか？

[cpp_beginner]

hmmm 様
重ね重ねご丁寧にご教授くださいまして誠に有難う御座います。

ご教授いただいた通り、リソースファイル(.rc) よりリソースビューを開き、リソースファイルを
右クリック→[リソースファイルのインクルード]→[コンパイル時に追加するファイル]を
調べましたところ、ご教授通りの命令文は書かれていましたが、該当する.tlbファイルがどこにも見当たりませんでした。
（VC++6.0で開発していたときのフォルダ内で同ファイルを探したところ、\Releaseフォルダ内に存在していました。）

試しに、VC++6.0時代の.tlbファイルを、現在のVS2017開発環境での.ocx作成プロジェクトフォルダ
配下の\Releaseフォルダ内にコピーをし、.ocxをビルドし直して、インストールを試みましたが、
結果は変わりませんでした。
また、.ocx作成プロジェクトの「Resource Files」右クリック→「追加」→「既存の項目」で
同.tlbファイルを追加し、.ocxをビルドし直して、インストールを試みましたが、
やはり結果は変わりませんでした。

VS2017の.ocx作成プロジェクトで.tlbファイルを作成し、.ocxに組み込むことは可能なのでしょうか？
プロジェクトのプロパティの項目をみましたが、それらしき設定項目は見つけることができませんでした。

隅から隅までご教授いただきっぱなしで大変恐縮ではございますが、最後(?)に
VS2017上のプロジェクトでの .tlbファイルの作成方法と、.ocxファイルへの組み込み方法を
ご教授いただけますよう宜しくお願い申し上げます。

[hmmm]

確認するポイントを回答に追記しました。

[cpp_beginner]

hmmm 様
詳細な対応方法をご提示くださり誠に有難う御座います。

ご指摘いただいた通り、.rc ファイルの最後の方の 1 TYPELIB "xxxxxx.tlb" 行が
コメントアウトされていました。
（.ocx 作成プロジェクトの移植時、この行で Error RC2135 が発生し、後々対応しようと
　コメントアウトしておいたのを忘れて放置したままとなっておりました。
　私のケアレスミスです。申し訳ございません。）

また、.ocx のプロジェクトを見直したところ、 source files フォルダに .odl ファイルが
すでに設定されていました。
.odl ファイルのプロパティで、IDLファイルであることも確認できました。

そこで、上記のコメントアウトを外し、ビルドし直しました（エラーは出ませんでした）。
その後、インストールし、レジストリ登録を行ったところ、発生していたエラーは解消され
問題なく登録できました。

この度は、最後までご丁寧にご教授くださりまして誠に有難う御座いました。
おかげ様で問題が無事解決できました。
また、windowsについていろいろと勉強させていただきました。あわせて感謝致しております。
また機会がありましたら、宜しくお願い致します。

[hmmm]

解決できて何よりです。
今回の話はCOMの話です。
古すぎて絶版ですが、Essential COM(https://www.amazon.co.jp/dp/4756130666)がCOMの目的や実装方法が記載された本です。IDLについても触れられているので読んでみるといいかもしれません。
アパートメントについてもっと知りたい（いまいち理解できない）場合は
https://www.kekyo.net/2011/06/05/14
がお勧めです。

[cpp_beginner]

hmmm 様
ご返事が遅くなり、大変申し訳ありません。
参考にすべき資料本とURLのご提示、誠に有難う御座います。
ぜひ読んでみたいと思います。

Answer 2

そのOCXですが、32bit OSでは正しく登録できるのでしょうか？

また、自作のOCXではなく、Microsoftなどから配布されているOCXでやってみたらどうでしょうか？
（その場合も、SysWOW64で登録する必要があります。）

Comments

[cpp_beginner]

PineMatsu 様
ご回答有難う御座います。

ご指摘いただいた .ocx ですが、Visual C++ 6.0 のプロジェクトを VS2017 に移植してビルドし直したもので、ビルドし直し後の動作実績はないものです。
.ocx のビルド自体に問題がある可能性も高いのではないかと疑っています。

一旦、Windows(32bit) で動作実績のある .ocx と.dll をインストールするインストーラプロジェクトを作成して試してみようと思います。

ほかに気になる点などがありましたら、ご教授お願い致します。

[cpp_beginner]

PineMatsu 様

Windows(32bit) で動作実績のある(VC++でビルドした) .ocx と .dll をインストールするインストーラプロジェクトを作成し、
試してみたところ、こちらの .ocx と .dll は問題なくレジストリ登録ができました。

レジストリ登録OK/NGの両 .ocx と .dll の依存関係を比べてみたところ、
レジストリ登録OKの .ocx と .dll は、MFC42.DLL と MSVCRT.DLL とその他でした。
レジストリ登録NGの .ocx と .dll は、MFC140.DLL と VCRUNTIME140.DLL とその他でした。
%windir%\syswow64 フォルダ内には、MFC42.DLL, MSVCRT.DLL, MFC140.DLL, VCRUNTIME140.DLL すべてが実在していました。

この依存している DLL の違いが、レジストリ登録に関係するのでしょうか？！

現在、登録NGの ocx と dll のビルド設定で依存関係を変更できないか調査していますが、方法が不明です。

なにかお気づきの点がありましたら、ご教授お願い致します。

[PineMatsu]

OCX(ActiveX)は、それを使うEXEと同じフォルダに入れておけば確か使えたはず。ただ、複数のアプリから使うのであれば、レジストリ登録して共有化しておくべきですが。

[cpp_beginner]

PineMatsu 様
ご回答有難う御座います。

exe ファイルと同一フォルダ内であれば使用可能なのですか？！
恥ずかしながら知りませんでした。貴重な情報を有難う御座います。
しかしながら、今回の .ocx / .dll は複数のアプリから使用される可能性があるため、レジストリ登録は行わなければなりません。

[PineMatsu]

たしか、レジストリに登録しているのはDLLのパスを得るためです。レジストリになければ、順序は違っているかもしれませんが、EXEと同じディレクトリ、パスが通っているところを探しに行くはず。
VB6では、ActiveXを登録せずにEXEと同じフォルダーに入れて使っていました。

[cpp_beginner]

PineMatsu 様
ご回答有難う御座います。

おっしゃる通り、今回の基となったVC++6.0で作成された.ocxと.dllは、VB6作成のインストーラ内でアプリと同一フォルダにパッケージング(.cab化)されて使われていました。
ただし、格納場所は同一フォルダでしたが、$(DLLSelfRegister) と $(Shared) が付随していました。
これはレジストリ登録のコマンドかと思っていました。
（違っていましたら申し訳ありません。Windows開発の知識が全く足りていないということでご了承ください）

Answer 3

regsvr32はsyswow64フォルダにもあります。
32bitのocxを登録するにはこちらのregsvr32を使う必要があるかもしれません。
syswow64フォルダのcmdを実行してもsystem32フォルダがカレントとなり、syswow64フォルダのregsvr32が使われていない可能性があります。
フルパスで指定するか、カレントフォルダを移動してからregsvr32を実行してみてはいかがでしょうか。
的外れでしたらすみません。

Comments

[cpp_beginner]

ttyp03 様
ご回答有難う御座います。

cmd起動直後のカレントフォルダ %windir%\system32 にて
%windir%\syswow64\regsvr32 %windir%\syswow64\xxxxx.ocx
も試してみましたが、現象は変わりませんでした。

また、カレントフォルダを %windir%\syswow64 に移動して
regsvr32 xxxxx.ocx
も試してみましたが、現象は変わりませんでした。

Answer 4

以下のサイトに、同様の問題があったが、再度管理者権限でコマンドプロンプトを起動してうまくいった、という報告があります。

https://blogs.msdn.microsoft.com/rajakedar_ganta/2012/06/06/dllregisterserver-failed-with-the-error-code-0x80040201/

もう一度コマンドプロンプトを管理者権限で起動し、ocxの登録を行うとどうでしょうか？
お役に立てなかったらゴメンナサイ。

Comments

[cpp_beginner]

kenshirou 様
ご回答有難う御座います。

残念ながら、何度試しても現象は変わりませんでした。
※ /u 付きのコマンド（登録解除）は成功するんですが｡｡｡