Как получить аварийный дамп (или любой полезный отчет о сбое) для конвертированного приложения Windows Store UWP?

Question

Я отправил в Windows 10 Store native Приложение Win32, которое было converted to UWP приложение, используя Project Centennial конвертер. Приложение прошло сертификацию магазина и доступно через частную ссылку (пока я ее тестирую).

При выполнении моих тестов приложение повесило трубку и разбилось один раз. Поэтому я пытался найти любые пригодные для использования аварийные свалки для диагностики проблемы.

Я авторизованы на Windows Dev account, затем пошел к моему Dashboard и достаточно уверены, что приложение показывал одну аварию:

тогда я нажал на него. Новая Health страница показала время, когда авария прошла, рынок и т.д.

Затем на дне я увидел это (материал, который не помог бы мне отлаживать эту проблему.):

Я нажал на синюю ссылку, где он сказал MOAPPLICATION_HANG_, и он открыл окно Failure details. Тогда, если я прокручивается весь путь вниз (прошедшую дату и время попадания графика), я вижу это:

OK. Трассировка стека не совсем то, что я ожидал, но я посмотрю.

Так что, если я нажимаю на stack trace, я получаю это всплывающее:

Тогда, если я нажимаю скачать я получаю крошечный текстовый файл stackTrace.tsv (117 байт), что в буквальном смысле имел в нем:

есть ли способ, чтобы получить функциональный mini-dump .dmp file, который можно использовать в Visual Studio C++ проект для анализа этой аварии с native отладчик?

Answer 1

Вы можете попробовать этот метод для создания файла дампа.

1. Пока вы отлаживаете процесс в Visual Studio, вы можете сохранить файл дампа, когда отладчик остановился при исключении или в точке останова. Выберите Сохраните дамп As, отлаживайте. В Сохранить дамп диалоговое окно, в списке Тип, вы можете выбрать Minidump или Minidump с Heap (по умолчанию).
2. С помощью Just-In-Time Debugging enabled вы можете прикрепить отладчик к аварийному процессу, который работает за пределами отладчика, а затем сохранить файл дампа. См. Attach to Running Processes.
3. Другие методы: create dump file. Более подробную информацию вы можете получить по адресу using Dump files.

Надеюсь, это может быть полезно для вас.

Answer 2

Знаете, я должен, вероятно, отдать должное Microsoft за фактическую реализацию коллекции трассировки стека от сбоев приложения UWP. Я столкнулся с фактическим сбоем в приложении Windows Store Win32/UWP, и вот как я смог использовать его, чтобы найти скрытую ошибку.

Во-первых, когда вы войти в свой dashboard, проверьте листинг приложения и посмотреть, если есть какие-либо сбои:

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

Нажмите ее, что приведет еще одно окно. Прокрутите вниз до Failure Log:

Он покажет вам, когда авария прошла, версия вашего приложения, какое устройство это произошло в (! Что очень приятно), а затем ссылку на стек след. Так нажмите кнопку:

Вот как мои фактические трассировки стеки выглядели в момент аварии. Поскольку компьютер этого человека не имел символов (.pdb файл) с моим исполняемым файлом, все методы в моем приложении отображаются как пустые смещения.

Вот как найти фактическое местонахождение аварии:

Восстановления визуального решения Студии с точной копией разбитых файлов. (Я предполагаю, что вы архивируетесь в release сборке вашего решения вместе с .exe и .pdb файлами перед загрузкой в ​​Windows Store.)

Запустите Visual Studio откройте версию разбитого приложения, переключиться на Release конфигурации и disable builds. (Эта часть важна, потому что в противном случае Visual Studio попытается создать ваш проект, прежде чем вы начнете отлаживать его, что может испортить ваши смещения функций, которые вы получили из трассировки стека!)

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

Запустите отладку (нажмите F5) и дождитесь, пока точка останова ударит. Затем покажите Modules панель (Ctrl + Alt + U) и найдите исполняемый файл и получить его базовый адрес:

В моем случае это было 0xD0000. Затем переключитесь на разборку (Alt + 8) и введите свой базовый адрес + смещение сбоя из трассировки стека выше в баре Address поверх окна разборки.Это мое дело было:

0xD0000+0x1D500 

и нажмите Enter для отображения местоположения в коде. Это покажет вам, где произошел сбой. В моем случае это была эта линия:

Тогда все зависит от ваших навыков отладки. В моем случае это было довольно легко увидеть - индекс nRow был вне пределов. Так что было довольно тривиально исправить эту ошибку.

Опять же, я хочу выразить благодарность Microsoft за предоставление такой функции. Я не знал об ошибке, которую я показал выше, и мне было бы трудно, если бы я пытался обнаружить, что выйдет из строя приложением только после простого отчета конечного пользователя.

PS. Наконец, я думаю, что причина, по которой моя трассировка стека не была собрана в моем первом примере, заключалась в том, что приложение было повешено. Поэтому в этом случае отладочная информация, вероятно, не собирается. (Просто догадайтесь на этот момент.)