Опрос
Вы участвуете в программе Windows Insider?
Комментарии
Популярные новости
Обсуждаемые новости

14.08.2009 11:39 | deeper2k

Последние пару дней наша команда была занята исследованием недавнего отчета об ошибке в финальной версии 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. Затем мы приступили в автоматизированным тестам на широком перечне конфигураций, продолжавшимся в течение 2 последующих дней. Мы виделы отчеты, связанные с конкретной аппаратной конфигурацией, поэтому мы подготовили свыше 40 компьютеров на базе того чипсета, с различными вариантами драйверов и прошивок, и снова запустили автоматизированные тесты. Никаких сбоев обнаружено не было (об увеличении потребления памяти мы говорили выше). Поскольку некоторые пользователи говорили о зависаниях, мы провели тесты с оператором и вновь не обнаружили проблем в работе ОС. Мы расширили тестирование, попросив других сотрудников Microsoft по всему миру (знаете, в нашей компании громадное число конфигураций, поскольку офисы находятся в различных уголках мира) провести тесты. Несколько отчетов о сбое упоминали об появлении сбоя при отсутствии виртуальной памяти, но это не могло являться причиной, поскольку эта утилита, как и любая иная программа, требующая памяти больше, чем физически доступно, могла привести к подтормаживаниям и поэтому не рекомендована к использованию (нарушение этих рекомендаций является одной из наиболее распространенных проблем, которые невозможно воспроизвести). Тем, кому интересно, рекомендую ознакомиться со статьей в блоге Марка Руссиновича о файлах подкачки. Несмотря на то, что нам не удалось ничего обнаружить, это вовсе не отрицает возможности существования ошибки, но это является свидетельством того, что шансы наличия ошибки на большинстве используемых систем крайне малы.

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

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

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

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

Стивен Синофски (Steven Sinofsky)


Источник: http://blogs.msdn.com/e7ru
Перевод: deeper2k

Комментарии

Не в сети

Очень логично и здраво. И кстати, никого не удивил тот факт, что эта якобы "утечка памяти" в CHKDSK исчезает после завершения его работы? Насколько я понимаю, утечка памяти предполагает её "утекание" насовсем, до очистки ОЗУ, а не до завершения работы вызвавшей её программы.

14.08.09 12:37
0
Не в сети

мы обращаемся к нашим IHV-партнерам

14.08.09 13:51
0
Не в сети

Забавно. Если, как говорится, это не баг, а фича (с), то почему тогда в висте подобного не наблюдается? Или в chkdsk что-то поменялось?

14.08.09 13:56
0
Не в сети

Спасибо, Стивену за объяснение!

14.08.09 15:46
0
Не в сети

mefin, завуалированный мат = мат. Устное предупреждение.

14.08.09 16:02
0
Не в сети

Sgt.Riggs
http://ru.wikipedia.org/wiki/Утечка_памяти
Грубо говоря нет, не так. Утечка памяти - когда программа во время работы взяла кусок памяти, а потом про него успешно забыла.

14.08.09 19:46
0
Не в сети

Описываю процедуру -

1. Запускаем в Explorer проверку второго жесткого диска с включенными двумя чекбоксами. Наблюдаем рост потребления памяти до 1,7 Гб (из 3 доступных).

2. На третьем этапе проверки/исправления нажимаем Отмена.

3. Наблюдаем не освобождаемую память в течение получаса(!). Надоедает. Перегружаемся.

4. Пытаемся загрузиться в Windows XP (которая была установлена на проверяемом диске). Обнаруживаем повреждения диска, которые не дают загрузить XP.

Больше я проводить такие эксперименты с Win7 не собираюсь, хватит. Пусть MS сначала её доделает.

14.08.09 22:26
0
Не в сети

Обращаю внимание - не из командной строки, а из свойств диска!

14.08.09 22:27
0
Не в сети

SergeSF, предлагаете установить Windows XP? Извините, не собираюсь на это тратить время.

14.08.09 23:19
0
Не в сети

SergeSF, так вот что у меня грохныло все дескрипторы безопастности(ACL). Спасибо з инстркцию.
Кстати с Vista будет такой же эффект.

15.08.09 01:04
0
Не в сети

Да, именно дескрипторы.

15.08.09 12:34
0
Не в сети

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

А Вы живите хоть на альфа-версии Windows 8, дело Ваше.

15.08.09 12:37
0
Не в сети

SergeSF, так а в чем проблема? Вместо того, чтобы здесь разводитьтреп, лучше напишите MS об этой проблеме.

15.08.09 13:23
0
Не в сети

Слово "треп" Вы употребляете, чтобы задеть меня. Это бесполезно.

Зачем мне писать MS и куда собственно я должен это делать? Я уже дважды предлагал свои услуги Microsoft в качестве бета-тестера ОС Windows. C моим 10-летним опытом тестирования продуктов одного мейджора это была бы реальная помощь, а не Ваш треп (touche!

Сейчас у меня хватает возможностей для самореализации, помимо попыток достучаться до Microsoft. Им это не нужно, поймите. Microsoft в сочетании с американским авторским правом - это подразделение госдепа США по выкачиванию денег со всего мира. Такой налог на всех в мире для поддержания падающей экономики.

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

Ну и уж подавно не стоит критику в адрес ОС принимать так близко к сердцу (своему). Вас лично я не знаю и критиковать Вас мне пока не за что.
Успехов!

15.08.09 14:21
0
Не в сети

Впрочем, не счёл за труд и в комментах блога e7 запостил баг. Посмотрим, got SS the balls или нет.

15.08.09 15:05
0
Не в сети

Столько шума вокруг бага...

15.08.09 16:29
0
Не в сети

Слово "треп" Вы употребляете, чтобы задеть меня. Это бесполезно.


Ни в коем разе.

Ну и уж подавно не стоит критику в адрес ОС принимать так близко к сердцу (своему).


Вам наверное показалось. Критика MS меня ничуть не ранит


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


Возможно. С другой стороны, деньги у них отбирает ЕК и антимонопольный комитет :;)

15.08.09 18:27
0
Не в сети

SergeSF , раз вам(тебе) не удалось достучаться до MS, значит вы(ты) выбрал(и) неправильную тактику.
Надо идти не со стороны Windows, а со стороны бизнес-приложений и небольших программ. Сейчас, например, можно протестировать MSE. Просто так в Windows-программу попадают только иностранцы, да люди со статусами(MSP,MVP, MCT & ect).
Касательно данного бага: я его между прочим постировал в одном из бета-форумов. Именно по такому сценарию как вы(ты) описал(и). Вероятней всего они знают об этой проблеме, но решить её пока не могут. Поэтому проще сказать, что проблемы нет, чем решить её. Об этом, кстати, свидетельствует и то, что существует 2 различные точки зрения на данную проблему:
1. Баг является поблемой драйвкров, а не самой ОС.
2. Повышенное потребление ОЗУ для chkdsk /r является нормальным процессом.
Я думаю, что они решат эту проблему, но не оффициально. Просто выпустят заплатку внутри какого-нибудь критичного обновления, которое с данной проблемой вообще никак не будет связанно.
PS. C 10-летним опытом тестирования надо уже в саму MS работать устраиваться, а не с тестированием через MS Connect заморачиваться. Ей богу от этого будет больше выгоды.

16.08.09 15:23
0
Не в сети

SergeSF, rкстати вам всем (тем кто хочет сообщать о багах в RTM-ерсиях) уже дали совет как это сделать: послать сценарий через e-mail форму блога. Так что дерзай.

16.08.09 15:28
0
Не в сети

Мне? Достучаться до Microsoft?? Чтобы они справили свои же ошибки??? Это не мне, это им нужно! Это их проблема, их ПО, пусть они пытаются до меня достучаться. Я всего лишь сторонний наблюдатель за их агонией последних лет.

Работа с файловой системой, дисковыми устройствами - это БАЗОВАЯ, основная задача ОС, если Вы позабыли. Собственно потребность в ОС поэтому и возникла. ОС=файловая система. Вы всезьез считаете, что такая ошибка - это нормально?

Моя задача здесь - показать Вам, как Вас кидают. А работают на Microsoft пусть те, кто в этом нуждается.

16.08.09 16:44
0
Не в сети

SergeSF , no comments. Научитесь сначала читать, что пишут другие, а уже потом критиковать.
Кстати показывть здесь никто ничего не просил.

16.08.09 19:40
0
Не в сети

А по существу сказать нечего. Как всегда.

16.08.09 20:52
0
Не в сети

По существу уже всё давно сказано.

17.08.09 03:01
0
Не в сети

SergeSF, так а делать-то, переходить на Linux? К тому же, от ошибок никто не застрахован.

17.08.09 13:01
0
Не в сети

Делать то, что считаете нужным.

Мне, например, WinXP хватает для любых целей.

17.08.09 19:00
0
Для возможности комментировать войдите в 1 клик через

По теме

Акции MSFT
420.55 0.00
Акции торгуются с 17:30 до 00:00 по Москве
Все права принадлежат © ms insider @thevista.ru, 2022
Сайт является источником уникальной информации о семействе операционных систем Windows и других продуктах Microsoft. Перепечатка материалов возможна только с разрешения редакции.
Работает на WMS 2.34 (Страница создана за 0.047 секунд (Общее время SQL: 0.021 секунд - SQL запросов: 123 - Среднее время SQL: 0.00017 секунд))
Top.Mail.Ru