Создание ADOQuery в удалённом процессе

← →
FunkyByte © (2005-12-14 23:49) [0]

Доброго времени суток, уважаемые мастера. Волею судеб пришлось создавать поток в удалённом процессе. Задача эта была решена так, как нам завещал дедушка Рихтер, а именно:
1. Выделяется блок памяти в адресном пространстве удаленного процесса через VirtualAllocEx.
2. При помощи WriteProcessMemory копируется строка с полным именем файла DLL в блок памяти, выделенный в п 1
3. С использованием GetProcAddress извлекается истинный адрес функции LoadLibraryA или LoadLibraryW внутри Kernel32.dll.
4. Через вызов CreateRemoteThread создаётся поток в удаленном процессе, который вызовет соответствующую функцию LoadLibrary, передав ей адрес блока памяти, выделенного в п. 1.
В исполняемом разделе присоединённой dll-ки создаются объекты 2-х самописных классов: TRegAPIHook и SomeClass (с названием пока ещё не определился :)). Первый объект перехватывает (а именно сплайсит) обращения "заражённого" процесса к API-функциям, работающим с реестром. Методы второго объекта прописаны, как обработчики событий, возникающих при перехвате вышеупомянутых API.
Всё вышеизложенное написано, отлажено и, как ни странно, работает. Затем я попытался приладить ко всей этой конструкции компонент ADOQuery, чтобы через него вести лог обращений к реестру. Прилаживал я его разными способами (посредством DataModule и напрямую, прописывая ему в качестве владельца Application и SomeEkz (объект-экзепляр реализации SomeClass)). Во всех случаях возникал один из 2-х наборов ошибок (причём от чего зависит, какой набор возникает при каждом конкретном прогоне я так и не понял):
1. Исключение неизвестное программное исключение (0x0eedfade) в приложении по адресу 0x77e73887
2. Exception EOleSysError in module RAHLib.dll at 00063525. Не был произведён вызов CoInitialize
3. Access violation at address 00A143C4. Read of address 0A143C4.

или

1. Исключение неизвестное программное исключение (0x0eedfade) в приложении по адресу 0x77e73887
2. Exception EOleSysError in module RAHLib.dll at 00063525. Не был произведён вызов CoInitialize
3. Инструкция по адресу "0x00a143c4" обратилась к памяти "0x00a143c4". Память не может быть "read"
4. Runtime error 216 at 00A143C4
5. Инструкция по адресу "0x00a143c4" обратилась к памяти "0x00a143c4". Память не может быть "read"
6. Runtime error 216 at 00A143C4

А теперь внимание вопрос: почему возникают подобные ошибки? Чего такого особенного в стандартном ADOQuery, что в вышеописанной ситуации его конструктор вызывает целую плеяду ошибок, а объекты самодельных классов TRegAPIHook и SomeClass создаются без проблем?
И как можно побороть эту напасть?
Заранее благодарен.

P.S.: при необходимости могу выложить/выслать исходники по первому требованию. Только помогите. Времени осталось меньше 2-х недель, а прогу ещё писать и писать даже без подобных траблов.

← →
sniknik © (2005-12-15 01:38) [1]

> Не был произведён вызов CoInitialize
однозначно надо произвести...
CoInitialize(nil);
try
//сдесь код работаюший с COM обьектами (каким является и ADO)
finally
CoUnInitialize();
end;

вместо ADOQuery возьми ADODataSet/ADOCommand, по ситуации, и обязательно используй ADOConnection если вдруг не используеш.

← →
FunkyByte © (2005-12-15 21:20) [2]

Мдя, вот в таких случаях начинаешь понимать, зачем выводятся сообщения об ошибках :)
Но на этом злоключения ADOQuery в чужом процессе не закончились. После создания объекта пытаюсь в run-time добавить текст запроса в ADOQuery.SQL и получаю Access Violation. Пытаюсь выполнить ExecSQL при забитом в design-time запросе - аналогично. Проверяю наличие ADOQuery в памяти - он и не думал оттуда никуда деваться. Пытаюсь считать забитый в design-time текст запроса:
showmessage(DataModule1.ADOQuery1.SQL.Strings[0])
ошибок не возникает. В чём дело?

← →
sniknik © (2005-12-15 22:20) [3]

> ... run-time добавить текст запроса в ADOQuery.SQL
> ... Пытаюсь выполнить ExecSQL
и то и другое "бантики" на основных компонентах, никакой функциональной роли не несут, только "украшательные"(/маскируют под аналог TQuery из BDE).

всетаки попытайся последовать совету и использовать ADOCommand (судя по ExecSQL, нужен он)
большой уверенности что поможет нет... но, а вдруг?

← →
FunkyByte © (2005-12-15 23:13) [4]

> и то и другое "бантики" на основных компонентах, никакой
> функциональной роли не несут, только "украшательные"(/маскируют
> под аналог TQuery из BDE)

всмысле? а куда помимо этих "бантиков" писать текст запроса? и как его потом выполнять?

> всетаки попытайся последовать совету и использовать ADOCommand
> (судя по ExecSQL, нужен он)
> большой уверенности что поможет нет... но, а вдруг?

попытался. "вдруг" не произошло - ситуация полностью повторилась

← →
sniknik © (2005-12-16 00:33) [5]

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

ложить надо в родные предназначенные для этого свойства, а не использовать дополнительный навесок который только и делает что передает текст в то самое родное поле (к тому же убого)

но раз не получается то значит дело в чемто другом (передаче строк например), не думаю чтобы в чужом процессе можно было использовать дельфевские строки, менеджер памяти то туда не переносится. возможно придется вообще использовать "чистые" без оберток обьекты (_Command вместо ADOCommand) и т.д.
но вообще, не уверен, "темная" для меня область, необходимости внедрятся куда либо не возникало ни разу...

http://delphimaster.net/view/2-1133684536/

2 sniknik
У тебя нет описания методов "чистого" объекта _Command и параметров, требуемых ими? Или хотя бы ссылки, где есть такое описание? Искал в Инете по запросу "ADODB.Command.2.7" - не нашёл. Даже на МСДН.

мс оффис стоит? тогда и у тебя есть, файл ADO210.CHM. нет, значит поставь, только нерезаный (пиратские зачастую идут без того что они считают "лишним").

Создание ADOQuery в удалённом процессе Найти похожие ветки