2

私はかなり奇妙で非常に特殊な DCOM 関連の問題に直面しており、誰かがそれに遭遇して解決したことを願っています。

Windows 7 マシン (W7 と呼びます) の EXE サーバーで COM オブジェクトをインスタンス化しようとしています。クライアントは Windows XP マシン (WXP と呼びます) 上にあります。WXP では、ログイン ユーザーはドメイン ユーザーです。W7 では、ユーザーはローカル ユーザーです。すべての DCOM 権限、認証、およびアカウント権限を (私の知る限り) 正しく設定しました。関連するファイアウォールはありません。

私が得たのは、COM EXEサーバープロセスがW7で開始され、期待するユーザー名で開始されたということだけですが、WinMain関数に到達することさえできず、ハングしたままになり、強制終了しない限り死ぬことはありません. リモート デバッガー (Visual Studio 2010) を接続すると、プロセスがデッドロックしている可能性があることが警告されます。プロセスを中断すると、メッセージ キュー ループ (GetMessage/Dispatch) で停止します。

クライアントは (一見有効な) ポインターを取得しますが、それを使用しようとすると、E_ACCESSDENIED が発生します。

上記のシナリオから何かが変更された場合、COM オブジェクトのインスタンス化は成功し、オブジェクトは正しく動作します。

答えが見つかる可能性はわずかですが、ヒントは大歓迎です。

ありがとう。

4

2 に答える 2

2

DCOMクライアントとサーバーは、ワークグループの同じローカル管理者であるか、同じドメインのドメインユーザーである必要があります。

このテストアプリを使用して、2台のマシンが正しく構成されているかどうかを確認できます。http： //support.microsoft.com/kb/259011 このようにして、マシンのアクセス許可とファイアウォールが、独自のコードなしで最初に正しくセットアップされていることを確認します。

于 2012-07-20T21:37:25.290 に答える
1

私自身の質問に答える...

結局、クライアントでは CoInitializeSecurity が必要なすべての資格情報を持っていなかったことが判明しました...資格情報が判明する前に、あまりにも早く呼び出されました。

これは、インスタンス化する各コンポーネントでCoSetProxyBlanket を使用した後に発見しました (ここで説明されているように: DCOM での偽装はどのように機能しますか? )。CoSetProxyBlanket を呼び出したすべてのコンポーネントは正しく機能していました。これにより、CoInitializeSecurity を再確認するようになりました。

逆接続 (W7 から WXP へ) が機能したのは不思議なままですが、これは私が行う必要がある別の調査です。現在の質問を閉じることができます。

于 2012-07-23T09:39:32.013 に答える