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