Eoleexception ошибка при вызове метода processdata интерфейса

Обновлено 27.08.2022

Добрый день! Уважаемые читатели IT блога Pyatilistnik.org, в прошлый раз мы с вами разобрали за, что отвечает библиотека vcruntime140.dll и на сколько она важна для работы многих программ. Сегодня я хочу вам рассказать, об интересном случае, когда специализированный софт может не получить доступ к удаленному компьютеры по RPC протоколу из-за новых политик безопасности DCOM. В логах будет фигурировать событие об ошибке DCOM ID 10036 «политика уровня проверки подлинности на стороне сервера не разрешает пользователю». Давайте смотреть в чем дело.

❌Описание ошибки DCOM ID 10036 (EOleException)

Обратился ко мне мой коллега с просьбой показать ему, как отправлять сообщение всем пользователям терминального хоста. Я предложил ему бесплатную утилиту Terminal Services Manager и подумал, что задача выполнена, но не тут то было. Коллега сказал, что у него не подключается к RDSH хосту и высвечивается ошибка доступа. Я решил так же проверить данную ситуацию.

Запустив Terminal Services Manager, в логе я увидел вот такую ошибку подключения:

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

Давайте выяснять в чем дело и как это можно обойти.

⚙️Причина ошибки DCOM ID 10036

Первое, что я стал изучать, что такое RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. В итоге я наткнулся на статью Microsoft о константах уровня аутентификации.

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

В итоге есть вот такой список констант:

• RPC_C_AUTHN_LEVEL_DEFAULT — Использует уровень проверки подлинности по умолчанию для указанной службы проверки подлинности.
• RPC_C_AUTHN_LEVEL_NONE — Не выполняет аутентификацию.
• RPC_C_AUTHN_LEVEL_CONNECT — Аутентифицируется только тогда, когда клиент устанавливает связь с сервером.
• RPC_C_AUTHN_LEVEL_CALL — Выполняет аутентификацию только в начале каждого вызова удаленной процедуры, когда сервер получает запрос. Не применяется к удаленным вызовам процедур, выполненным с использованием последовательностей протоколов на основе соединения (тех, которые начинаются с префикса «ncacn»). Если последовательность протокола в дескрипторе привязки представляет собой последовательность протокола на основе соединения, и вы указываете этот уровень, эта процедура вместо этого использует константу RPC_C_AUTHN_LEVEL_PKT.
• RPC_C_AUTHN_LEVEL_PKT — Аутентифицирует только то, что все полученные данные получены от ожидаемого клиента. Не проверяет сами данные.
• RPC_C_AUTHN_LEVEL_PKT_INTEGRITY — Аутентифицирует и проверяет, что никакие данные, передаваемые между клиентом и сервером, не были изменены.
• RPC_C_AUTHN_LEVEL_PKT_PRIVACY — Включает все предыдущие уровни и гарантирует, что данные в открытом виде могут быть видны только отправителю и получателю. В локальном случае это предполагает использование безопасного канала. В удаленном случае это включает шифрование значения аргумента каждого удаленного вызова процедуры.

Теперь стало понятно, за что отвечает RPC_C_AUTHN_LEVEL_PKT_INTEGRITY и видимо Microsoft, ужесточила какую-то политику безопасности, я стал изучать вопрос дальше. Поиск ошибки DCOM ID 10036 привел меня ну обсуждение нового обновления KB5004442, которое как я выяснил и вызывает эту ситуацию.

KB5004442 призвана усилить защиту DCOM объектов. Удаленный протокол модели распределенных компонентов (DCOM) — это протокол для предоставления объектов приложений с помощью удаленных вызовов процедур (RPC). DCOM используется для связи между программными компонентами сетевых устройств. Многие из нас на самом деле не понимают этого, и мы не можем диагностировать ошибки DCOM в наших журналах событий, которые, по-видимому, не оказывают серьезного влияния на наши сети. Эта технология представляет собой протокол для предоставления объектов приложения с помощью удаленных вызовов процедур (RPC).

RPC являются ключевой частью Windows. RPC — это клиент-серверный протокол, который разработчики приложений могут использовать для вызова процедур на локальном или удаленном узле в сети. Детали подключения и сортировка данных выполняются за кулисами на уровне RPC, что дает разработчикам средства для прямого подключения клиентских приложений к удаленному компьютеру. Это позволяет разработчикам не беспокоиться о знании деталей того, как данные передаются между двумя машинами и как вызываются процедуры.

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

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

1. 8 июня 2021 г. — Изменения защиты отключены по умолчанию, но с возможностью включить их с помощью ключа реестра.
2. 14 июня 2022 г. — Защитные изменения включены по умолчанию, но с возможностью отключить их с помощью ключа реестра.
3. 14 марта 2023 г. — Усиление изменений включено по умолчанию, отключить их невозможно. К этому моменту вы должны решить все проблемы совместимости с усиливающими изменениями и приложениями в вашей среде.

Так же помимо события ID 10036, есть еще два:

• %1 — путь к приложению
• %2 — PID приложения
• %3 — CLSID класса COM, который приложение запрашивает для активации
• %4 — имя компьютера
• %5 — значение уровня аутентификации

💡Как устранить ошибку ID 10036

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

Тут IP-адрес откуда идет подключение 10.11.11.210, там и нужно установить все возможные обновления безопасности.

Как только я обновился, ошибка EOleException ушла и мой Terminal Services Manager успешно подключился к серверу.

Если по каким, то причинам ваше приложение не заработало, а вам нужно, то есть лазейка до 2023 года в виде ключа реестра, который вы должны добавить на сервере, куда вы пытаетесь производить подключение. Запустите реестр Windows и перейдите в раздел:

И создайте там ключ реестра с типом REG_DWORD (32-бита) с именем RequireIntegrityActivationAuthenticationLevel.

• RequireIntegrityActivationAuthenticationLevel = 0x00000000 выключает политику
• RequireIntegrityActivationAuthenticationLevel = 0x00000001 включает политику

Если и данный метод вам не помог, то как крайняя мера может быть, это удаление обновления. Посмотрите список установленных обновлений командой:

После чего просто прочитайте инструкцию, как это сделать. Надеюсь, что вам оказалась полезна данная статья, и вы устранили ошибку EOleException. Если остались вопросы, то пишите их в комментариях. С вами был Иван Сёмин, автор и создатель IT портала Pyatilistnik.org.

Дополнительные ссылки

• https://docs.microsoft.com/en-us/windows/win32/rpc/authentication-level-constants
• https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c
• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26414

← →
Василич
 
(2002-09-19 19:16)
[0]

Здравствуйте ! Подскажите, пожалуйста, вследствие чего появляется ошибка «EOLEException. Не удается найти строку для обновления. Некоторые значения могли быть изменены со времени ее последнего чтения». Ошибка выдается после метода Post или Requery. Везде искал, не могу найти даже описания ошибки.

← →
Василич
 
(2002-09-20 10:29)
[1]

Ребята, ну неужто никто не знает ?

← →
Johnmen
 
(2002-09-20 10:40)
[2]

← →
Василич
 
(2002-09-20 11:35)
[3]

Подобный вопрос отсутствует. Самое интересное, что трассировка запроса с помощью SQL Profiler ничего не дает !

← →
Юрий Жуков
 
(2002-09-20 13:09)
[4]

← →
Василич
 
(2002-09-20 15:25)
[5]

← →
Юрий Жуков
 
(2002-09-20 16:00)
[6]

← →
Василич
 
(2002-09-20 16:04)
[7]

← →
Юрий Жуков
 
(2002-09-20 16:40)
[8]

← →
Василич
 
(2002-09-20 16:47)
[9]

И что мне писать в это «bla-bla» ?

← →
Василич
 
(2002-09-20 18:06)
[10]

Это все, к сожалению, не помогает.

← →
Юрий Жуков
 
(2002-09-20 19:15)
[11]

← →
Василич
 
(2002-09-23 09:45)
[12]

← →
Василич
 
(2002-09-23 10:40)
[13]

Я немного понял. Для того, чтобы Update отрабатывался нормально,
ВСЕ поля в таблице должны быть заполнены (не равны NULL). Может, следует каким-то образом изменить запрос ?

← →
Василич
 
(2002-09-23 11:15)
[14]

← →
MOA
 
(2002-09-23 13:05)
[15]

← →
Юрий Жуков
 
(2002-09-23 13:22)
[16]

← →
Василич
 
(2002-09-23 14:53)
[17]

← →
MOA
 
(2002-09-23 15:22)
[18]

>уничтожить в корне эту проклятую ошибку

Я бы сделал так:

1.Запрос:

«SELECT C.ComputerID AS «

← →
Юрий Жуков
 
(2002-09-23 15:42)
[19]

← →
Василич
 
(2002-09-26 14:05)
[20]

Ничего у меня не получается. Для интереса создал уникальный индекс во всех родительских таблицах, последовал всем советам MOA, и ничего не работает !!! Судя по вылетающей в этот раз ошибке («Cannot insert duplicate key») SQL Server действительно пытается засунуть записи в родительские таблицы, хотя ясно указаны все динамические свойства типа Resync Command и Unique Table. Подскажите, как избавиться от этой нездоровой тенденции SQL-сервера апдейтить таблицы, которые совершенно не нужно апдейтить !

← →
Юрий Жуков
 
(2002-09-26 14:32)
[21]

← →
MOA
 
(2002-09-26 15:10)
[22]

Может, так:?

1. Если не хочется отказываться от VIEW — добавить отдельные DataSet-ы на вставку — обновление — удаление и перехватывать соответсвующие события, не давая «основному» датасету вставлять-удалять-обновлять

Или

2. В «Основном» датасете обращаться к детайл-таблице, оформив поля из мастер-таблиц как Lookup поля. Понадобится дополнительно столько датасетов, сколько мастер-таблиц — но обновления-удаления-вставки будут работать как ожидается + бонус — автоматом появится возможность юзеру выбирать нужные значения из Lookup-ов.

Любая таблица должна иметь PRIMARY KEY. И мастер — тоже. И это — ключ для ссылки из детайл.

А дублирующиеся ключи — это точно не ключи в детайл-таблице?

Удачи!

← →
MOA
 
(2002-09-26 15:25)
[23]

← →
MOA
 
(2002-09-26 16:04)
[24]

Sorry, забыл, что у Вас не VIEW, a SELECT.

НО все же — попробуйте в SELECT выбирать только ссылки на мастер-таблицы (ID), а не названия.

Удачи!

← →
Василич
 
(2002-09-26 16:08)
[25]

Похоже, этот кошмар никогда не кончится. Сделал все по вашим советам: lookup-поля, куча датасетов, по одному на каждую таблицу, даже не датасеты, а BetterADODataSets, черт бы их побрал. Насмотрелся на кучу новых ошибок, как например, сверхинформативное сообщение «Не удается вставить или обновить столбцы из нескольких таблиц», или, «При вызове ITransaction::Commit или ITransaction::Abort объект не отвечает на запросы». Короче, пора переквалифицироваться в дворники, всем спасибо за оказанную помощь.

← →
MOA
 
(2002-09-26 16:13)
[26]

← →
Василич
 
(2002-09-26 16:16)
[27]

← →
MOA
 
(2002-09-26 16:35)
[28]

← →
MOA
 
(2002-09-26 16:36)
[29]

Русские названия, конечно же, Вам понадобятся только для созданных Вами Lookup полей. Наверное, не нужно юзеру знать русское название поля ProcessorID, например.

Удачи!

I have a Delphi 6 professional program that is calling COM object methods belonging to an MSVC 2008 COM DLL. The DLL’s Type Library imported without error into Delphi. I can call one of the method’s without error, but most of the others lead to an EOleException error with the message «An unexpected exception was raised», which corresponds to the EOleException error code: 0x80040205,
EVENT_E_INTERNALEXCEPTION:

http://msdn.microsoft.com/en-us/library/cc704587(v=prot.10).aspx

I am calling CoInitialize before making the call:

var
    intfMsvcComObj: IMsvcComObject;

begin
    if not Succeeded(CoInitialize(nil)) then
        raise Exception.Create('Coinitialize failed.');

    intfMsvcComObj := CoMsvcComObject.Create;

    try
        // EOleException occurs when I make this call.
        intfMsvcComObj.doSomething;
    finally
        CoUninitialize;
    end;
end;

Next I tried turning of FPU exceptions because that sometimes is an issue when calling into MSVC DLLS using Set8087CW($133f) and then I tried again with Set8087CW(Get8087CW or $3f), but neither of those operations helped.

Any ideas on how to fix/diagnose this?

I have a Delphi 6 professional program that is calling COM object methods belonging to an MSVC 2008 COM DLL. The DLL’s Type Library imported without error into Delphi. I can call one of the method’s without error, but most of the others lead to an EOleException error with the message «An unexpected exception was raised», which corresponds to the EOleException error code: 0x80040205,
EVENT_E_INTERNALEXCEPTION:

http://msdn.microsoft.com/en-us/library/cc704587(v=prot.10).aspx

I am calling CoInitialize before making the call:

var
    intfMsvcComObj: IMsvcComObject;

begin
    if not Succeeded(CoInitialize(nil)) then
        raise Exception.Create('Coinitialize failed.');

    intfMsvcComObj := CoMsvcComObject.Create;

    try
        // EOleException occurs when I make this call.
        intfMsvcComObj.doSomething;
    finally
        CoUninitialize;
    end;
end;

Next I tried turning of FPU exceptions because that sometimes is an issue when calling into MSVC DLLS using Set8087CW($133f) and then I tried again with Set8087CW(Get8087CW or $3f), but neither of those operations helped.

Any ideas on how to fix/diagnose this?

Я сделал два компонента ActiveX в Delphi XE2 в отдельных проектах. Один из компонентов работает отлично, и каждое исключение, которое он выдает, маскируется как EOleException. На другом компоненте ActiveX исключения не маскируются, они генерируются как исходный тип. Клиент представляет собой программу delphi XE.

Когда компонент ActiveX выдает исходное исключение, следующий вызов любого другого метода из компонента выдает исключение нарушения прав доступа в тех местах, где он не должен, например, установка локальной строковой переменной со значением. Это очень странное поведение.

Я сравнил оба проекта: файл .ridl, параметры компиляции, файл .dproj и не смог найти виновника.

Кто-нибудь знает причину этой разницы/странного поведения?

благодаря

Изменить: какой-то код

Компонент 1, который работает (маскирует все исключения для EOleException)

TspdMyClassX = class(TActiveXComponent, MyInterface)

…

initialization


TActiveXComponentFactory.Create(
    ComServer,
    TspdMyClassX,
    CLASS_spdMyClassX,
    1,
    '',
    0,
    tmBoth);

Другой компонент, который не генерирует EOleException, имеет другой интерфейс, но остальная часть кода такая же (инициализация, родительский класс TActiveXComponent).

A Windows service when trying to access the .Body property of a MSMQ message object throws an EOleException — but only when the Xml document contained in this message has an empty list node.

The EOleException message complains about insufficient memory (exception code -2147024882). Since the exception only occurs with the smallest possible Xml document, memory cannot be the real issue. The next thing that comes to mind is a problem with access rights but then again all «good» messages (as described below) are processed without problems.

The exception can be reproduced under any thinkable condition («bad» message first, many «good» messages first — then «bad» message, run in debugger or just logging the exception); it doesn’t matter if the code shown below is run as a service or as a simple excecutable.

Using the same COM object (MSMQ.MSMQQueueInfo) from within a VBScript on the same machine does not produce any errors.

Accessing any other properties apart from .Body doesn’t throw an exception so the message object instance seems to be received sucessfully. Also the transaction receiving the message can be comitted sucessfully if the .Body property is not accessed.

Windows Service code

//...
qInfo    := CreateOleObject('MSMQ.MSMQQueueInfo');
qTxDisp  := CreateOleObject('MSMQ.MSMQTransactionDispenser');
//...
qTx := qTxDisp.BeginTransaction;
qMessage := qQueue.Receive(qTx, False, True, 0);
//...
sBody := qMessage.Body; //throws EOleException

The qMessage.BodyLength property returns the value 165 for «bad» messages as shown below.

«Bad» message

<?xml version="1.0" encoding="Windows-1252"?>
<response space="" Message="Entry_7">
    <query>
        <entrylist count="0">
        </entrylist>
    </query>
</response>

This message reliably makes the service code throw an EOleExecption.

«Good» message

<?xml version="1.0" encoding="Windows-1252"?>
<response space="" Message="Entry_7">
    <query>
        <entrylist count="2">
            <entry>
                <abc>123</abc>
                <def>456</def>
            </entry>
            <entry>
                <abc>789</abc>
                <def>000</def>
            </entry>
        </entrylist>
    </query>
</response>

This message is reliably processed without problems.

The problem first occured when moving the service from a Win2003 machine to a Win2008 (32-bit Standard).