Как интерпретировать трассировку стека

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

Информация:

Problem function: unknown //not very useful
Exception type: c0000005 //this is the code for Access violation exception
Stack trace: 
Frame    Image        Function      Offset 
0        qcdx9um8960                0x00035426 
1        qcdx9um8960                0x000227e2

Я не привык работать с указателем памяти и similia, и я не привык видеть трассировку стека.

Итак, у меня есть вопрос:

Как я должен интерпретировать/читать эту информацию, какой смысл каждой части информации?
Есть ли способ использовать эту информацию для поиска моей проблемы?
~~Есть ли способ получить эту информацию при отладке в VS2012~~

Примечания:

Я не спрашиваю, что такое нарушение доступа.
Я отметил это как С# и С++, потому что мой код находится в С#, но генерируется исключение (я полууклоняюсь) с помощью реализации С++ для компонента WebBrowser

изменить:

Я попробовал установить тип Debug только для Native, это позволило мне получить ту же информацию, что и в отчете о сбое в центре dev. Таким образом, отладчик прерывается, когда генерируется исключение, и дайте мне увидеть дизассемблированный код, к сожалению, нет файла qcdx9um8960.pdb(даже на Microsoft Symbol Server), поэтому я не знаю имя функции, вызвавшего ошибку.

Ответ 1

Любопытно, что поиск в Интернете для имени изображения "qcdx9um8960" возвращает несколько результатов, ссылающихся на Windows Phone 8 и элемент управления WebBrowser. Собирая ответы и ответы (некоторые даже с помощью MSFT), вот что вам следует изучить:

Если вы обновили приложение с Windows Phone 6/7 до 8, убедитесь, что вы еще не ссылаетесь на любые 6/7 DLL. ¹
Убедитесь, что вы не тестируете или не публикуете свое программное обеспечение в режиме отладки. Существует файл "qcdx9um8960.pdb", который может отсутствовать, что приводит к нарушению доступа. ¹
"... существует известная проблема возможного состояния гонки, если приложение имеет несколько экземпляров WebBrowser. Посмотрите, может ли ваш код непреднамеренно создавать более одного экземпляра". ¹
Этот образ "qcdx9um8960" ссылается на DLL-драйвер Qualcomm DirectX. Возможно, это не ошибка компонента WebBrowser, а драйвер DirectX, который он может использовать для рендеринга веб-страниц. ²
Название изображения указывает на то, что авария происходит на устройствах, работающих на Qualcomm Snapdragon S4 Plus с номером модели MSM8960. ³
Предполагая, что процессор выше, и перекрестные ссылки на телефоны Windows, использующие этот чип, вы, вероятно, смотрите на проблему, возникающую на Nokia Lumia 920T. ³ Это не означает, что драйвер не работает на нескольких процессорных архитектурах или телефонах.

Есть несколько других обращений о сбоях и проблемах при отладке в присутствии этой DLL, поэтому, к сожалению, для вас, я думаю, вы можете быть во власти некоторых сторонних программ, у которых есть несколько нерешенных проблем.

Ссылки

¹Нарушение доступа с обновления до WP8

²[Toolkit] [WP8] Проблемы с производительностью с DepthStencilBuffer

³Snapdragon (система на чипе)

Ответ 2

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

Итак, сначала вы должны сосредоточиться на получении (справедливого) надежного сценария воспроизведения: минимальный набор шагов, которые (часто или обычно) приводят к сбою. Это может быть связано с опросом пользователей, которые столкнулись с крахом, или, может быть, с некоторой автоматизацией тестирования с вашей стороны, чтобы ускорить скорость отказа.

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