Типичные фатальные ошибки (по данным Windows Mobile Watson)
Типичные фатальные ошибки (по данным Windows Mobile Watson)
Я больше чем уверен, что время от времени на вашем телефоне выскакивает вот такое "окошко счастья". Ну, вы знаете, - это окно, где вам говорят, что в приложении возникла ошибка и предлагают отправить отчет в Microsoft. Вы не видели такое окно в телефоне? Что ж, потрясающе, тогда, возможно, оно появлялось на вашем настольном компьютере.
А вот то, что это окно создает Watson, компонент Windows Error Reporting (WER), вы могли и не знать. Если точнее, Watson –это работающая на стороне клиента программа, которая активируется, если на телефоне возникает необработанное исключение. Watson составляет отчет о проблеме (стек вызовов, информация о системе, о переменных и т.д.), уведомляет пользователя о возникшей ошибке (показывает это самое "окошко счастья") и спрашивает, согласен ли пользователь отправить созданный отчет в Microsoft. Если пользователь соглашается, зашифрованный файл отправляется в Microsoft, добавляется в базу данных WER, куда имеют доступ сотрудники службы поддержки и команда разработчиков Microsoft.
Все это, конечно, великолепно, но возникает закономерный вопрос – если вся информация отправляется в Microsoft, какой толк от этих ценных сведений всем остальным разработчикам? Я сотрудничаю командой, которая занимается анализом этих отчетов об ошибках, и мы хотим попробовать поделиться с вами хотя бы некоторой информацией. К сожалению, пока что у нас нет возможности дать непосредственный доступ к отчетам, но зато мы можем прямо в этом блоге обсудить наиболее типичные ошибки кодирования и разработки, которые приводят к сбою ваших приложений. В сегодняшнем вводном посте я кратко рассмотрю три проблемы, отчеты о которых приходят наиболее часто.
Проблема #1. Следите за размером буфера!
Одна из часто возникающих проблем - это попытка приложения извлечь текст из элемента treeview с помощью сообщения TVM_GETITEM. Такой сценарий предполагает, что вызывающий код отвечает за передачу буфера и его размера через структуру TVITEM. Затем функция TV_GetItem(), используя wcsncpy(), копирует объем запрошенного текста в выходной буфер. Фатальные ошибки, отчеты о которых мы получаем, как раз происходят во время выполнения этой операции. Наши исследования проблемы показывают, что, скорее всего, причина ошибки в несоответствии размера выделенного буфера и размера буфера, указанного приложением в структуре TVITEM. Размер буфера должен задаваться в TCHAR'ах, а не в байтах! Этот фрагмент кода показывает причину ошибки:
Проблема #2. И снова про буфер
Другая проблема, которую мы часто наблюдаем, возникает в приложениях, которые пытаются с помощью сообщения LVM_GETCOLUMN извлечь текст из заголовка колонки. Ситуация очень похожа на ту, что мы только что рассмотрели – вызывающий код пытается передать буфер и его размер через структуру LV_COLUMN, затем функция Str_GetPtrW() копирует объем запрошенного текста в выходной буфер, и во время этой операции возникают фатальные ошибки. Еще раз – причина этой ошибки, скорее всего, в несоответствии размера выделенного буфера и размера буфера, указанного приложением в структуре LV_COLUMN. При использовании LV_COLUMN подразумевается, что размер буфера должен быть указан в TCHAR'ах, а не в байтах, в противном случае приложение просто напросто выйдет за пределы буфера.
Проблема #3. NET CF v1.0 – это прошлый век!
Последняя проблема, которую я хочу сегодня рассмотреть, относится к использованию .NET CF. Иногда .NET CF v1.0 приложения инсталлируют MSCOREE1_0.DLL, которая, по сути, есть .NET CF v1.0 runtime. Эта версия больше не поставляется с операционной системой, и не нужно ее устанавливать, когда уже установлена версия .NET CF v2.0. Несмотря на то, что эта проблема гораздо более общего характера, чем две предыдущие, мы очень часто сталкиваемся с ней в отчетах.
Пожалуйста, сообщите нам, помогла ли вам эта информация, и если нет, прокомментируйте, как нам сделать ее более полезной.
Перевод: Светлана Шиблева.
Comments
- Anonymous
June 20, 2009
Наверное, стоит переводить не только статью, но и важные комментарии: http://blogs.msdn.com/windowsmobile/archive/2009/04/20/resolving-common-crashes-seen-in-windows-mobile-watson-data.aspx#9571960 А то в статье и даже на официальном сайте winqual.microsoft.com написано, что доступа к дампам под WM у обычных разработчиков нет, а в комментарии написано, что всё-таки есть.