Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Типичные фатальные ошибки (по данным 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 у обычных разработчиков нет, а в комментарии написано, что всё-таки есть.