Предотвращение блокирования диалогов / окон сообщений / зависания графического интерфейса от неинтерактивных процессов в Windows?

Question

Мы разрабатываем приложения для C ++ (много MFC) с Visual Studio 2005 для Windows.

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

Поскольку автоматизированное приложение запускается (службой Windows) без какого-либо сеанса рабочего стола, очевидно, никто не может подтвердить или даже прочитать сообщения GUI.

Есть ли способ, чтобы Windows не позволяла приложениям открывать диалоги? Или, может быть, инструмент, отслеживающий сеанс службы, который автоматически убивает любое приложение, открывающее диалоговое окно?

Я думаю, что в большинстве случаев, когда приложения отображают неожиданные всплывающие сообщения, в конечном итоге вызывается одна из MessageBox* функций из user32.dll, и может быть просто "волшебным образом", что эти функции не сработают для определенный логин-сессия? (Просто дикая идея.)

Очевидно, что «правильное» исправление состоит в том, чтобы иметь вещи, не открывающие никаких диалогов, но с инструментами сторонних производителей это не всегда возможно, и с нашими инструментами было бы лучше иметь неудачный модульный тест, который говорит мне, что тест "незаконно" открыл окно сообщения, чем у висящего модульного теста.

(Примечания: мы используем Boost.Test для наших модульных тестов и FinalBuilder для сценариев автоматической сборки.)

_{Примечание. Удалены исходные теги [автоматические тесты автоматизации непрерывной интеграции] и перефразирован вопрос, чтобы сделать его более ориентированным на процесс.}

Answer 1

Вы можете загрузить DLL в каждом из процессов, который подключает MessageBoxA и MessageBoxW. Вы можете сделать это вручную или через библиотеку Detours. Затем вы можете либо вернуть его сразу, не вызывая реальную функцию, либо даже реализовать некоторую форму регистрации, чтобы уведомить свой CI об ошибке.

Answer 2

Мы используем AutoIt для автоматического закрытия диалогов в нашем коммерческом приложении, работающем как Windows. Концепция описана, и некоторые примеры сценариев доступны здесь: http://www.coretechnologies.com/products/AlwaysUp/AutoIt/

Обратите внимание, что некоторые функции AutoIt не работают должным образом в сеансе 0 (например, WinActivate), но обычно вы можете найти альтернативы. Обязательно проведите тестирование в Сессии 0!