3

次の方法は、DCOMサーバーの方法です。COMクライアントとサーバーは異なるWinXPマシンで実行されています。COMクライアントは、RegisterClientメソッドを呼び出してコールバックインターフェイスを登録します。問題は、QueryInterfaceメソッドがエラーコードで失敗することですE_ACCESSDENIED。問題の理由は何でしょうか？

STDMETHODIMP CGEMExtension::RegisterClient(IUnknown** ppGEMExtensionEvents, int* nClientId, int* nResult)
{
    HRESULT  hRes = (*ppGEMExtensionEvents)->QueryInterface(IID_IGEMExtension,(void**)&pUnknown);
    return hRes;
}
4

3 に答える 3

3

E_ACCESSDENIEDを取得すると、アクセス許可に問題があることを意味します（ファイアウォールや登録に時間を浪費しないでください。前者はサービスが利用できないことを示すエラーを発生させ、後者はクラスが登録されていないことを通知します。それで）。COMはWindowsのアクセス許可に依存しているため、これに焦点を当てる必要があります。

あなたの場合、私がそのケースを正しく理解していれば、サーバーは実際にクライアントを呼び出して、適切なインターフェースを取得します。そのためには、サーバーを実行しているユーザーがクライアント側で適切な権限を持っている必要があります。いくつかの提案：

  1. daramarakが示唆しているように、サーバーとクライアントに同じドメインユーザー、または同じパスワードを持つ同じローカルユーザーを使用させる。
  2. クライアントで、この設定を「クラシック」に設定します。
  3. サーバーのユーザーに、クライアントに認識されている場合は、 DCOMCNFGを使用して追加のアクセス許可を付与します。
于 2011-06-28T08:24:09.097 に答える
1

これは、他のコンピューターの正しいアクセス許可が間違っていることが原因である可能性があります。これを確認する最も簡単な方法は、secpolを使用してログをオンにすることです（ローカルポリシー、監査ポリシー、ログオンイベントとオブジェクトアクセスのログをオンにする）。その後、他のマシンにアクセスしようとしているかどうかを確認できます。

テストしているだけの場合は、コンポーネントサービスのcomオブジェクトで「インタラクティブユーザーとして実行」設定を使用し、両方のマシンで同じパスワードを持つ同じユーザーがいることを確認することをお勧めします。次に、クライアントマシンで共通ユーザーとして実行している必要があります。特別にユーザーを一般ユーザーに設定することも可能です。

DCOM接続をデバッグするための一般的なアドバイスとして：接続が機能していることを確認するためにすべてのファイアウォールなどをオフにしてから、セキュリティ対策を1つずつオンにして、正しいポートを開いたままにし、正しいユーザーが正しいユーザーを持っていることを確認します権限。

于 2011-06-28T08:09:05.520 に答える
0

あなたの特定のケースに直接当てはまらないかもしれないとしても、私はあなたに私の経験を与えます。

64ビットのWindows7では、x64でコンパイルされたexeと32ビットでコンパイルされたdllがあります。

COMオブジェクトはdll内にあります。

exe（「通常の」ユーザーによって起動される）は、要求するCOMオブジェクトを（同じコンピューター上に）IUnknown作成し、作成は成功します。次に、exeはを介して別のインターフェイスを要求し、 。QueryInterfaceで失敗しE_ACCESSDENIEDます。

「管理者として」exeを起動すると、QueryInterfaceはで返されS_OKます。

これ以上調査しませんでした。32ビットと64ビットの相互作用について何らかのポリシーがあるのではないかと思います。

于 2012-03-17T08:56:20.440 に答える