Почему любая введенная DLL может привести к сбою хост-процесса? - PullRequest
2 голосов
/ 07 февраля 2012

В ходе бета-тестирования новой версии моего программного обеспечения несколько пользователей сообщали об исключениях при запуске приложения. В обоих случаях это: «Приложение не удалось правильно запустить (0xc0000142)». Я также видел это как 0xc0000005. Я также обнаружил локальную систему с этой ошибкой и обнаружил, что при запуске отладчика «datamngr.dll» имел нарушение прав доступа и не удалось выделить в куче. Я быстро обнаружил, что «datamngr.dll» является шпионским ПО и загружается так же, как и в системном AppInit.

После того как я очистил ключ реестра AppInit, эта проблема исчезла. Я проверил это через Process Monitor, и каждый раз, когда вводилась эта DLL, мое приложение зависало. Я думал, что это просто плохо написанная шпионская программа, но с тех пор я обнаружил, что другие библиотеки DLL делают то же самое (например, acaptuser32.dll, который является законным программным обеспечением). Что странно для меня, предыдущая версия моего программного обеспечения не падает. Было много, много изменений между двумя версиями, поэтому трудно сказать, что это такое.

С чего мне начать? Некоторые онлайн-исследования показывают, что такие приложения, как Firefox, заменяют LoadLibrary, чтобы черный список DLL-файлов не был введен Но я бы хотел начать с более простого: почему приложение теперь падает, а раньше - нет?

Я понимаю, что это очень расплывчато, но это почти неизбежно. Я надеюсь, что в свойствах проекта, который я делаю неправильно, есть что-то очевидное. Я пробовал с включенным и выключенным ASLR, включенным и выключенным DEP ... Я попытался отложить загрузку user32.dll и вручную загрузить его через LoadLibrary (с SetErrorMode, установленным, чтобы игнорировать ошибки), и ничего у меня не работает. Мы видели, как это происходит в Windows XP и Windows 7 (32- и 64-разрядных).

Будем весьма благодарны за любые указания о том, с чего начать. Я предоставлю столько информации, сколько смогу, если кому-то понадобятся другие подробности.

Приветствия

1 Ответ

1 голос
/ 08 февраля 2012

Я нашел исправление. Я использовал Process Monitor для сравнения порядка загрузки DLL в версиях с инжекторами DLL и без них. Одна вещь, которая затем поразила меня, - это C ++ DLL, которая у меня есть, которая загружает .NET (через LoadLibrary), которая была включена первой. Поскольку CLR такой большой зверь, я решил попробовать отсрочить загрузку этой DLL и всех .NET DLL. Вот и все, что нужно - моя проблема ушла.

Так что, как сказал Раймонд Чен, порядок хрупок. Если другие люди сталкиваются с этой проблемой, я предлагаю просто настроить порядок загрузки DLL.

...