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

У нас есть неуправляемое приложение 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 собран с точно таким же компилятором (и / или настройками компилятора).

-3

Решение

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

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]