У нас есть неуправляемое приложение C ++ (платформа MFC, Windows CE), которое закрывается для нас в случайные, казалось бы, моменты.
Нет сообщения об ошибке и нет исключения C ++, оно просто исчезает.
Я предполагаю, что произошло что-то плохое, и среда выполнения C или ОС решили убить программу.Но я не уверен, где продолжить поиск.
Вопрос: возможно ли увидеть где-нибудь в Windows CE , почему приложение завершилось в первую очередь?
Собирает ли Windows CE базовую информацию о сбое?Возможно, тогда можно будет хотя бы посмотреть, было ли это нарушение прав доступа, нехватка памяти, паника ядра / драйвера или, возможно, какое-то другое внутреннее или внешнее событие, которое вынудило приложение закрыться?
В обычном режимеНа x86 ПК можно было бы отключить отладчик, верификатор приложений, инструменты отчетов об ошибках Windows, WinDbg и т. д. Но как (запустить) проанализировать сбой приложения Windows CE?
Что я пробовал до сих пор:
- Создание глобальных обработчиков исключений C ++ в тактических местах приложения.Они создают и передают простой пакет UDP, содержащий минимальную информацию об исключениях.затем они просматриваются на другом компьютере с Wireshark.
- Добавление переключателя компиляции исключений SEH (
/EHa), чтобы можно было перехватывать даже те исключения, не связанные с C ++, как Access Violation и т. д. - Подключение отладчика Visual Studio 2008 через TCP / IP к интеллектуальному устройству (успешно подключается к интеллектуальному устройству, сообщает MSVS, но отладчик не видит удаленных процессов. В окне
Attach to process VS выдается следующая ошибка: Unable to Connect to ''.) - Перенацелить приложение таким образом, чтобы оно работало на обычном ПК с архитектурой x86 (но затем оно работает нормально, поэтому никакой «роскоши» отладки проблемы также нет)
Я протестировалобработчик исключений путем принудительного нарушения прав доступа.Ожидаемое UDP-сообщение поступает на компьютер, на котором отлично работает Wireshark.Но когда возникает настоящая проблема, она остается совершенно тихой.
Платформа: MS Windows Embedded Compact 7.02, работающая на процессоре Texas Instruments (ARM A8).
Само приложение реализует элементарный VNCзритель.Он использует сокеты и использует сторонний двоичный файл с именем zlib CE (ZLIBCE.DLL) для распаковки данных VNC.
Не было проверено, был ли двоичный файл zlib собран с точно таким же компилятором (и / или настройками компилятора).