Посмертный анализ программы Windows Embedded Compact (Windows CE)

Question

У нас есть неуправляемое приложение C++ (платформа MFC, Windows CE), которое закрывается для нас в случайные, казалось бы, моменты.

Нет сообщения об ошибке и исключения C++, оно просто исчезает.

Я предполагаю, что произошло что-то плохое, и среда выполнения C или ОС решили убить программу. Но я не уверен, где продолжить поиск.

Вопрос: возможно ли увидеть где-то в Windows CE, почему приложение было остановлено?

Собирает ли Windows CE базовую информацию о сбое? Возможно, тогда можно будет хотя бы посмотреть, было ли это нарушение прав доступа, нехватка памяти, паника ядра / драйвера или, возможно, какое-то другое внутреннее или внешнее событие, которое заставило приложение закрыться?

На обычном ПК с архитектурой x86 можно было бы использовать отладчик, верификатор приложений, инструменты отчетов об ошибках Windows, WinDbg и т. Д. Но как (запустить) проанализировать сбой приложения Windows CE?

Что я пробовал до сих пор:

• Создание глобальных обработчиков исключений C++ в тактических местах приложения. Они создают и передают простой пакет UDP, содержащий минимальную информацию об исключениях. затем они просматриваются на другой машине с Wireshark.
• Добавление переключателя компилятора исключений SEH (/EHa), чтобы можно было перехватить даже те исключения, не связанные с C++, как Access Violation и тому подобное.
• MSVS сообщает, что подключение отладчика Visual Studio 2008 через TCP/IP к интеллектуальному устройству (успешно подключается к интеллектуальному устройству, но отладчик не видит никаких удаленных процессов. 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 собран с точно таким же компилятором (и / или настройками компилятора).

Answer 1

Принято решение отладки для бедного человека. Теперь отправка значений состояния приложения в файл отображения памяти. Идея заключается в том, что специально созданная вспомогательная программа запускается вдоль основного приложения. Эта программа открывает файл сопоставления памяти и отображает значения, которые она читает из него. И основная программа пишет в него. Если с основным приложением происходит что-то фатальное, вспомогательная программа имеет самую последнюю информацию о состоянии. Поскольку это общая память, это не сильно влияет на производительность. Таким образом нашли раздел программы, где происходит сбой.