Что означает код HRESULT 0x00040000 (OLE_S_USEREG)?

 
Предыдущий Следующий
STG_S_POWER_CYCLE_REQUIRED OLE_S_STATIC

OLE_S_USEREG

OLE просит использовать сведения из реестра

это HRESULT 262144 (0x00040000) из winerror.h. AllStat описывает OLE_S_USEREG как «Используйте базу реестра для получения запрошенных сведений». Старший бит severity сброшен, поэтому это успешный результат, но он сообщает больше, чем обычный S_OK.

OLE-операция завершилась успешно, указав вызывающему коду использовать зарегистрированные сведения о классе вместо данных от экземпляра объекта.

Где встречается этот результат

  • Этот HRESULT может появляться в helper-функциях создания или активации OLE object; фиксируйте интерфейс и метод, вернувшие результат, а не делайте вывод только по символическому имени.
  • Этот HRESULT может появляться при поиске class metadata и verbs; фиксируйте интерфейс и метод, вернувшие результат, а не делайте вывод только по символическому имени.
  • Этот HRESULT может появляться в legacy embedding-коде, который способен получать сведения как от object handler, так и из registration database; фиксируйте интерфейс и метод, вернувшие результат, а не делайте вывод только по символическому имени.

Для этого результата, одно и то же числовое успешное значение может быть обработано неверно, если обёртка оставляет только Boolean. для этого результата сохраняйте исходный HRESULT до оценки выходных данных и перехода состояния, относящихся к конкретному коду.

Последовательность диагностики

  • Для этого результата, зафиксируйте исходный HRESULT 0x00040000 сразу после возврата из метода и запишите, использовал ли вызывающий код SUCCEEDED, FAILED, проверку на точное равенство или преобразование в исключение.
  • Определите точного владельца OLE_S_USEREG: интерфейс, метод, экземпляр объекта, версию поставщика или фильтра, поток или apartment и фазу операции.
  • Проверьте решающую границу контракта для этого результата: регистрация класса присутствует, правильно выбрана для bitness процесса и контекста user/machine и соответствует реально активируемому классу объекта.
  • Проверьте каждый выходной параметр, счётчик, массив статусов, возвращённый интерфейс и побочный эффект, который документация метода связывает с этим результатом «успех с дополнительной информацией».
  • Сравните наблюдаемое состояние до и после этого результата; не предполагайте, что признак успешной severity означает завершение каждой необязательной подоперации.
  • Для этого результата, воспроизведите минимальный запрос с тем же состоянием объекта, а перед повтором измените только условие, подтверждённое собранными данными.

Граница состояния, которую нужно подтвердить

Главный вопрос для этого результата — присутствует ли регистрация класса, правильно ли выбрана для bitness процесса и контекста user/machine и соответствует ли реально активируемому классу. для этого результата сам HRESULT не подтверждает завершение несвязанной работы и не гарантирует качество необязательных выходных данных.

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

Правильная обработка, повтор и восстановление

Следуйте документированному пути поиска в реестре и проверяйте регистрацию класса. Не заменяйте этот статус общей ошибкой и не выдумывайте возможности объекта, отсутствующие в регистрации.

Повторяйте OLE_S_USEREG только когда зафиксированное состояние действительно может изменить документированный результат. для этого результата, повтор того же вызова неуместен для устойчивого признака конца, отмены, неподдерживаемого формата, скорректированного свойства или частичного результата, уже выполненные побочные эффекты которого ещё не согласованы.

Какие доказательства и телеметрию сохранить

  • Сохраните CLSID и ProgID.
  • Сохраните выбранное 32- или 64-битное представление реестра.
  • Сохраните владельца регистрации и версию установки.
  • Сохраните запрошенные OLE-метаданные, например verbs или presentation.
  • Сохраните fallback-путь, выбранный после HRESULT.

Также зафиксируйте ole_s_usereg_operation, ole_s_usereg_object, ole_s_usereg_state_before, ole_s_usereg_state_after, время UTC, идентификаторы процесса и потока, а также correlation ID. для этого результата, не записывайте секреты в журналы, но сохраните GUID, CLSID, подтипы media, идентификаторы свойств, идентификаторы строк и хеши, необходимые для различения объектов.

Отличие от соседних значений HRESULT

OLE_S_STATIC описывает статический presentation object, а OLE_S_USEREG указывает вызывающему коду, где получить метаданные.

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

Рекомендации разработчикам и администраторам

Обработка кода OLE_S_USEREG должна проверять точное документированное значение до общей ветки SUCCEEDED(hr), если от него зависят выходные данные или управление. Операционное исправление для этого результата должно затрагивать компонент-владелец COM, media, Tablet PC или OLE DB, а не сбрасывать несвязанные службы.

Отчёт в поддержку для этого результата должен включать десятичное значение 262144, шестнадцатеричное 0x00040000, описание AllStat, API-владельца и первый детальный статус или выходной параметр, объясняющий, почему метод не вернул обычный S_OK.

Практический сценарий проверки

OLE-контейнер запрашивает у object handler сведения о классе и получает этот HRESULT. Он читает зарегистрированные verbs для CLSID, записывает использованное представление реестра и не запускает сервер только ради запроса метаданных.

Негативный тест должен сохранять условие, приводящее к этому HRESULT; тест восстановления должен менять только это условие и проверять как конечное состояние, так и HRESULT.

Ссылки

Нужно найти другой код? Найти другой код состояния или ошибки.