Предотвращение выполнения данных с помощью служб Windows - PullRequest
1 голос
/ 10 февраля 2012

Я использую 64-разрядную версию Windows 7 Ultimate.

У меня есть служба Windows (написанная на C #), которая вызывает библиотеку DLL, выпущенную крупным поставщиком телекоммуникационных услуг здесь, в Южной Африке (TELKOM). DLL называется MPIEst.dll, и я считаю, что она была написана на C ++. У парня по ссылке (вроде http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/thread/a7e5aafc-bb52-42c3-a3b7-19cb4cfbf6d5/)) была та же проблема, что и у меня.

После некоторых исследований я обнаружил, что DEP (Data Execution Prevention) был виноват в ошибке «Невозможно загрузить DLL« MPIest.dll »: Неверный доступ к расположению памяти. (Исключение из HRESULT: 0x800703E6)». Поэтому я подумал: «Хорошо, это просто ... давайте отключим DEP для всего компьютера и посмотрим, что произойдет». Поэтому я делаю это, и результат становится еще более странным ... Служба Windows работает успешно, как будто ничего не происходит, но все вызовы в DLL ничего не делают.

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

В любом случае, суть в том, что отключение DEP для всей системы не влияет на службу Windows. Кто-нибудь сталкивался с этим раньше? Служба Windows и консольное приложение вызывают один и тот же код и делают одно и то же, но консольное приложение работает должным образом, в то время как службы Windows молча ничего не делают, но DEP отключен для всей системы.

Заранее спасибо.

1 Ответ

2 голосов
/ 13 февраля 2012

Нашел решение. Решение на самом деле двоякое. Сначала есть DEP, который необходимо отключить для всего компьютера, а затем перезагрузить компьютер (это потому, что невозможно отключить DEP для службы Windows через панель управления).

Затем, во-вторых, я использовал приложение «ProcessMonitor», чтобы увидеть, что служба Windows и «MPIEst.dll» делали с ОС Windows за кулисами. Оказывается, что DLL искала файл, от которого она зависела (client.mpi), в папке системного каталога, хотя файл находился в том же каталоге, что и исполняемый файл службы Windows. Поэтому я добавил код для копирования необходимых файлов в системный каталог, и все заработало.

...