Подтвердить что ты не робот

Как я могу запретить библиотеке сторонних разработчиков отображать MessageBox?

Я интегрирую SDK сторонней C-SD в свое приложение .NET. Приложение будет работать как служба Windows на сервере, поэтому он не должен взаимодействовать с пользователем каким-либо образом.

К сожалению, в определенных условиях ошибки он настаивает на вызове MessageBoxA, предположительно, чтобы сообщить, что произошло что-то плохое. Когда это произойдет, служба перестает отвечать на запросы. Я предполагаю, что он ждет, чтобы кто-то нажал Ok?

Невозможно, чтобы продавец менял код для меня.

Есть ли способ сделать этот вызов в no-op, чтобы мой код мог автоматически обрабатывать ситуацию?

EDIT: Возможно, важно отметить, что в моем конкретном случае служба автоматически перезапустится, если она разбилась. Изящный (как возможно) и внезапный выход, вероятно, является лучшим разрешением для ситуации, когда MessageBox отображается в моем случае.

4b9b3361

Ответ 1

Отъезд Объяснения из Microsoft Research. Он позволяет объединять произвольные функции Windows API. Программирование на C/С++ требуется, чтобы заставить его работать. Вам не нужно много.

Ответ 2

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

Для людей, которые раньше делали такие вещи (взлома лицензий или другое обратное проектирование), это довольно просто, но реальный вопрос заключается в том, что происходит, если его игнорировать - продолжает ли он работать?

Ответ 3

Это не очень просто. Я бы подумал, что единственный способ - написать сообщение, чтобы перехватывать сообщения, перекачанные через все петли сообщений Windows в системе. Но я даже не уверен, что служба может создать привязку к сообщению, поскольку она не имеет доступа к стандартной станции по умолчанию по умолчанию (LocalSystem). Таким образом, задача № 1 - проверить, действительно ли это будет работать.

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

  • Создайте окна hook, чтобы улавливать сообщения из всех очередей сообщений Windows в системе.
  • Перехватите все сообщения WM_CREATE и проверьте параметр CREATESTRUCT для сообщений, которые могут быть получены из вашей сторонней библиотеки. Возможно, вам придется записывать все сообщения WM_CREATE, а затем анализировать данные, чтобы увидеть, как вы можете отличить диалоговое окно библиотеки от любого другого диалогового окна в системе. (Много раз член "lpszName" отличается между реализациями диалога.)
  • если вы считаете, что конкретный WM_CREATE пришел из вашей библиотеки, верните "обработанный" ответ из вашего сообщения и не вызывайте следующего обработчика сообщения в цепочке.

Это все очень рискованно, но это путь, который кажется таким, каким он имеет для меня шанс.