次のようにします。COMオブジェクトは、独自のモジュールをメモリに保持しますか？
1）LoadLibraryを使用してfoo.dllをロードします。
2）GetProcAddressを使用して関数へのポインタを取得します。
3）関数を呼び出して、そのモジュールで実装されているCOMオブジェクトへの参照を与えます。
4）FreeLibraryを呼び出してfoo.dllを解放します。
5）COMオブジェクトのメソッドを呼び出します。
手順5は成功し、AVはないと思いますか？つまり、COMオブジェクト自体がLoadLibraryを呼び出して（再び）Windowsが各モジュールに対して保持する参照カウントをインクリメントして、モジュールの寿命を延ばさないようにしますか？
私はAVを期待しています。たとえそれが今日AVではなかったとしても、これはおそらく起こるのを待っているクラッシュです。
カスタムDLLのエクスポートによってCOMオブジェクトが返された場合、アプリケーションがDLLのリソースを使用している限り、COMオブジェクトがDLLの参照カウントをインクリメントするとは思いません明示的にロードされた場合、そのDLLをロードしたままにするのはアプリケーションの責任です。
通常のCoCreateInstanceルートを使用して作成されるin-proc COMオブジェクトの場合、DLLは通常、未処理の参照がある限りS_FALSEを返すDllCanUnloadNowをエクスポートします。
しかし、COMオブジェクトがLoadLibraryを介してDLLの参照カウントをインクリメントすることを妨げるものは何もありません。これについては何も違法で安全ではありません。
確かにありません。モジュール参照カウントは、通常の使用方法によって維持されます。実行しているのは、実行時スキームのバックドアです。通常、CoCreateInstanceなどを使用してオブジェクトを作成します。これらはCoGetClassObjectとDllGetClassObjectを呼び出すラッパーです。 CoGetClassObjectは、dllの参照カウントを維持するCoLoadLibraryを呼び出します。さらに、クラスオブジェクトに対してLockServerを呼び出して、パフォーマンスのためにクラスオブジェクトの参照カウントを維持することもできますが、dllが確実に読み込まれるようにする必要はありません。
非常に興味深い。手順3で呼び出された関数の名前がMyCreateInstanceであると答えた場合、答えは変わりますか？私。 CoCreateInstanceの後にモデル化されていますか？ありがとう！ –
上記の「標準」バージョンでは、CoLoadLibrary呼び出しはdllへの参照を保持します。これは安全なときにのみリリースされます（COMサーバーで作成されたオブジェクトへのライブ参照を参照するか、 –
DLLはDllCanUnloadNow呼び出しに関して未解決の参照をどのように追跡していますか？ありがとう！ –
しかし、それは望みです。実装を見てきました。各COMオブジェクトのコンストラクタ/デストラクタがモジュールのグローバル参照カウントをインクリメント/デクリメントし、DllCanUnloadNowはrefカウントをチェックするだけです。 – Michael