QueryInterface завершается ошибкой с E_ACCESSDENIED - PullRequest
Новая
       10

QueryInterface завершается ошибкой с E_ACCESSDENIED

3 голосов
/ 28 июня 2011

Следующий метод является методом сервера 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;
}

Ответы [ 3 ]

3 голосов
/ 28 июня 2011

Когда вы получаете E_ACCESSDENIED, это означает, что у вас есть проблема с разрешениями (не тратьте время на брандмауэрах или регистрациях - первый вызовет ошибки, сообщающие, что сервис недоступен, а второй скажет, что классне зарегистрировано или около того).COM полагается на разрешения Windows, поэтому вам следует сосредоточиться на этом.

В вашем случае, если я правильно понимаю, сервер фактически вызывает клиента, чтобы получить правильный интерфейс.Для этого пользователь, работающий на сервере, должен иметь необходимые разрешения на стороне клиента.Несколько предложений:

  1. Как рекомендует Дарамарак, сервер и клиент должны использовать одного и того же пользователя домена или одного и того же локального пользователя с одним и тем же паролем.
  2. На клиенте установите этот параметр для "классического".
  3. Предоставьте пользователю сервера, если он известен клиенту, дополнительные разрешения, используя DCOMCNFG .
1 голос
/ 28 июня 2011

Это может быть связано с неправильными правами доступа на другом компьютере.Самый простой способ проверить это - включить ведение журнала с помощью secpol (Локальные политики, Политика аудита, включить ведение журнала событий входа в систему и доступ к объектам), после чего вы можете увидеть, пытаетесь ли вы получить доступ к другому компьютеру.

Если вы только тестируете, я бы предложил использовать параметр «запускать как интерактивный пользователь» в объекте com в службах компонентов и убедиться, что у вас один и тот же пользователь с одинаковым паролем на обеих машинах.Тогда вы должны работать как обычный пользователь на клиентском компьютере.Также возможна специальная настройка пользователя на обычного пользователя.

В качестве общего совета по отладке подключения DCOM: отключите все брандмауэры и тому подобное, чтобы убедиться, что подключение работает, затем включите меры безопасности по одному, убедившись, что вы оставляете правильные порты открытыми и что правильные пользователи имеют правильные разрешения.

0 голосов
/ 17 марта 2012

Я даю вам свой опыт, даже если это может не относиться непосредственно к вашему конкретному случаю.

В Windows 7 на 64-битной версии у меня есть исполняемый файл, скомпилированный с x64, и dll, скомпилированный на 32-битном.1004 * COM-объект живет внутри dll.

exe (запущенный "обычным" пользователем) создает COM-объект (на том же компьютере), запрашивая IUnknown, и создание успешно.Затем исполняемый файл запрашивает другой интерфейс через QueryInterface, и он завершается неудачно с E_ACCESSDENIED.

Если я запустил исполняемый файл "как администратор", то QueryInterface вернется с S_OK.

Я больше не расследовал, я подозреваю, что есть некоторая политика в отношении 32-битного - 64-битного взаимодействия.

...