Перехват EOleException

Доброго здравия!

Можно ли каким нибудь образом перехватить исключение блока try except до его обработки, например EOleException?

 

Средствами яп ?

Уточните вопрос, нужно больше нюансов, которые вам кажутся не существенными.

Вот всякой инфы навалом по юзерфаулт. Exeption oriented programming где то там даже видел.

 

Источник исключения [DBNETLIB][ConnectionWrite (send())]. Что сия фунь делает? Где это посмотреть?

Перехват думал замутить чтобы получить больше инфы чем то что выдает обработчик. Прога сделана в Delphi7. Работает с БД через ADO контролы, юзает OLEDB провайдер. Скорее всего ошибка возникает внутри него. Меня смущает NET в описании, это ведь не dotNET? Полагаю прога неуправляемая.

--- Сообщение объединено, 11 янв 2025 в 07:36 ---

Где, черт ногу с

Нда, действительно вагон и маленькая тележка! Глаза разбегаются.

--- Сообщение объединено, 11 янв 2025 в 07:40 ---

Извиняюсь, пишу с мобилы.

 

ответ в гугле: "delphi winsock send" (отправляет запрос в сеть).

--- Сообщение объединено, 11 янв 2025 в 08:31 ---

поставьте бряк в отладчике на "send", и поймаете проблему за хвост.

 

Что имею на данный момент.
1. Файл exe нестабильной проги.
2. Исполняемый файл собран в среде Delphi7.
3. Ошибка EOleException указывает на слой Ole.
4. Ошибка вылетает при записи данных в БД, следовательно это OleDb.
5. Dependency Walker показывает в exe программы наличие связанных с Ole библиотек OLEAUT32.DLL и OLE32.DLL.
6. Просмотр функций в таблице импорта и экспорта OLEAUT32 наводит на мысль что она обслуживает используемые типы.
7. OLE32 интереснее, там уже работа с COM (очень много функций C0...).
8. Никакой ConnectionWrite не нашел.
Куда смотреть дальше - в OLE32.DLL? Здесь больше всего функционала.

Может кто знает, как сделать трассировку вызовов которые идут через OLEDB? Пробовал штатными средствами в ODBC - файл вывода пустой. Видимо OLEDB минует ODBC.

--- Сообщение объединено, 11 янв 2025 в 09:29 ---

В отладчиках не силен, какой лучше использовать?

 

для анализа Дельфи7 прожки в статике рекомендую инструмент IDR

 

OLE32.DLL и OLEAUT32.DLL смысла не вижу смотреть, это слой работы с COM в котором нет как таковой работы с DB.

 

EOleException = End Of Line ?
"4. Ошибка вылетает при записи данных в БД, ... " - конец буфера, строки, формата ... может быть?

 

Ole Automation (OleAut32) это концепция использования COM-объектов из Visual Basic и других скриптовых языков.
Вся вращается вокруг OleVariant - нетипизированной переменной Basic где может лежать что угодно, что совместимо со скриптовыми языками, включая интерфейсы IDispatch через которые можно попробовать вызвать у объекта метод зная только его текстовое имя и число параметров (все параметры передаются как массив OleVariant).
В Delphi этот тип называется просто Variant и обслуживается на уровне языка.

 

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

EOleException с описанием ConnectionWrite, как я писал выше, связано по видимому с TCP Chimney. Как я понял, эта техника позволяет операционной системе переносить обработку сетевых операций с CPU на уровень сетевого адаптера. Более подробно об этом могли бы рассказать сетевики, тема интересная. Так вот, Когда эта опция включена SQL Server обрабатывающий запросы от клиента может обрывать долго висящие соединения, например такие которые открыты с помощью TADOConnection, так как этот контрол реализует DataSource в терминах OLEDB Provider.

 

Просто COM-объекты могут быть межпроцессными - вызов метода в текущем процессе превращается в так называемый маршаллинг и обработка передаётся в другой процесс, включая даже другой компьютер по сети где находится настоящий экземпляр объекта, поэтому этот слой реализован на всяких сокетах.
Для OLEDB это разумеется нужная вещь чтобы в сервер базы данных передавать типа MS SQL.
Так же очень пригождается OleVariant в OLEDB как контейнер заранее неизвестных данных в колонках результата.

 

С маршалингом впервые столкнулся когда из C# тягал либу на Сях.

 

Вообще как было дело - однажды MS решили невероятно прокачать один из основных своих хлебов - MS Office двумя концепциями:
а) чтобы кусок таблицы из экселя можно было вставить в ворд и прям там же редактировать (Objects Linked and Embedded)
б) сделать тьюринг-полные макросы на VBScript так чтобы можно было полностью программно контролировать любой документ (Automation)
В результате эти концепции в процессе реализации (поистине блестящей) взаимно проникли друг в друга и теперь когда мы говорим OLE мы подразумеваем Automation, говорим Automation подразумеваем OLE.
Границы между процессами Word и Excel тоже пришлось преодолевать.

 

Это немного неправильный вопрос как бы.
DCOM он про то, что мы работаем с COM-объектами созданными в другом процессе так как будто бы они находятся в нашем процессе - у нас на руках есть интерфейс ISomething и мы вызываем ему методы передавая то да сё, но на самом деле этот интерфейс ведёт к объекту-перемычке в данном процессе который превращает вызовы в отправку данных другому процессу через какой то вид дальней связи (RPC) это называется marshalling. Всё крутится вокруг очень мощной инфраструктуры детали которой я даже не знаю, никогда не погружался, когда мы можем зарегистрировать свои объекты и интерфейсы в этой системе маршаллинга и далее всё для нас происходит крайне прозрачно - некие фабрики пакуют данные и данные об интерфейсах/объектах в потоки байт которые по RPC отправляются туда-сюда и выглядит внешне всё как просто то, что объекты создаются, методы вызываются.
Поэтому "передать картинку" тут немного неправильная постановка вопроса - всё выглядит как просто obj->method(param1, param2, ...). Параметры с идентификатором объекта и метода пакуются в сетевой вызов метода у реального объекта в другом процессе, а результат вызова возвращается обратно.
Логичный способ "передать картинку" это передать в параметре типа массив байтов.
То есть если бы мы создали интерфейс IMyObject с методом PutData( char *data, int size ) и предоставили бы информацию маршаллеру как эти данные запаковать в сетевой обмен - то и дело с концом.
Но я лично вообще в душе не знаю как как раз это сделать - описать свой метод для маршаллера и правила запаковки.
Поэтому на деле на практике самый простой способ - это воспользоваться типами которые уже известны маршаллеру и он сделает для них всё сам.
А маршаллеру известно всё что входит в инфраструктуру OLE/ActiveX.

Поэтому самый простой способ - это пользоваться всеми тулчейнами и тулзами которые MS наворотили вокруг OLE.
В первую очередь мы описываем объекты и интерфейсы в специальном формате библиотеки типов Type Library - это в том числе даст всю нужную информацию маршаллеру для нашей библиотеки COM-классов (включая приложение). Пользуясь там уже готовыми типами, например BSTR (Basic String) мы будем уверены, что маршаллер их передаст как нужно на другой даже компьютер.
Я всегда использовал для таких задач Delphi, а там всё это делается в формошлёпной манере легко и просто.
Но можно и в плюсах так делать, только руками многое придётся описывать и утилиты запускать.
Хотя в студии наверняка есть мастера.
Ну и если память не изменяет такой тип как массив байт там или принадлежит к числу примитивных или просто есть IByteArray как объект.

--- Сообщение объединено, 12 янв 2025 в 07:53 ---

P.S.
А, вспомнил, в OLE массив байт реализуется через тип SAFEARRAY.
Работать с ним надо через группу соответствующих функций: https://learn.microsoft.com/ru-ru/windows/win32/api/oleauto/nf-oleauto-safearraycreate
Вот этот передастся через параметр на другой ПК как миленький.

 

Простейший тут всё-равно будет не простым, т.к. вовлекает, как я выше говорил, довольно много инфраструктуры COM. Вот первый попавшийся пример в гугле как сделать DCOM-EXE-сервер (а это автоматически out-of-proc) с помощью библиотеки ATL и всех остальных прибамбасов.
https://github.com/microsoftarchive... server (ATLExeCOMServer)/C++/ATLExeCOMServer

Причём для простоты клиент там написан на VBScript:

Код (Text):

1. SET obj = CreateObject("ATLExeCOMServer.SimpleObject")
2.  
3. MsgBox "An ATLExeCOMServer.SimpleObject object is created"
4.  
5. ' call the HelloWorld method that returns a string
6. MsgBox "The HelloWorld method returns " & obj.HelloWorld
7.  
8. ' Set the FloatProperty property
9. MsgBox "Set the FloatProperty property to 1.2"
10. obj.FloatProperty = 1.2
11.  
12. ' Get the FloatProperty property
13. MsgBox "The FloatProperty property returns " & obj.FloatProperty
14.  
15. SET obj = Nothing

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

Ключевые особенности: EXE должен быть специальным образом написан - он должен поддерживать опции командной строки /RegisterServer и /UnregisterServer чтобы откладывать или убирать из реестра информацию о своих ком-объектах, а кроме того еще забыл какой ключ - когда процесс запускается именно из-за того, что была вызвана где то функция CreateObject (в VBS) или CoCreateInstance (C/C++). Тогда приложение еще запускается обычно в режиме сокрытия главного окна чтобы по умолчанию не отсвечивать если явно не попросят show yourself. Тут это берёт на себя библиотека ATL.
В первую очередь интересен .idl файл - это как раз описание интерфейсов и объектов в специальном языке.
При компиляции утилитой tlblib или как то так из него будут созданы .c и .h файлы с подкапотной реализацией некоторых штук, в том числе если память не изменяет относящихся к маршаллингу.

Когда клиент дёргает CreateObject/CoCreateInstance эти функции лезут в реестр по имени класса, там выходят на его GUID и по GUID-у выходят на имя exe где объект существует и запускают этот EXE со специальным ключом. После запуска происходит какой то скрытый RPC-коннект и EXE начинает обслуживать запросы. Это еще происходит в Main loop, т.е. цикл GetMessage тоже должен нормально крутиться.
Плюс еще в этом режиме запуска если память не изменяет - ATL закроет приложение когда последний COM-объект исчезнет (отрелизится).

В общем простой пример да с аналогом в ассемблере тут хрен сделаешь.

 

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

 

В Delphi всё вообще суперпросто сделано - сделал аппликуху с окошечком, а потом просто сделал "Add to project..." и выбрал "Type Library".
Вся инфраструктура подтянется, приложение получит поддержку сразу ключей командной строки RegisterServer/UnregisterServer и появится в дереве проекта собственно Type Library где:

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

--- Сообщение объединено, 12 янв 2025 в 12:57 ---

IDataObject это кирпичик именно в Objects Linked and Embedded - просто интерфейсы для оповещения в Word, что в листе Excel что-то поменялось, а точнее даже довольно низкоуровневая штука для поддержки всего этого великолепия когда одни документы внедреяют в себя другие документы. Там и визуальных штук очень очень много для концепции inplace-редакторов.
А если просто примитивную задачу рассматривать - как с клиента на сервер передать пачку байт, то это просто вызов любого метода, просто самая базовая операция - вызов метода с параметрами.