Что происходит с отчетами об ошибках?
Последние пару дней наша команда была занята исследованием недавнего отчета об ошибке в финальной версии Windows 7. Подробности самой проблемы не столь важны, сколько важно то, каким образом мы будет решать подобные проблемы в будущем. Думаю, что это очень удачный случай рассказать об этом процессе и проиллюстрировать его.
Неделей ранее в сети появилась информация об ошибке в Windows 7. Для того, чтобы воспроизвести ошибку, требуется выполнить нехитрую процедуру:
1) выполнить в командной строке операцию chkdsk /r для любого несистемного диска.
В связи с тем, что воспроизвести проблему не составляет труда, информация о ней быстро расползлась по сети. Последующие публикации и комментарии к ним показали, что эта проблема проявилась у многих, при этом проблема проявлялась у пользователей в двух видах: a) потреблении большого количества памяти и б) аварийном завершении работы Windows Explorer.
Практически мгновенно я начал получать массу писем, связанных с этой проблемой. Как и многие из вас, первое, что я попытался сделать – попробовал воспроизвести ситуацию. И хотя рост потребления памяти имел место, проблема не проявилась ни в одной из своих ипостасей. Я попробовал еще на одном компьютере и снова проблема никак себя не проявила. В обоих случаях, компьютеры работали, как и положено до и после запуска команды chkdsk. Для начала я ответил на большую часть входящей почты и приступил к опросу пользователей на предмет того, как они воспроизвели ошибку, а также просил прислать дамп памяти. Потребление памяти меня волновало не столь сильно, сколько аварийное завершение работы. Письма продолжали поступать, однако, ни дампов, с которыми мы смогли бы поработать, ни более подробных описаний я так и не получил.
Как вы, наверное, догадались, я был не первым в Microsoft, кто увидел это сообщение. Команда File System незамедлительно приступила к расследованию проблемы. Однако, им тоже не удалось выявить аварийное завершение работы. Что касается растущего потребления памяти, то, по их мнению, так и было задумано (флаг /r осуществляет блокировку и восстанавливает диск, поэтому мы думали, что перед тем, как приступить к выполнению работы, необходимо восстановить поврежденные секторы – некоторые авторы нашумевших статей в результате тоже пришли к такому выводу). Мы решили подробнее изучить дампы и отчеты. Как сказано выше, в нашем распоряжении имеется достаточное количество необходимых инструментов.
По мере нашего расследования я продолжал отвечать на непрекращающийся поток писем. Автор одного из них сослался на нашу переписку в блоге. Поэтому мое желание вести нормальный диалог через электронную почту вылился в глобальное обсуждение. Повторив ставшую уже привычной для меня операцию, я добавил комментарий к оригинальной публикации в блоге (именно там мой собеседник сослался на нашу переписку), подробно описав предпринятые шаги и рассказав все, о чем мы знали. Забавно, что мой комментарий привлек к проблеме еще больше внимания. Мне, должен сказать, нравится быть частью сообщества и участвовать в обсуждении лично, хотя порой это может стать причиной неразберихи.
Следует отдельно рассказать о том, что происходит, когда мы получаем отчет об аварийном завершении работы. Давным давно мы обходились всего двумя вариантами: 1) поднять руки и сдаться, если потеряна надежда отыскать причину ошибки или 2) приостановить работу и отправить сотрудников с терминальными отладчиками к пользователям в надежде найти воспроизводимый случай. Ни один из этих вариантов не эффективен, а второй к тому же, как бы героически это ни звучало, не приносит ожидаемых результатов. Даже если сбой имел место, мы не могли определить, был ли это единичный случай или с проблемой сталкивались многие. Нам приходилось принимать решения, не имея нужной информации.
С распространением Интернета и появлением телеметрии (не только в Windows 7) сегодня мы имеем достаточно четкое представление о состоянии наших продуктов. Когда мы впервые слышим об аварийном завершении работы, то проверяем, не зарегистрирован ли подобный сбой на миллионах других компьютеров. Это позволяет собрать статистику, но совершенно бесполезно, если сбой имеет место в одной конкретной конфигурации. Однако, сбой в данной конфигурации, проявившийся на статистически релевантной выборке, является поводом задуматься. Мы, к примеру, можем проверить все стеки вызовов, чтобы понять, была ли в момент сбоя в памяти та или иная программа.
В случае, если зафиксирован сбой, в нашем распоряжении есть множество инструментов. Вы могли видеть их работу в случае сбоя. Мы можем увеличить количество необходимых данных. Мы можем разместить статью в базе знаний в качестве ответа на конкретную ошибку (и вы будете уведомлены об этом через Windows 7 Action Center). Мы можем даже сказать «эй, позвоните нам». Как бы странно это не звучало, в большинстве случаев это помогает. Если же обнаружена ошибка в уже завершенном продукте, тогда ситуация меняется – причиной ошибки может быть новое устройство, новый драйвер или иной программный продукт. Как правило, обычное подтверждение изменений помогает нам диагностировать проблему. Помню, как однажды у многих пользователей Word стал завершать работу с ошибкой. Мы ничего не меняли. Оказалось, что была выпущена новая версия популярного дополнения и именно она стала причиной сбоя, но пользователи винили в ошибке Word. Мы быстро опубликовали инструкции по удалению дополнения и начали работу с его авторами над исправлением. Это умение видеть меняющееся окружение, диагностировать и отвечать на проблему кардинальным образом изменило наш подход к устранению ошибок в продукте.
Мы непрерывно изучаем новые и часто повторяющиеся проблемы (включая сбои, зависания, неудавшиеся установки, потенциальные уязвимости и т.д.). На самом деле, в течение каждого месяца обрабатываются сотни отзывов, получаемых от корпоративных клиентов и OEM-партнеров (и IHV, и ISV). Мы часто видим, что проблемы решаются изменениями вне ядра Windows (например, в драйверах, прошивках или приложениях). Мы не перекладываем ответственность и помогаем компаниям устранять причины ошибок. Мы также вносим многочисленные изменения в код Windows, выпуская ежемесячные обновления, заплаты и пакеты сервисных обновлений. Львиная доля изменений неприменима ко всем компьютерам, поэтому мы не торопимся с их распространением. Однако если проблема носит массовый характер, мы стремимся распространить обновление как можно скорее. Очень важно понимать, со сколь серьезной ответственностью мы подходим к вопросу обеспечения комфортной работы основной массы пользователей, стараясь сбалансировать объем изменений, применимых для этих пользователей.
Для того чтобы вернуться к разговору об утилите chkdsk, давайте окунемся в события, произошедшие за последние пару дней в нашем подразделении. Для начала мы скрупулезно просмотрели данные телеметрии на наличие информации о сбоях (на уровне пользователей и «синих экранов») и не обнаружили ни одного сбоя, вызванного утилитой chkdsk. Мы также внимательно изучили существующие отчеты, собранные в ходе разработки Windows 7, но и здесь не обнаружили ничего похожего. Мы изучили стеки вызовов в существующих отчетах об ошибках (различных ошибок, зафиксированных с момента появления информации об этой) и не обнаружили ни одного сбоя, произошедшего в тот момент, когда была запущена утилита chkdsk.exe. Затем мы приступили к автоматизированным тестам на широком перечне конфигураций, продолжавшимся в течение двух последующих дней. Мы видели отчеты, связанные с конкретной аппаратной конфигурацией, поэтому подготовили свыше сорока компьютеров на базе проблемного набора микросхем с различными вариантами драйверов и прошивок, и снова запустили автоматизированные тесты. Никаких сбоев обнаружено не было (об увеличении потребления памяти мы говорили выше). Поскольку некоторые пользователи говорили о зависаниях, мы провели тесты с оператором и вновь не обнаружили проблем в работе ОС. Мы расширили тестирование, попросив других сотрудников Microsoft по всему миру (знаете, в нашей компании громадное число конфигураций, поскольку офисы находятся в различных уголках мира) провести тесты. В нескольких отчетах упоминалось о появлении сбоя при дефиците виртуальной памяти, но это не могло являться причиной сбоя, поскольку chkdsk, как и любая иная программа, требующая памяти больше, чем физически доступно, могла привести к подтормаживаниям и поэтому не рекомендована к использованию (нарушение этих рекомендаций является одной из наиболее распространенных проблем, которые невозможно воспроизвести). Тем, кому интересно, рекомендую ознакомиться со статьей в блоге Марка Руссиновича о файлах подкачки. Несмотря на то, что нам не удалось ничего обнаружить, это вовсе не отрицает возможности существования ошибки, но является свидетельством того, что шансы ее проявления на большинстве используемых систем крайне малы.
Тем временем, мы продолжаем следить за внешними блогами, форумами и иными источниками собирая информацию о подобных сбоях, чтобы попробовать воспроизвести их. И хотя у нас нет возможности контактировать с каждым, мы обращаемся к пользователям, если видим, что обсуждение может привести к требуемому результату. Пока же видно много дыма, а мы все еще пытаемся отыскать огонь. Публикуется громадное число комментариев по поводу уровня критичности ошибки, но никто из их авторов не смог описать сценарий сбоя или предоставить дамп памяти.
Подобная работа продолжается до тех пор, покуда мы не добьемся систематического сбоя или не выявим обстоятельств, при которых этот сбой происходит. В связи с тем, что сбой может быть связан как с программной, так и с аппаратной составляющей, мы обращаемся к нашим IHV-партнерам. В данном случае ошибка связана с жестким диском и нельзя исключить, что ее причиной является именно он. И несмотря на то, что мы разрабатываем ОС так, чтобы избежать подобных ошибок, все-таки есть вероятность, что данный конкретный тип ошибки обрабатывается недостаточно хорошо. На самом деле, в наших лабораториях, в которых мы выполняем тесты в течение нескольких дней, был зафиксирован один сбой, и его причиной стала ошибка в прошивке контроллера диска.
Мне хотелось лишний раз подчеркнуть, насколько серьезно мы подходим к решению таких проблем. Когда я вижу в сети громкие заявления о критических ошибках, это привлекает мое внимание, но это нисколько не помогает в проведении конструктивного и рационального анализа. Крупные программные проекты по своей природы крайне сложны. В них всегда присутствуют проблемы, зависящие от среды и конфигурации. И, как мы убедились, иногда ту или иную проблему просто невозможно воспроизвести. Для изучения подобного типа отчетов у нас предусмотрена четкая процедура, которая позволяет обеспечивать здоровое состояние Windows в условиях непрерывного меняющегося окружения. Эта статья была написана чтобы рассказать не столько о конкретной проблеме, сколько о принятой в компании процедуре изучения подобных ситуаций.
Всегда здорово найти ошибку в программном продукте. Независимо от того, банкомат это, аппарат для продажи билетов или Windows – все мы ощущаем некую гордость за то, что обнаружили, что что-то работает не так, как предполагается. Windows является плодом труда огромного количества людей и не только сотрудников Microsoft. Когда что-то работает не так, как ожидается, мы активизируем работу с широчайшим спектром партнеров над тем, чтобы устранить эту проблему. Надеюсь, что вы осознали всю ту серьезность и ответственность, с которой мы подходим к решению проблем. В будущем мы продолжим пристально следить за отзывами и, при необходимости, будем вносить изменения в код, чтобы обеспечить уровень качества, который пользователи ждут от Windows.
Стивен Синофски (Steven Sinofsky)
Comments
Anonymous
February 26, 2011
Очень интересно ) http://my-seven.ruAnonymous
March 25, 2014
Очень хорошая статья. килограмм воды лишь бы не обращать внимания в корень. Искать несуществующие ошибки, которых и нет на целом зверинце компьютеров упорно не замечая сути проблемы. Вы не думайте о сложных стеках и дампах ошибок, вы подумайте вот о чём: МАЛЕНЬКАЯ ШТАТНАЯ УТИЛИТКА ПРОВОДИТ ПРОСТУЮ ПРОВЕРКУ ДИСКА СО СКАНИРОВАНИЕМ СЕКТОРОВ И СЪЕДАЕТ ВСЮ ВОЗМОЖНУЮ ОПЕРАТИВНУЮ ПАМЯТЬ, да так что свободная память заканчивается, система начинает сильно подкачиваться и тормозить, о чем даже вылезают предупреждения о нехватке памяти. Может быть этой программке нужно обрабатывать в оперативной памяти огромные объёмы данных как например SQL-базу данных или здоровый фотошоп-проект? Да, ошибок нет, но из вашей замечательной статьи можно уловить идею что всё якобы нормально. Ситуацию может воспроизвести у себя ЛЮБОЙ. прошу вам на рассмотрение очередной скрин: s2.hostingkartinok.com/.../a4b9319cc10ab96aeda9eae050bb8605.png Посмотрите на этот скрин, ну или посмотрите это видео: www.youtube.com/watch и честно, положа руку на сердце, скажите при всех чтобы люди это увидели - ЭТО НОРМАЛЬНАЯ СИТУАЦИЯ? Ну или если уж вы так любите техническую терминологию - просто объясните НА ЧТО ИМЕННО расходуются тонны оперативной памяти утилиткой chkdsk?
