Как называется окно ошибки

Здесь вы не увидите ни строчки кода. Мы поговорим об обычных людях — о наших пользователях, точнее о том, как сообщать им, если в системе возникла какая-то непредвиденная ситуация.

В основе статьи доклад Антонины Хисаметдиновой с Heisenbug 2017 Moscow, которая занимается проектировкой пользовательских интерфейсов в компании Собака Павлова.

Кроме того, на Медиуме есть цикл статей «Руководство по проектированию ошибок». Цикл еще не дописан до конца, но дает более полную и цельную картину по теме статьи.

Ошибочный сценарий

Раз за разом мы проектируем основные сценарии самых разнообразных сервисов. В случае интернет-магазина основной будет таким:

Человек заходит на сайт, выбирает товар, заказывает его доставку; оплачивает и получает заказ.

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

Всё это — ошибочные сценарии, возникающие, когда что-то идет не так.

Продуктовые команды часто не уделяют достаточно внимания таким сценариям. Например, очень типичная история: «Что-то пошло не так. У нас проблемы, поэтому просто закройте это сообщение».

Еще пример: «У нас ошибка. Повторите вашу попытку позже»:

И еще одна категория ошибок — моя любимая: неизвестные ошибки.

Зачем работать над ошибочными сценариями?

Обосновать бизнесу необходимость проработки ошибочных сценариев бывает очень сложно. Зачем нам возвращаться назад и что-то исправлять, когда впереди у нас новые фичи? Но у меня есть четыре железных аргумента, которые помогут продемонстрировать вашему product owner’у или бизнесу необходимость такой работы.

Хорошее сообщение об ошибке снижает нагрузку на техническую поддержку и персонал

На слайде представлены некоторые цифры одного из наших клиентов. Это количество звонков пользователей в техподдержку в месяц. Звонки связаны с проблемами определенного рода:

Обратите внимание, 400 человек в месяц звонят просто из-за того, что не могут войти или корректно ввести логин / пароль в соответствующей форме на сайте.

Хорошее сообщение об ошибке помогает пользователю не потеряться в воронке конверсии

Если сообщение об ошибке составлено грамотно, оно возвращает его к основному сценарию, даже если произошел разрыв сессии.

Хорошее сообщение об ошибке обучает работе с сервисом

Возможно, вам даже не потребуется создавать onboarding или какие-то обучающие видео, разработка которых, кстати говоря, тоже стоит приличных денег.

Хорошее сообщение об ошибке позволяет сохранить доверие к сервису в трудную минуту

Это последний, но немаловажный аргумент.

Вообще тема доверия «человек-технология» исследуется довольно давно. Сейчас мы уже достаточно доверяем технологиям. Например, мы никогда не будем перепроверять, отправил ли мессенджер сообщение адресату, или как калькулятор сложил или умножил трехзначные числа (к сожалению, правда, не все сервисы могут похвастаться таким уровнем доверия, как калькуляторы).

Мы доверяем свою жизнь десяткам видов разного программного обеспечения, летая в самолетах. Но это доверие очень легко разрушить. Сделать это может даже самая маленькая ошибка. И такие ошибки случаются как в маленьких, так и в очень больших компаниях.

Из-за чего возникают ошибки

Я несколько раз упомянула «хорошее сообщение об ошибке». Настала пора поговорить о том, что это значит. И для начала разберемся, из-за чего в принципе возникают ошибки.

• первое, что приходит в голову, это какие-то глобальные сбои или технические работы на сервисе;
• специфические баги;
• ошибки пользователя.

Но это далеко не всё. Еще есть:

• проблемы на стороне подключенных сервисов;
• внешние проблемы;
• крайне необычное поведение пользователей или сервиса.

Это не попытка классификации. На самом деле видов ошибок далеко не шесть, их может быть сотня или даже больше. Но в контексте проектирования интерфейсов эти ошибки самые значимые.

Глобальные сбои

Давайте начнем с ситуации, когда ваш сервис полностью недоступен.

К сожалению, такие ошибки могут возникнуть в любых сервисах, от онлайн игр до сложных биржевых профессиональных инструментов.

Хороший вопрос: что в такой ситуации делать?

Пока разработчики спешно чинят какие-то инструменты, несчастные пользователи получают странные сообщения об ошибках и достают вашу техподдержку, пишут неприятные посты в твиттере:

Давайте посмотрим на сообщения, которые в этот момент выводятся:

Они достаточно простые и некоторые из них даже честно извиняются. Но пользователи все равно чувствуют себя некомфортно и пытаются понять, в чем же дело; повторяют вход далеко не через 15 минут; тыкают, куда попало.

Как им помочь?

Подумайте о последствиях

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

Многие в таких ситуациях ограничиваются сообщением: да, у нас есть проблема и мы скоро ее поправим:

Но «скоро» — это когда?

Пользователю не нужно знать, когда вы всё поправите, с точностью до минуты. Но им нужно понимать какие-то значимые временные ориентиры, например, 15 минут, один час, пять часов или даже сутки. Это поможет им сориентироваться в пространстве и спланировать управление своими деньгами.

Еще один резонный вопрос (в ракурсе финансового сервиса): работают ли карточки?

И хорошее сообщение об ошибке сможет на него ответить. Даже если карточки не работают, лучше всё равно об этом сказать, потому что это очень важная информация.

Еще одна история — тут зарплата или перевод должны быть; а когда придут эти деньги?

Вроде бы ничего критичного, но когда человек не может проверить баланс, он начинает сильно паниковать. Поэтому предложите проверить баланс альтернативными методами, если это, конечно, возможно.

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

Важно понимать, что глобальный сбой — это проблема ваша, а не пользователя. Не нужно перекладывать на него мыслительные процессы. Предложите сразу готовые варианты.

Предупредите заранее

Не все пользователи готовы зайти в личный кабинет прямо сейчас, и далеко не все пользователи в принципе зайдут и заметят ошибку. Но если вы предупредите их заранее (например, постом в Twitter, SMS-сообщением или по электронной почте), то когда они столкнутся с сообщением об ошибке, будут готовы.

Отдельно стоит сказать про профессиональные сервисы, от которых ежедневно зависит работа пользователей. Например, сервис Антиплагиат иногда выводит такое сообщение о проведении технических работ:

Обратите внимание, что указана точная дата и точный диапазон времени — это поможет пользователю спланировать свою работу в вашем сервисе.

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

Однако если же мы говорим о профессиональных инструментах, от которых пользователь реально зависит каждый день с утра и до вечера, очень странно не предупредить о проблеме (а частота, с которой допустимо сообщать пользователю о проблемах, при этом сильно зависит от отрасли).

Специфические баги

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

Для нас баги — это знакомая история. Мы четко классифицируем их по разным параметрам: степени опасности, необходимости исправления и т.п.

Но пользователи когда замечают баг, в принципе не понимают, с чем они столкнулись. Многие даже не знают этого термина. Для них баги на самом деле выглядят вот так:

Мы предполагаем, что если пользователь вдруг заметил что-то странное, он конечно же нам об этом сообщит. У него есть для этого пять или даже больше способов:

• раздел «Контакты» и обратная связь;
• онлайн-консультант и звонок в техподдержку;
• социальные сети и чаты компании;
• отзывы (App Store и Play Market)!!!
• блоги и форумы.

Мы предполагаем, что пользователь когда-нибудь проскролит страницу вниз до подвала, найдет там вкладку «Контакты». В разделе контактов найдет среди карт, отделов, офисов продаж и прочего маленькую кнопочку «Обратная связь», нажмет на нее, выберет тему обращения. Напишет подробное письмо о том, как воспроизвести эту ошибку, приложит скриншоты и отправит.
Да, действительно, такие письма приходят. Но если ошибка очень плохая, человек может сразу оставить отзыв с низкой оценкой на App Store, где также подробно распишет, чем ему ваш сервис не нравится.

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

Или могут вообще перестать пользоваться вашим сервисом, как неработающим.
Поэтому в багтрекере ВКонтакте висит такой вот тикет, который называется «отсутствие кнопки «Сообщить о баге»»:

Действительно, это проблема очень многих сервисов.

Создайте специальные окна для сбора обратной связи

Но есть и позитивные примеры, например, Semrush. Почти по всему сервису размещены специальные окна, которые нацелены на то, чтобы забирать фидбэк от человека.

В такой ситуации пользователю стоит меньших усилий написать вам о какой-то ошибке или о фидбеке. Особенно это актуально для бета-тестирования.

Если нельзя исправить баг быстро, предупредите о нем

К сожалению, бывают такие ситуации, когда вы не можете исправить баг быстро. Можно просто предупредить об этом пользователя — как и в предыдущей части доклада.

В качестве примера здесь приведен скриншот, когда с помощью совершенно обычных окошек разработчики иконочного шрифта material design предупреждают пользователей, что есть проблема совместимости, и приносят свои извинения:

Обратите внимание, что они приводят ссылку для тех, у кого возникли эти проблемы. По ссылке инструкция, как всё исправить.

Самое главное, что нужно запомнить про специфические баги, — это необходимость качественного фидбэка. Поэтому создавайте специальные окна, чтобы как можно быстрее получать от пользователей эту информацию. Ну и второе — конечно, предупреждайте, если вам какой-то баг известен, но вы не можете его поправить.

Ошибки пользователей

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

Первый пример узкого места многих сервисов — это, конечно, вход / регистрация:

Например, поле входа в InVision. Маленькая красная полосочка — это, в принципе, всё сообщение об ошибке. Наверное, когда дизайнер его рисовал, думал, что пользователь без труда прочитает сообщение: «Упс, комбинация email и пароля не верна». Проверит сначала email, затем пароль, и снова нажмет кнопочку войти. Но статистика подсказывает, что пользователь делает несколько попыток входа и ввода пароля, прежде чем догадывается, что проблема в email-адресе.

Это происходит, потому что внимание пользователя в момент входа сосредоточено в одной очень узкой области — она называется фокусом внимания:

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

Фишка 1. Разместите сообщение в фокусе внимания

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

Фишка 2. Показывайте, где именно ошибка

Подсвечивание обоих полей — это и есть вторая фишка.
Но и это не всегда помогает.

Например, дизайнеры компании Adobe считают, что пользователи действительно это всё читают:

Еще один классический пример предлагает Xiaomi:

Или, например, сайт Госуслуги (как и многие другие) просто дублирует название поля заголовка в ошибку:

Фишка 3. Используйте понятные и короткие формулировки

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

Но в окружении интерфейса и текущих задач у пользователей это выглядит вот так:

И они не дочитывают до конца. Когда пользователь читает строку, он фокусируется на начале строки. А чтобы прочитать дальше, ему надо приложить усилия:

Ему неохота читать ваши тексты, он хочет дальше решать свои задачи.
Поэтому, сокращая формулировку и размещая сообщение в зоне фокусировки, мы можем быстрее донести смысл.

Фишка 4. Подскажите, как исправить ошибку

Кто сталкивался с кассами самообслуживания?

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

В чем была проблема? Пользователи забывают положить маленькие товары на другую сторону. Поэтому разработчики добавили звуковой сигнал, после чего в 90% таких ситуаций покупатели стали обходиться без помощника. Сигнал заставлял человека поднимать глаза на экран кассы и выходить из состояния, когда он сканирует свою огромную корзину покупок: «Точно, я не положил воду».

У этого сообщения об ошибке есть две из перечисленных «фишек»: оно подсказывает, где именно ошибка, и обучает работе с сервисом.

Фишка 5. Сохраняйте работу пользователя

Последнее, но самое интересное.

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

Чтобы вообще начать пользоваться финансовым сервисом Revolut, я должна сначала подтвердить свой номер телефона. Обратите внимание, они уже автоматически определили и подставили код страны. Спасибо ребятам.

Дальше я должна ввести свое имя и фамилию. Ну раз они определили мою страну, то я начинаю вводить автоматически по-русски, и когда я уже нажимаю «Далее», заполнив всю форму, сервис мне говорит: «Пожалуйста, используйте латинские буквы». Автоматическая валидация уже давно всем известна, и ее нужно обязательно применять! Но на этом дело не заканчивается. Мне нужно заполнить адресную информацию, причем, обратите внимание, страна уже подставлена автоматически и написана кириллицей.

Но меня не обманешь — я ввожу адрес латиницей, нажимаю Continue. И, как вы думаете, что происходит?

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

Поэтому не заставляйте пользователя вводить какие-то поля заново, используйте как можно больше автоматизации.

Проблемы подключенного сервиса

Тестируйте API подключенных сервисов

На днях мне попался интересный отчет на сайте APIFortress. Там был рассказ про компанию, которая поставляла стоковые изображение своим партнерам. Одним из них было агентство, которое занималось сувениркой с мопсами.

Однажды этот мопс-партнер позвонил в стоковую компанию и пожаловался на поломку сервиса.

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

Учите их различать проблемы

Иногда недостаточно просто знать, что где-то там у вас проблема, потому что пользователи будут видеть странные окна, которые не будут им помогать:

И в интерфейсе эту проблему не решить.

Поэтому очень важно потратить усилия, чтобы научить ваш сервис различать причины проблем с API.

Предусмотрите в интерфейсе оповещение о проблемах

Очень хороший пример — сервис-автоматизатор ifthisthenthat. С помощью связок API различных сервисов (например, умного дома или социальных сетей) они заставляют сторонние сервисы делать определенные вещи. Например, если я опубликовала пост в Instagram, он автоматически уходит в мой Facebook. Или, если я вышла из дома, сервис определяет по моей геопозиции, что я нахожусь в офисе, и проверяет, выключила ли я все свои смарт-утюги. А если не выключила, то выключает.

Эти ребята проделали очень большую работу, и не только в интерфейсе.

Во-первых, они выделяют отдельную вкладку для ошибок. Все неудавшиеся операции собираются в этот лог.

Они определяют разные типы ошибок:

В первом случае — сервис Instagram офлайн, и мы понимаем, в чем проблема. Возможно, мы временно вышли из зоны действия сети.

В случае, если пользователь никак не может поспособствовать решению проблемы, выводится просто оповещение.

Внешние проблемы

Что такое внешние проблемы в моем пользовательском понимании?

Весь software завязан на аппаратуру, на датчики и т.п. Всё это тоже создано людьми и может не работать. Поэтому очень важно сообщать об этом пользователю. Хороший сервис может сообщать о таких ошибках, как о своих.

Дайте понять, какие действия в вашем сервисе недоступны из-за внешних проблем

Хороший пример — отсутствие интернет-соединения в коммуникаторе Slack. Если во время работы у меня отвалился интернет, я вижу вот такое сообщение сверху:

Как мы помним про сообщения об ошибках пользователей, в момент ввода какого-то текста пользователь сконцентрирован в этой области:

Slack об этом не забывает и подсвечивает поле желтеньким.

При этом он не блокирует мне набор сообщения. Я могу продолжить писать его дальше, но при попытке отправить Slack-бот отправляет мне вот такое сообщение:

И в принципе очень доступно объясняет, с чем именно проблема. Такую ошибку я замечу достаточно быстро.

Большая проблема с внешними ошибками, которая пришла к нам еще из «древних» времен, когда продукты создавались инженерами для инженеров, — это содержание текстов об ошибках:

Они написаны таким языком, как будто мы сейчас до сих пор подразумеваем, что пользователь знает, что такое firewall, ftp, dll, ядро, kernel и так далее.

Четко разделите уровни компетенции

Техническому специалисту мы показываем одну информацию, а пользователю — другую.

Наверное, стоит отдельно сказать про то, как люди в принципе общаются с техподдержкой.

Для многих это действительно большой стресс. Большая часть сообщений об ошибках совершенно не подразумевает, что они должны быть поняты. Человек, который даже не знает английского языка, пытается как-то объяснить: у меня там что-то сломалось. Он испытывает очень сильный дискомфорт. И всё это влияет в целом на его опыт общения с вашим сервисом. Поэтому старайтесь создавать такие сообщения, которые пользователь сможет осознать и своими словами передать техподдержке.

Например, это фото 3D-принтера, который четко и ясно (с помощью маленького экранчика) говорит, что температурный сенсор испортился — произошла ошибка, поэтому он остановился. Свяжитесь с техподдержкой. Пользователь легко может понять, в чем дело, и для него не сложно описать эту проблему своими словами без технических терминов:

Помогите пользователю оценить приоритет проблемы

Что это значит?

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

В такой ситуации пользователь не понимает, что делать. Некоторые водители-новички вместо того, чтобы прочитать инструкцию, просто продолжают ездить, думая, что всё в порядке. А у других, наоборот, начинается паника — они пытаются вызвать эвакуатор.

А есть еще такая категория: «У меня там до зарплаты неделька… ничего же не случится?»
Поэтому очень важно дать возможность пользователю оценить опасность этой проблемы. Пользователь в этот момент не хочет лезть в какие-то сложные инструкции. Если действительно произошло что-то страшное, важно указать одно —  серьезность проблемы. Иногда «эксплуатацию продолжать нельзя», а иногда и правда можно подождать до зарплаты.

Крайне необычное поведение пользователей или сервисов.

Бывает ситуация, как на графике. Что вызвало такой резкий скачок? К примеру, это температура в двигателе повысилась? Или это просто датчик какой-то забарахлил?

В таких ситуациях лучше всего пользователю дать возможность самому принять решение о том, что же это было.

В качестве примера — хорошая длинная история. В сентябре этого года видеоблогер PewDiePie во время стрима на несколько сотен тыс. человек обозвал своего чернокожего противника словом, которое в англоязычном мире называть в принципе не стоит. Он, конечно, потом извинился, но все равно произошел скандал. Производители разных игр, в том числе, Шон Ванаман, подали жалобу в YouTube с просьбой удалить все видеозаписи того, как PewDiePie играл в их игры.

Но за PewDiePie тоже стояла большая армия поддержки. И на игры Шона Ванамана в Steam (сервис, который продает эти игры) посыпались сотни негативных отзывов. Эти отзывы не отражали качество игры, но могли негативно сказаться на ее продажах. И Steam проделал просто потрясающую работу: они обратили внимание пользователя, что произошло, что замечен нетипичный объем отрицательных отзывов с 11 сентября:

При этом они позволяют пользователю самому решить, исключать эти отзывы или учитывать. Пользователь может сам принять решение, насколько эти отзывы для него важны в контексте покупки игры. Такая работа над ошибками восхищает меня и как usabilist’а, и как пользователя этого сервиса.

Дополнительные возможности — скрытый потенциал

Не все ошибки — просто баги. У многих есть скрытый потенциал. Давайте про это немного поговорим.

Обучайте через ошибки

Во-первых, как я уже говорила ранее, через ошибки можно и нужно обучать.
Например, сервис Skyeng — это онлайн школа английского языка, которая работает только через браузер Google Chrome. Этот браузер автоматически (по дефолту) иногда блокирует входящие видеозвонки или аудиозаписи. И в такой ситуации Skyeng вешает кнопочку, которая ведет на вполне подробную инструкцию:

У этого решения тоже есть некоторые проблемы. Если таких кнопочек в вашем сервисе будет очень много, все эти инструкции будет просто невыносимо, дорого и сложно поддерживать в актуальном виде. А пользователь на самом деле не сильно любит читать какие-то инструкции.

Еще один пример — SEMrush. Это окно входа в сервис:

Оно отображается в том случае, если я пошла по ссылке, которая требует от меня авторизации. Большая часть сервисов в такой ситуации выдает ошибку 404, пользователь уходит и больше не возвращается по этой ссылке. Но в SEMrush не ограничиваются просто формой входа. Они показывают дополнительные картинки и описание работы в той части сервиса, куда ведет эта ссылка. Таким образом пользователь входит в контекст. Он понимает, куда пойдет, если сервис ему знаком. А если сервис не знаком, получит беглое представление о том, что его ждет после входа.

Выводите из тупика

Еще один потенциал сообщений об ошибках — это вывод из тупика.

Часто ошибки являются абсолютно тупиковыми сценариями. Пользователю нужно вспоминать контекст и возвращаться по сценарию выше.

Например, возьмем сервис Avito. Там есть вкладка «Сохраненные поиски»:

Если там ничего нет, пользователь вынужден возвращаться обратно к строке поиска. В соответствии с представленной здесь инструкцией, которую он должен каким-то образом запомнить, он должен выполнить сохранение поиска где-то там на странице.

А можно было сделать вот так:

Мы знаем (сохраняем) историю и выводим ее здесь, чтобы пользователь, не отрываясь от контекста, нажал звездочку и сохранил какой-то нужный ему поиск. Таким образом мы превращаем тупиковый сценарий в возврат к основному пути.

Доступность

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

Меня очень радует, что в последнее время об этом стали много говорить, и много в этом направлении стали делать. Например, недавно UsabilityLab проводили тестирование доступности интернет-банков для людей с нарушениями зрения и слуха.

Но в контексте ошибок мы иногда забываем про разницу восприятия и делаем некоторые вещи, которых делать нельзя.

Например, многие используют только цветовую индикацию ошибки. Так делать не стоит, потому что есть дальтоники:

Многие дизайнеры скажут: «Я всё проверил в специальном сервисе, который показывает, как видит дальтоник». Но на самом деле эти сервисы никогда не покажут точной картины, потому что все дальтоники видят по-разному. И даже если вы подберете яркость / контрастность, всё равно существует риск, что пользователь-дальтоник эту ошибку не распознает.

Например, поле регистрации во Wrike содержит как раз такую ошибку:

У них реализована чисто цветовая дифференциация — при ошибке красным подсвечивается обводка и текст внутри поля. Лучше всего добавить какое-то текстовое сообщение или символ.

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

Человек просто сломает глаза при попытке прочитать такой текст.

Проводите Accessibility testing для сценариев с ошибками

Бизнес-ценность

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

Что нужно делать? Мой коллега выстроил работу в своем коллективе следующим образом. Все ошибки, которые возникают, сначала собираются в какой-то один большой мешок (log). Оттуда вычленяются только те ошибки, которые повторяются.

Повторяющиеся ошибки уже имеют бизнес-ценность. Это те ошибки, на которые стоит потратить время.

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

Я понимаю, что интерфейс — это не всегда часть вашей работы. И даже далеко не все product owner’ы горят желанием выстраивать работу с ошибками в своей команде, потому что это не всегда выгодно (выгода, если и есть, иногда не видна сразу). Но моя цель — немного расширить ваш образ мышления и задать вопрос: вы делаете только свою работу или вы делаете классный продукт?

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

Резюме

Что я предлагаю вам делать со всей этой информацией?

1. Когда вы придете на работу, обсудите доклад с командой и владельцем продукта. Особенно полезно зайти к UX’ерам или к дизайнерам.
2. Проверьте, насколько ваши сообщения об ошибках полезны пользователям.
3. После этого вы сможете комплексно посмотреть на свой продукт, найти его слабые места, которых раньше, возможно, не замечали, и улучшить ошибочные сценарии.
4. И еще один очень важный пункт в контексте тестирования — ошибочные сценарии тоже нужно тестировать и часто на равных правах с остальными.

Что почитать?

Здесь есть несколько ссылок:

1. «Release It!: Design and Deploy Production-Ready Software», Michael T. Nygard
2. «How to write a great error message», Thomas Fuchs, https://goo.gl/4L8YWo
3. Architecting Your Software Errors For Better Error Reporting, Nick Harley, https://goo.gl/7em6cQ

В заключение я хочу сказать, наверное, только одну вещь: ошибки — это тоже опыт. Проектируйте его.

---

Если тема тестирования и обработки ошибок вам так же близка, как и нам, наверняка вас заинтересуют вот эти доклады на нашей майской конференции Heisenbug 2018 Piter:

• Пишем UI тесты для Web, iOS и Android одновременно # python (Игорь Балагуров, Uptick)
• Web Security Testing Starter Kit (Андрей Леонов, SEMrush)
• Бета-тестирование ВКонтакте (Анастасия Семенюк, ВКонтакте)

Автор: Майкл Болтон

Перевод: портал software-testing.ru

Оригинал статьи: http://www.developsense.com/essays/AReviewOfErrorMessages.html

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

Начальные знания о сообщениях об ошибке

Программа выводит сообщение об ошибке в ответ на необычную или исключительную ситуацию, которую не может разрешить самостоятельно. Если программа написана корректно, сообщения об ошибке у нее выводятся нечасто: везде, где это возможно, программа сама справляется с возникающими проблемами и не обращается за помощью к пользователю.

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

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

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

При этом не стоит полагаться и на операционную систему. Удивительно, но команды DOS COPY и XCOPY до сих пор не проводят проверку на наличие свободного места на диске перед началом копирования файлов; вместо этого копирование начинается “вслепую” с надеждой на то, что места будет достаточно. Windows ничуть не лучше, эта система тоже не проверяет диск на наличие свободного места перед копированием файлов. Хуже того, если вы одновременно копируете несколько файлов, Windows прерывает процесс копирования после обнаружения первой ошибки и “забывает”, какие файлы были выделены для копирования.

При написании программы старайтесь предугадать условия возникновения ошибки и реакцию системы на эти ошибки. Постарайтесь выполнить задачу пользователя максимально точно, и не относитесь к ошибке как катастрофе (если, конечно, это не является реальной катастрофой). Запомните состояние программы до возникновения проблемы и дайте пользователю возможность легко вернуться в это состояние. Всегда пишите функции, которые возвращают статус выполнения и используйте уникальный код ответа для каждой проблемной ситуации. Если возвращается код ответа, который свидетельствует о возникновении проблемы, обычно удаётся собрать достаточно информации, которую можно передать ответственным за исправление ошибки специалистам. С другой стороны, помните, что внутренние сбои в работе программы, с которыми она может справиться самостоятельно, не должны беспокоить пользователя, поэтому сообщения о таких ошибках не должны выводиться без крайней необходимости. Также в сообщении нужно четко разграничить информацию, предназначенную для пользователя, и необходимую для сотрудников техподдержки.

 Как выглядит корректно составленное сообщение об ошибке?

Сообщение об ошибке должно:

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

Оно не должно:

• содержать информацию, которая не поможет в решении проблемы и на которую пользователь зря потратит время;
• содержать бесполезную, избыточную, неполную или неверную информацию.

Хороший пример

Одно из самых лучших сообщений об ошибке, которые я когда-либо видел, выглядело примерно так:

«Система ATS потеряла связь с принтером. Для решения проблемы убедитесь, что принтер включен, и попробуйте запустить печать снова. Если напечатать документ не удается, убедитесь, что оба конца кабеля, соединяющего компьютер с принтером, надежно соединены с устройствами, и попробуйте снова запустить печать. Если и в этом случае проблема не устранена, свяжитесь с Джо Грантом по номеру (212) 555-1212 и сообщите ему, что программа выдает ошибку ATSPR35 в строке 31, модуль PRNFNC»

Это сообщение программы по подбору персонала (называется «Система ATS»), созданной независимым разработчиком для кадрового агентства в 1988. Сообщение выглядит почти так, как я описал выше. Существенным отличием является то, что оно не имеет привычный вид окна Windows, потому что это сообщение из программы DOS. Я упоминаю об этом, потому что это сообщение было составлено во времена, когда объем памяти ограничивался 640 Кб. У пользователей тогда не было большого опыта работы с компьютером, но даже если бы они были экспертами в этой области, все равно сообщение было бы полезным.

Давайте сравним это сообщение с требованиями, предложенными выше:

• Сообщение совершенно четко идентифицирует программу. Более того, строка заголовка идентифицирует тип ошибки.
• В сообщении сказано о том, что программа потеряла связь с принтером. В сообщении не говорится «невозможно напечатать», или «LPT1: Ошибка», или любой другой малоинформативный текст, скопированный из операционной системы. Сообщения об ошибке большинства операционных систем очень лаконичны и обычно для пользователя бесполезны. А это сообщение составлено так, что его может понять обычный пользователь.
• В сообщении пользователю предлагаются действия, которые он способен выполнить, независимо от уровня или опыта владения программой. Здесь не высказываются догадки о причине ошибки. Предложенные действия располагаются от простого к более сложному, а причины – от более вероятных к менее вероятным. Отчасти здесь автору программы повезло – далеко не всегда самые распространенные ошибки проще всего исправить.
• Программа не предлагает действий, которые будут пустой тратой времени. («Попробуйте перезапустить программу», или еще хуже, «Попробуйте переустановить приложение».)
• Текст сообщения тщательно составлен. Важен каждый пункт сообщения. Нет бесполезных рекомендаций. Не предлагается искать причину сбоя в другом приложении. Вся информация точная и полезная.
• Самое главное, в сообщении есть полезная техническая информация и для пользователя, и для сотрудника техподдержки, и для разработчика. Если ошибка содержится в коде, сообщение указывает программисту, где именно следует искать ошибку и тип ошибки. Немаловажный плюс – указание реального имени человека. Приятнее иметь дело с конкретным человеком, чем с абстрактной организацией, наличие имени программиста говорит об ответственности за свою работу.

10 примеров неудачных сообщений об ошибке

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

 

 «Невозможно загрузить список новых групп. Произошла ошибка»

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

К этому сообщению у меня вообще нет комментариев.

К этому тоже. Хотя оно выглядит не таким грозным как предыдущее.

 

 «Интерфейс передачи сообщений вернул неизвестную ошибку. Если проблема повторяется, перезапустите Outlook»

Вам известно больше, чем вы сообщаете, и вы что-то скрываете? И кстати, как именно может помочь перезапуск Outlook?

 «Переключение из режима Internet Only E-mail Service в режим Corporate or Workgroup E-mail Service может быть несовместимо с существующими приложениями»

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

 

 «Невозможно запустить программу. Возможно, один из компонентов занят или отсутствует. Пожалуйста, проверьте, правильность установки и попробуйте еще раз».

 «Возможно». Компонент занят или отсутствует, или и то и другое? Если компонент используется, то какой именно компонент? Файл? Если так, можно узнать имя файла?

«Действие не может быть выполнено. Действие не может быть выполнено».

Правда? Правда? Какое действие? Какое действие? Что я должен сделать, чтобы устранить проблему? Что я должен сделать, чтобы устранить проблему?

 «Невозможно найти файл cuecard.hlp. Хотите найти файл вручную?»

Нет, не хочу. Я хочу, чтобы вы его нашли.

«Невозможно найти файл cuecard.hlp. Проверьте наличие файла на вашем диске. Если файл не будет найден, переустановите его».

Может, все-таки поищете, нет? Честно говоря, я не помню ситуацию, при которой я получил это сообщение, соответственно не помню и программу, которая его вывела. Тем не менее, я помню, что и тогда мне было непонятно, что мне следует переустановить.

Почему сообщения об ошибках обычно составлены некорректно, и как это можно исправить?

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

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

Программу нужно писать так, чтобы сообщения об ошибках появлялись как можно реже. Чтобы облегчить идентификацию ошибок, включите в вашу программу функцию протоколирования или режим подробной диагностики. Все функции программы, которые могут дать сбой, должны иметь код ошибки, который должен отображаться в сообщении об ошибке. Такие коды помогают выявить причину ошибки, а также облегчают тестирование локализованных версий. Документируйте эти коды ошибок, и в сообщение включите информацию о том, где находится эта документация, чтобы помочь техподдержке. Убедитесь, что в программе есть механизм для идентификации отсутствующих файлов, записей реестра и т. д. Создайте классы и функции обработки ошибок, чтобы получить систематизированные, корректно оформленные сообщения об ошибках – и постоянно используйте их в своей работе в дальнейшем. Проведите анализ кода, проверьте программу с другими разработчиками, чтобы убедиться, что программу легко читать и поддерживать, что в ней нет дефектов и она логически последовательна. Предоставьте тестировщикам инструменты для тестирования или программу, которая позволит просмотреть все сообщения об ошибках в вашей программе.

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

Программировать сейчас, конечно, сложнее, чем раньше. С каждым днем нужно осваивать все больше новых технологий, языков программирования, различных смежных дисциплин. От разработчиков требуют писать код быстрее, это оставляет меньше времени для размышлений о дизайне. Однако программистам и менеджерам не стоит обманываться – никто в компании не захочет взять на себя ответственность за дефекты и ошибки в программе, уже переданной на тестирование (или, хуже того, пользователю). Поэтому разработчики и менеджеры должны в своем рабочем плане выделить время на проектирование и на отладку, при необходимости закладывать больше времени и предусмотреть дополнительную помощь, особенно в вопросах, не требующих программирования, например, таких как разработка интерфейса пользователя.

Представьте себя на месте пользователя, который столкнулся с проблемой – вряд ли техподдержка отреагирует немедленно. Когда вы составляете сообщение об ошибке, важно помнить, что содержащаяся в нём информация должна быть полезной. Полезная информация экономит время. Помните также о том, что сообщение будут читать не только пользователи. Сообщение должно быть полезным и для сотрудников техподдержки, которые принимают звонки от пользователей, и для сотрудников контроля качества, которые помогают в поиске причины сбоя, и для программиста, ответственного за исправление ошибки в коде. Каждый специалист в этом процессе – это расход для компании. И если код обработки ошибок можно написать только один раз, то поддержку нужно будет оказывать многократно – десятки, сотни, или даже тысячи раз. Сотрудничайте с техподдержкой, тестировщиками и авторами технической документации; задавайте вопросы, считайте расходы и пытайтесь оценить стоимость решения проблем, возникающих после выпуска продукта. Не забудьте учесть в своих расчетах снижение продаж. Если руководство вашей компании хочет быстрее выпустить продукт на рынок и отказывается выделить время на обработку ошибок, вежливо напомните о том, во сколько может обойтись такая политика.

Обсудить в форуме

Баг-репорт — это отчет об ошибке. В нём указывают, что нужно исправить в программном обеспечении или на сайте. Перечисляют причины и факты, почему поведение считают ошибочным.

Отчеты отличаются: содержание зависит от предметной области, типа программного обеспечения и даже части программы, где произошла ошибка. Но есть и общие, характерные для всех отчетов моменты.

Почему важно сообщать об ошибках и кто это делает

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

Во многих командах разработчиков есть тестировщики или даже службы обеспечения качества. Они ищут и готовят сообщения об ошибках, а разработчики устраняют проблемы.

Тестировщиком реально стать даже без опыта в IT. Для этого пройдите курс Skypro «Инженер по тестированию». Научитесь писать тестовую документацию и составлять отчеты, тестировать веб- и мобильные приложения и API, освоите нужные инструменты. Внутри — мастер-классы с реальными рабочими задачами, домашки и разборы от наставника. Создадите четыре проекта для портфолио и получите диплом гособразца.

Основные принципы

Правильные отчеты помогают программистам быстрее исправлять ошибки. Детали зависят от типа багов. Но есть несколько основных принципов — что и как включать в баг-репорт, чтобы заранее снять вопросы разработчиков.

Указывайте:

1️⃣ Только одну ошибку на отчет. Это золотое правило, потому что так гораздо проще исправлять баги. Легче отслеживать статус отдельных отчетов и выставлять приоритеты задач, распределять работу между несколькими разработчиками. Да и меньшее количество информации проще запомнить и проанализировать.

2️⃣ Место интерфейса программного обеспечения, в котором возникла ошибка. Опишите экран, на котором находитесь, состояние интерфейса. Включите URL-адрес страницы, если это веб-приложение.

3️⃣ Действия в программе. Пошагово опишите действия, которые выполняли перед тем, как столкнулись с ошибкой. Это важно: может оказаться, что некорректное поведение программы началось до того, как вы его заметили.

4️⃣ Ожидания. Поведение программы может быть некорректным с точки зрения общей логики или вашего личного опыта — указывайте не только очевидные отказы выполнения и неверные результаты вычислений. Программы создают, чтобы облегчить пользователям жизнь, а не заставлять их подстраиваться под готовый результат.

5️⃣ Скриншот или запись экрана с ошибкой. Есть риск ошибиться, когда пишешь отчет об ошибке. Это значительно усложнит работу команды разработки. Визуальные материалы — более точный способ указать на проблему, чем просто описать ее.

6️⃣ Техническую информацию. То есть вашу операционную систему, браузер, тип устройства — персональный компьютер, мобильный телефон или планшет. А еще тип устройства ввода — клавиатуру, мышь, сенсорный экран и прочее. Будут полезны и параметры монитора, чтобы исправить ошибки в отображении пользовательского интерфейса.

7️⃣ Все сообщения об ошибках и коды. Они помогут определить, что это за ошибка и как ее устранить. Показывайте и те сообщения, которые кажутся нерелевантными. Даже они могут помочь разобраться в проблеме.

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

9️⃣ Пробовали ли исправить проблему. Есть причина, по которой айтишник всегда спрашивает: «Вы пробовали выключить и снова включить?» или «Пытались ли обновить веб-страницу?». Перезагрузка может быть простым способом исправить проблему. Если она не исчезает — это дает много информации. Укажите, и это сэкономит время на последующее обсуждение проблемы.

🔟 Насколько проблема влияет на работу. Обычно серьезность варьируется от очень высокой (полностью останавливает работу) до очень низкой (визуальные недочеты). Эта информация поможет командам разработчиков расставить приоритеты, определить порядок, в котором устранять ошибки.

Основные элементы

Отчет должен быть четким, действенным и простым. Иначе разработчикам будет сложно понять проблему и найти решение.

Обычно программисты и тестировщики договариваются, что и как указывать. Еще на это влияет система, в которой готовят отчет. Но есть общие компоненты баг-репорта:

👉 Резюме — краткое обозначение проблемы, причина и тип ошибки.

👉 Описание — подробности и любые сведения, которые помогут локализовать и исправить ошибку.

👉 Вложения — любые визуальные или другие материалы.

👉 Срок выполнения — если важно, чтобы ошибку исправили к определенной дате.

👉 Критичность — комментарий, насколько баг мешает нормальной работе приложения.

Часто выделяют следующие уровни критичности ошибок:

☝ Блокирующий (Blocker) — полностью блокирует нормальную работу программы, нужно исправить как можно быстрее.

☝ Критический (Critical) — сильно искажает логику приложения и значительно осложняет работу с ним.

☝ Значительный (Major) — затрагивает только отдельные элементы программы, существенно мешает работать.

☝ Незначительный (Minor) — либо не сильно влияет на работу программы, либо проявляется редко.

☝ Тривиальный (Trivial) — относится к визуальным недочетам в интерфейсе: опечатки, неудобные цвета и прочее.

Жизненный цикл

Порядок работы тоже зависит от соглашений в команде, системы управления. Но выделяют общие статусы отчета, которые встречаются практически везде:

💡 Новый — только создан, ждет проверки разработчиком.

💡 Принят — отчет проверили, проблему подтвердили.

💡 Отклонен — отчет проверили, но команда разработки отказалась работать по нему. Например, потому что ошибку не удалось повторить. Или то, что показалось ошибкой, — нормальное поведение программы. Или проблему уже устранили, когда работали над другим отчетом.

💡 Назначен — ошибку передали исполнителю.

💡 В работе — разработчик исправляет ошибку.

💡 Проверяется — исполнитель закончил работу, результат проверяет старший специалист.

💡 Закрыт — ошибку исправили, результат доступен пользователям.

Системы для отчетов об ошибках

Современные программы — это сложные, многоуровневые информационные системы. Большинство из них неидеальны, где-то постоянно появляются баги. Чтобы помочь командам разработчиков справиться с потоком отчетов об ошибках от пользователей или тестировщиков, создали специальные системы. Они позволяют автоматизировать работу с багами.

Такие программы называют баг-трекерами. Чаще всего они — часть более сложных систем: управления проектами или исходным кодом приложения.

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

К наиболее распространенным системам управления проектами относят:

• Jira.
• YouTrack.
• Redmine.

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

К основным системам управления исходным кодом относят:

• GitHub.
• GitLab.
• Bitbucket.

Интерфейсы и функции систем довольно сильно отличаются, но для работы с отчетами все предоставляют базовый набор функций:

✔️ форма создания отчета об ошибке с полями для ввода основных элементов;

✔️ управление состоянием и параметрами;

✔️ форма обсуждения, в которой команда задает вопросы и оставляет комментарии, указывает дополнительные детали;

✔️ уведомление об изменениях через имейл или другую систему обмена сообщениями.

У части баг-трекеров есть публичное голосование. Пользователи голосуют за или против бага: так повышают или понижают его приоритет.

Главное

• Баг-репорт — специальный вид отчета о неисправности в программном обеспечении или веб-сайте. Баг-репорт готовят тестировщики или специалисты из команды по контролю качества.
• Оформление баг-репорта сильно влияет на скорость, с которой исправят ошибки, на итоговый результат. Указывайте причину и тип ошибки, подробности, срок выполнения, критичность. Прикладывайте скриншоты или запись экрана.
• Прописывайте, пробовали ли исправить проблему, насколько она влияет на работу. Указывайте операционную систему, браузер, тип устройства, параметры монитора.
• Есть системы, с которыми проще создавать баг-репорты и управлять ими. Основные: Jira, YouTrack, Redmine, GitHub, GitLab, Bitbucket.

При тестировании возникает необходимость документирования найденных дефектов. Это позволяет исправить их в кратчайшие сроки.

Если кратко, то хороший баг-репорт позволяет:

• воспроизвести проблему;
• понять, в чем проблема, и какова ее важность.

Что такое баг, типы багов

По версии международной комиссии по сертификации тестирования программного обеспечения (ISTQB), баг(дефект) — изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. Например, неверный оператор или определение данных может привести к отказам компонента или системы.

Критичность и приоритет бага. Атрибуты баг-репорта

Необходимо рассказать о приоритете и критичности бага. Важно понимать разницу между ними. Примеры приведу из личного опыта. Объектом тестирования в моей работе является ПО приёмников цифрового телевидения. Главной задачей ПО приёмника является расшифровка контента, передаваемого в зашифрованном виде. Для успешной расшифровки абонент должен приобрести у оператора подписку на соответствующий пакет телеканалов.

Критичность бага – это  атрибут, который характеризует влияние бага на общую функциональность разрабатываемого ПО.

По критичности баги делят на:

S1. Блокирующий (Blocker). Всё тестируемое ПО не может работать без устранения бага. Например, приёмник начинает перезагружаться сразу после включения, мы не сможем больше ничего протестировать из-за этого бага.

S2. Критический (Critical). Большая часть ПО не может корректно работать. Например, приёмник не может открывать закодированные каналы. До устранения этого дефекта можно протестировать UI, а также функционал, не связанный с расшифровыванием каналов.

S3. Значительный (Major). Блокирует работу одной из основных логических цепочек ПО. Например, неправильное сообщение об ошибке при отсутствии подписки на пакет оператора.

S4. Незначительный (Minor). Не нарушает основные логические цепочки приложения, с ним можно продолжать работать почти без потери качества. Здесь можно привести неточный перевод с русского на английский в меню приёмника.

S5. Тривиальный (Trivial). Эта степень присваивается, когда баг вообще не влияет на общее качество работы ПО. Например, незначительное пересечение элементов в меню.

Приоритет бага — это то, в каком порядке нужно решать проблемы. Существует три степени приоритетности:

P1. Высокий приоритет (High). Нужно исправить немедленно, потому что баг является крайне важным для всего релиза. Например, старое сообщение об отсутствии подписки на пакет, хотя обновление текстов являлось целью этого релиза.

P2. Средний приоритет (Medium). Точно нужно будет исправить, баг достаточно важен, но не требует немедленного решения. Например, некорректный перевод в меню приёмника.

P3. Низкий приоритет (Low). Нужно будет исправить, но баг не очень важный и не требует немедленного решения. Например, это могут быть баги в функционале, который уже не используется оператором, но ещё не был удалён из кода.

Что такое баг репорт, его типичная структура

Глоссарий ISTQB говорит, что баг репорт — это документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.

Но можно сказать и проще: баг репорт (bug report) – это технический документ, который содержит в себе полное описание бага, включающее информацию как о самом баге (краткое описание, критичность, приоритет и т.д.), так и об условиях возникновения данного бага.

Состав баг репорта приведен в таблице:

Как правильно оформить баг-репорт

1. Для начала нужно убедиться, что найденный баг ещё не был оформлен. Следует провести поиск его в соответствующем проекте по всем подходящим ключевым словам иили полям. Если баг уже есть, следует обновить его описание.
2. Если баг не найден – нажимаем на кнопку создания бага. Не стоит забывать важное правило: один дефект — один баг в трекере.
3. Далее нужно постараться кратко описать, что не работает — это и будет заголовок баг-репорта.
4. После этого перейти к подробному описанию бага: указать шаги к воспроизведению.
5. Указать ожидаемый результат. Можно добавить ссылку на спецификацию.
6. Указать полученный результат.
7. Указать версию ПО, также указать версию окружения.
8. Если необходимо, приложить соответствующие артефакты: логи, скриншоты, дампы и т.д.

Ошибки при создании баг-репорта

Здесь перечислим проблемы, которые чаще всего встречаются при написании баг репорта.

Заголовок не понятен. Есть риск, что ни разработчик, ни коллеги не обратят внимания на довольно критичную проблему.

Отсутствуют шаги для воспроизведения. Есть риск, что разработчик, не поняв как повторить проблему, вернёт баг со статусом «Не воспроизводится».

Неправильно назначен баг. Возможно, баг по ошибке был назначен не на того разработчика или вообще остался в статусе “не назначен”. Есть риск, что багу долгое время не будет уделено внимание.

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

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

Жизненный цикл бага

Итак, баг найден, репорт составлен, что дальше? Дальше ведётся работа над багом в соответствии с жизненным циклом, который может быть настроен в системе багтрекинга. На практике это зависит от процессов в компании.

Если кратко, то после создания баг-репорта статус бага может выглядеть следующим образом:

• Новый (New). Тестировщик нашел баг, дефект успешно занесен в «Bug-tracking» систему.
• Открыт (Opened). После того, как тестировщик отправил ошибку, она либо автоматически, либо вручную назначается на человека, который должен её проанализировать. В зависимости от решения, баг может быть:
• Отложен (Postponed). Исправление бага отложено, т.к. он не является критичным на данном этапе разработки или по другим причинам.
• Отклонен (Rejected). По разным причинам дефект может и не считаться таковым, что вынуждает отклонить его. Не баг, а фича.
• Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему.
• Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build), происходит назначение на разработчика, который должен исправить ошибку.
• Исправлено (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.
• Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект. Если бага больше нет, он получает данный статус.
• Повторно открыт (Reopened). Если опасения тестировщика оправданы, и баг в новом билде не исправлен – он все так же потребует исправления, поэтому вновь открывается.
• Закрытый (Closed). В результате определенного количества перепроверок баг все-таки окончательно устранен и больше не потребует внимания команды – он объявляется закрытым.

Более наглядно жизненный цикл бага можно посмотреть на диаграмме:

При использовании системы тест менеджмента TestIT существует возможность интеграции с системами баг-трекинга. В нашей компании это JIRA. Достаточно нажать “save and create bug” и мы получаем почти готовый баг репорт в JIRA.

Нужно только добавить несколько полей связанных с текущим проектом.

В разделе Description уже есть разделы steps, actual result and expected result, что особенно актуально для начинающих тестировщиков и позволит им не пропустить важные разделы в баг репорте.

Вместо заключения

Если ваш баг-репорт составлен правильно, то шансы на быстрое исправление этих багов выше. Таким образом, исправление ошибки зависит от того, насколько качественно вы о ней сообщите. Смысл написания баг-репорта состоит в том, чтобы устранять проблемы. Составление правильных баг-репортов — не что иное, как навык, и его необходимо сформировать.

Если тестировщик не сообщает об ошибке правильно, программист, скорее всего, отклонит эту ошибку, заявив, что она не воспроизводится.

Поэтому, чем лучше тестировщики будут писать баг-репорты, тем дешевле обойдётся компании исправление этих дефектов.

From Wikipedia, the free encyclopedia

An error message is information displayed when an unforeseen problem occurs, usually on a computer or other device. On modern operating systems with graphical user interfaces, error messages are often displayed using dialog boxes. Error messages are used when user intervention is required, to indicate that a desired operation has failed, or to relay important warnings (such as warning a computer user that they are almost out of hard disk space). Error messages are seen widely throughout computing, and are part of every operating system or computer hardware device. Proper design of error messages is an important topic in usability and other fields of human–computer interaction.^[1]

Common error messages[edit]

The following error messages are commonly seen by modern computer users:^{[citation needed]}

Access denied

This error occurs if the user doesn’t have privileges to a file, or if it has been locked by some program or user.

Device not ready

This error most often occurs when there is no floppy disk (or a bad disk) in the disk drive and the system tries to perform tasks involving this disk.

File not found

The file concerned may have been damaged, moved, deleted, or a bug may have caused the error. Alternatively, the file simply might not exist, or the user has mistyped its name. This is most commonly seen on the internet with outdated links to web pages that no longer exist. On a local computer, this is more frequent on command line interfaces than on graphical user interfaces where files are presented iconically and users do not type file names.

Low Disk Space

This error occurs when the hard drive is (nearly) full. To fix this, the user should close some programs (to free swap file usage) and delete some files (normally temporary files, or other files after they have been backed up), or get a bigger hard drive.

Out of memory

This error occurs when the system has run out of memory or tries to load a file too large to store in RAM. The fix is to close some programs or install more memory.

[program name] has stopped working.

This message and similar ones are displayed by several operating systems when program causes a general protection fault or invalid page fault.

Notable error messages[edit]

• Abort, Retry, Fail? — A notoriously confusing error message seen in MS-DOS

  

  An example of an Error message .vbs script

• Bad command or file name — Another notoriously common and confusing error message seen in MS-DOS
• The Blue Screen of Death — On Microsoft Windows and ReactOS operating systems, this screen appears when Windows or ReactOS can no longer run because of a severe error.^[2] It is roughly analogous to a kernel panic on Linux, Unix, or macOS.
• Can’t extend — an error message from Acorn DFS. DFS stores files in non-fragmented contiguous disk space, this error is caused when trying to extend an open random-access file into space that is already occupied by another file.
• Guru Meditation — an error message from the Amiga, roughly analogous to a kernel panic or BSOD, also adopted by more recent products such as VirtualBox.
• HTTP 404 — A file not found error seen on the World Wide Web, usually resulting from a link to a page that has been moved or deleted, or a mistyped URL
• lp0 on fire — A Unix warning that the printer may be «on fire», literally or not
• Not a typewriter — A Unix error message that is confusing due to its now obsolete use of the word «typewriter», and which is sometimes output when the nature of the error is seemingly entirely different
• PC LOAD LETTER — An error on several HP laser printers that simply asked the user to add «Letter» size paper in a confusing way^[3]
• SYNTAX ERROR — Seen on many computer systems when the received instructions are in a format they don’t understand
• HTTP 504 — An error found on the World Wide Web stating that a gateway timeout occurred in the internet link.
• Error 1603 — An error that states that a problem during installation of a computer program, this error particularly occurs on Windows computer systems.
• <application name> has stopped — An error message commonly found on Android devices, which states a current running application unexpectedly stops working or crashes.
• Success — one of the error messages (in this instance, POSIX) that occurs when the program has detected an error condition, yet the actual error message printing routine relies on C library to print the error reported by the operating system (in this case, errno.h), while the underlying system calls have succeeded and report no errors (in this case, errno == 0). This is a form of sloppy error handling that is particularly confusing for the user.
• [Connection Time Out Error Mac] — Error occurs on Mac systems when it takes more time to connect wireless networks.

Fail pets[edit]

With the rise of Web 2.0 services such as Twitter, end-user facing error messages such as HTTP 404 and HTTP 500 started to be displayed with whimsical characters, termed Fail Pets or Error Mascots. The term «Fail Pet» was coined, or at least first used in print, by Mozilla Engineer Fred Wenzel in a post on his blog entitled «Why Wikipedia might need a fail-pet — and why Mozilla does not.»^[4] Dr. Sean Rintel argues that error messages are a critical strategic moment in brand awareness and loyalty. Fail pets are of interest to marketers because they can result in brand recognition (especially through earned media). «However, that same recognition carries the danger of highlighting service failure.»^[5] The most famous fail pet is Twitter’s Fail Whale (see Twitter service outages). Other fail pets include:

• Ars Technica: Moon Shark (March 3, 2013)
• FarmVille on Facebook: Sad cow.
• GitHub: Octocat
• Google: Broken robot (March 2, 2011)
• iCloud: Cloud with Apple System 7 emoticon-style face and a magnifying glass
• Macintosh: Sad Mac
• Palliser Furniture: Between the cushions (January 31, 2018)
• Tumblr: Tumbeasts (January 25, 2011)
• Twitter: Fail Whale / Twitter Robot (July 30, 2008)
• YouTube: Televisions (on main site), light static inside video window (embedded video)
• Cartoon Network: BMO [Asia]: Domo
• Google Chrome: T-Rex
• Patreon: Red fox with a helmet floating in space
• VK: Sad Vkontakte dog
• Scratch: Giga scratching his head

Message format[edit]

The form that error messages take varies between operating systems and programs.

Error messages on hardware devices, like computer peripherals, may take the form of dedicated lights indicating an error condition, a brief code that needs to be interpreted using a look-up sheet or a manual, or via a more detailed message on a display.

On computers, error messages may take the form of text printed to a console, or they may be presented as part of a graphical user interface. Error messages are often presented as a dialog box, which makes them cause a following mode error in the user interaction. In many cases the original error can be avoided by error prevention techniques. Instead of raising an error message the system design should have avoided the conditions that caused the error.^[6]

While various graphical user interfaces have different conventions for displaying error messages, several techniques have become common:

• A dialog box, or pop-up message, appears in a window on the screen, blocking further interaction with the computer until it is acknowledged. On Mac OS X, sheets are a form of dialog box that are attached to a specific window.
• Notification icons appear to notify a user about a condition without interrupting their work. On Windows, notification icons appear in the System Tray. On Mac OS X, notification icons may appear in the menu bar, or may take the form of an application’s icon «bouncing» in the Dock. The GNOME user interface for Unix systems can display notification icons in a panel.
• Minor errors may be displayed in a status bar, a small portion of an application’s window that can display brief messages to the user.

The three main factors^[7] that influence the design of error messages are technical limitations, the amount of information to be presented, and what kind of user input is required.

Some systems have technical limitations that may constrain the amount of information an error message can contain. For example, a printer with a sixteen-character alphanumeric display can only show a very limited amount of information at once, so it may need to display very terse error messages. Even with computer monitors, the programmer must consider the smallest monitor that a user might reasonably use, and ensure that any error messages will fit on that screen.

The nature of the error determines the amount of information required to effectively convey the error message. A complex issue may require a more detailed error message in order to adequately inform the user of the problem.

Security[edit]

When designing error messages, software designers should take care to avoid creating security vulnerabilities. The designer should give the user enough information to make an intelligent decision, but not so much information that the user is overwhelmed or confused. Extraneous information may be hidden by default or placed in a separate location. Error message should not expose information that can be exploited by a cracker to obtain information that is otherwise difficult to obtain. Examples are systems which may show either «invalid user» or «invalid password» depending on which is incorrect, and the error page in the web server IIS 5.0 which provides a complete technical description of the error including a source code fragment.

See also[edit]

• Alert dialog box
• Human–computer interaction
• Interaction design
• Usability
• User error
• User interface design
• Exception handling

References[edit]

External links[edit]

• A more useful 404 (A List Apart)
• Avoid being embarrassed by your error messages (UX Matters)
• Oops! I ruined your life.  (Cooper Journal) Archived 2014-08-25 at the Wayback Machine

Ошибки компьютера

Ошибки компьютера всегда случаются в самое неподходящее время. Ошибки такого рода не позволяют людям закончить их работу, выполнить отчет или дописать дипломную работу. Скорее всего причина неполадок кроется в операционной системе, но не всегда.

Давайте рассмотрим все возможные неполадки.

Ошибки, компьютера делятся на аппаратные и программные. К первому пункту относятся всевозможные перебои в аппаратной начинке. Некачественные модули, попадание влаги, чрезмерный перегрев и подобные факторы, несомненно, приведут к печальным последствиям, после которых компьютер скорее всего выйдет из строя. Менее существенны неполадки программного уровня. Как правило, решением может быть переустановка операционной системы, либо скачивание и установка патч-программы, а возможно требуется просто «полазить» в настройках.

Устранение программных неполадок.

Таким образом, программные неполадки – самые простые ошибки, которые можно устранить и без помощи специалистов. Так же на вооружение у пользователя есть очень хорошее приложение под названием «Восстановление системы». Его можно использовать в случае когда вы установили какой либо драйвер или программу, а компьютер после перезагрузки выдает ошибки, либо вообще отказывается загружаться. Как восстановить систему вы можете узнать здесь.

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

Компьютерные вирусы и пользовательские ошибки.

Ошибки, вызванные появлением вирусов – еще одна из самых неприятных проблем. Сегодня в сеть закачано огромное множество вредоносных червей, которые портят файловую систему и выводят компьютер из строя. Естественно, в таких случаях от пользователей потребуется немедленной найти и обезвредить вредоносную программу. Важно помнить, что некоторые вирусы могут вести себя не очень активно, блокируя только некоторые программы. Но рано или поздно работа системы нарушается и компьютеру может потребоваться помощь. Довольно часто, малоопытные пользователи, сами того не подозревая, наносят вред своему компьютеру. Необдуманные действия, удаление системных файлов и жизненно важных приложений – все это еще один фактор, вызывающий отдельные ошибки в работе ПК. Случается, что после подобных действий, ОС не работает не достаточно быстро или вообще не загружается. Как правило, среди таких пользователей подавляющее большинство – новички, которые плохо знакомы с особенностями современных компьютеров. В таких случаях, не рекомендуется самостоятельно устранять причины неполадок. Лучше всего обратиться к частному мастеру, либо в сервисный центр где вам вернут ваш ПК к нормальной жизни. Удачи!

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник

Что такое «компьютерная баг» и откуда взялся этот термин

В ы, наверное, слышали это раньше: в программном обеспечении есть «баг», из-за которого что-то работает неправильно. Что такое компьютерный баг и откуда появился этот термин? Мы объясним.

Баг- это непреднамеренная ошибка в компьютерном программном обеспечении

«Компьютерный баг» или «программный баг» — это термин, обозначающий непреднамеренную ошибку программирования или дефект в компьютерном программном обеспечении или оборудовании. Баги возникают из-за человеческой ошибки в конструкции оборудования или где-то в цепочке программных инструментов, используемых для создания компьютерных приложений, прошивок или операционных систем.

Программная ошибка возникает, когда программист либо делает ошибку при написании программного обеспечения, либо пишет код, который работает, но имеет непреднамеренные последствия, которые не были предвидены программистом. Устранение ошибок в программном обеспечении называется «дебаг».

В сегодняшнем мире ошибки в программном обеспечении — серьезное дело. Почти 20 лет назад Национальный институт стандартов и технологий подсчитал, что ошибки в программном обеспечении обходятся экономике США почти в 60 миллиардов долларов в год (около 0,6% ВВП в 2002 году), и с тех пор эта цифра, вероятно, увеличилась. Хотя точно количественно оценить негативные последствия ошибок сложно, легко представить, как неисправное программное обеспечение может повлиять на производительность. Это может даже подвергнуть опасности жизнь людей на транспорте или поставить под угрозу жизненно важную инфраструктуру, такую как электростанции.

Почему мы называем их багами

Термин «баг» появился еще до изобретения компьютеров, и мы точно не знаем, кто изначально придумал термин «баг» для обозначения инженерного дефекта. В письменных источниках историки проследили это до Томаса Эдисона не ранее 1870-х годов.

Эдисон использовал этот термин в своих личных заметках и переписке для обозначения сложной проблемы, которая требовала решения, или инженерного дефекта, который требовал исправления. Он даже пошутил о том, что этот термин имеет отношение к насекомым, написав в письме 1878 года:

«Вы были частично правы, я действительно обнаружил «баг» в своем аппарате, но не в самом телефоне. Он принадлежал к роду callbellum. Похоже, насекомое находит условия для своего существования во всех телефонных аппаратах».

Хотя некоторые считают, что примеры Эдисона означают, что он ввел термин «баг», но вполне возможно, что он произошел от кого-то еще раньше и что он просто популяризировал этот термин среди своих друзей и соратников-инженеров. Оксфордский словарь английского языка цитирует пример 1889 года, связанный с Эдисоном, который описывает ошибку как метафору насекомого, заползающего в элемент оборудования и вызывающего его неисправность, предполагая, что настоящая ошибка, делающая именно это, могло первоначально послужить источником этого термина, похожего на термин «ложка дегтя».

Отбросив на мгновение слово «баг», первым известным человеком в истории, который осознал, что программное обеспечение может работать неправильно из-за ошибок в программировании, была Ада Лавлейс. Она писала об этой проблеме еще в 1843 году в своем комментарии к аналитической машине Чарльза Бэббиджа.

«На это можно ответить, что процесс анализа в равной степени должен быть выполнен для того, чтобы снабдить аналитическую машину необходимыми оперативными данными; и в этом также может заключаться возможный источник ошибки. При условии, что реальный механизм безошибочен в своих процессах, карты могут отдавать ему неправильные приказы».

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

Бабочка Грейс Хоппер

На протяжении десятилетий книги, журналы и веб-сайты ошибочно сообщали, что термин «баг» был придуман легендарным компьютерным ученым Грейс Хоппер, когда моль влетела в реле компьютера Harvard Mark II и вызвала его неисправность. Как гласит история, она затем записала мотылька в журнал и сделала историческую заметку: «Первый реальный случай обнаружения бага».

Хотя в 1947 году в Mark II действительно залетела моль, она не была источником терминов «баг» или «дебаг», которые предшествовали инциденту. Кроме того, не совсем ясно, действительно ли моль привела к неисправности компьютера, или это была просто забавная находка, пока они исправляли другие дефекты. Хоппер сделала эту историю известной, рассказав ее в широко цитируемом интервью от ноября 1968 года.

Хоппер нашла эту историю забавной, потому что после частых поисков ошибок в компьютере (например, аппаратных и программных дефектов) ее команда наконец нашла настоящего насекомого (bug) внутри компьютера. Отсюда надпись: «Первый реальный случай обнаружения жука».

Интересно отметить, что Хоппер описывает мотылька Mark IV как «забитого до смерти», вероятно, из-за повреждений, вызванных движением электромеханических реле компьютера, что позволяет предположить, что компьютер продолжал функционировать, пока моль была там.

Историки не знают, был ли это дневник Хоппер или кто на самом деле написал запись, но сегодня журнал Harvard Mark II находится в Национальном музее американской истории в Смитсоновском институте в Вашингтоне, округ Колумбия.

Хотя бабочка Mark II (назовем его «Марк») не была первой компьютерной ошибкой, она, тем не менее, остается физическим и культурным символом очень реальной и сложной проблемы, с которой борются все программисты.

Источник

Ошибки при загрузке Windows: Разбираемся с самыми частыми

Ошибки при загрузке Windows

Ошибки при загрузке Windows встречаются довольно часто. Он могут говорить о неисправности жесткого диска, оперативной памяти, процессора или операционной системы.

Давайте разберемся, что обозначают ошибки, и как от них избавляться.

Загрузка системы

Разберем процесс загрузки ОС. При включении компьютера и его успешной загрузки, процессор выполняет ряд инструкций, которые ему предоставляет BIOS.

Эти инструкции внесены в энергозависимую память CMOS. После запуска процессор обращается к адресуемой ячейке микросхемы. Это зависит от заложенных свойств. В ней записан код BIOS.

Начальный набор инструкций, выполняемых процессором, называют процедурой POST (Power-On Self Test- самопроверка при подключении к питанию).

С ее помощью проводятся следующие действия:

BIOS прекращает свою работу в загрузке, когда находит главную загрузочную запись на жестком диске (или в месте записи ОС) и передает ей управление дальнейшей загрузкой.

Теперь в загрузку вступают программы, записанные на носителе.

Причины ошибок загрузки

Перечислим основные проблемы загрузки:

Нужно выяснить причину сбоя и устранить ее. А чтобы проблемы больше не возникали снова – не повторяйте эти ошибки.

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

Что мешает загрузке Windows?

Наиболее распространенные ошибки Windows

Дело в том, что ошибка при загрузке Виндовс изменяется в зависимости от версии ОС.

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

Windows XP

В нынешнее время данная версия Виндовс практически перестала существовать.

Однако некоторые компьютеры (часто это именно старые модели) всё ещё работают на этой ОС.

И хотя люди, которые давно знают ХР привыкли к её ошибкам, однако стоит разобраться с самыми распространенными из них.

Потеря системного загрузчика

Это наиболее распространенная проблема при загрузке Виндовс ХР. Обычно она возникает при попытке переустановить ОС.

При появлении данной ошибки система выдает одну из двух надписей:

Устранение данных ошибок возможно посредством выполнения данных пунктов:

После этого система перезапустится, и ошибка будет устранена.

Хотя существуют и другие причины потери системного загрузчика, однако вышенаписанное случается наиболее часто.

NTLDR is missing

Данная проблема также довольно распространена. При её появлении, зачастую, пользователи просто форматируют диск, что приводит не только к устранению ошибки, но и потере всей памяти.

Однако данную проблему можно решить без таких радикальных методов, достаточно понять причину её происхождения. А устранить и при этом сохранить данные не так уж и сложно.

Данная ошибка представляет собой черный экран с надписью NTLDR is missing.

Порой для устранения проблемы достаточно нажать популярное сочетание клавиш Ctrl+Alt+Delete (об этом написано в экране ошибки).

Данная комбинация должна перезапустить систему, но помогает это далеко не всегда.

Ошибка означает, что не доступны файлы отвечающие за загрузку системы. Причин её может быть несколько:

Решение ошибки «NTLDR is missing»

HAL.dll

При данной проблеме, во время загрузки ОС, пользователь наблюдает надпись на подобие «Не удается запустить HAL.dll» или «Файл не найден или поврежден».

При её появлении первым пришедшим на ум решением становится переустановка Виндовс. Однако можно справится и без столь кардинальных мер.

Дело в том, что данный файл отвечает за взаимодействие железа (самого компьютера) и его программных компонентов.

Проблема возникает по той причине, что ХР, как наиболее старая версия, подвержена различным ошибкам наиболее часто.

Как таковых причин возникновения ошибки может быть множество. Однако её всё же можно устранить при помощи ряда действий в BIOS’е не переустанавливая при этом операционную систему.

Тем не менее стоит понимать, что порой справится поможет только радикальный способ.

Решение ошибки «HAL.dll»

Windows 7

Несмотря на новые версии Виндовса, семерка всё же остается наиболее популярной. Это скорее дело привычки.

Многие считают данную версию наиболее удобной и усредненной между ХР и той же восьмеркой (в принципе так оно и есть)

. Именно потому что версия наиболее популярная, то и ошибка загрузки Виндовс 7 является частой проблемой.

Чаще всего при загрузке Windows 7 возникают различные коды ошибок, которые указывают на ту или иную проблему. Стоит разобраться с наиболее частыми проблемами, которые возникают.

Загрузчик системы

Как и у Виндовс ХР, у семерки случаются проблемы с загрузчиком. Причина проблемы та же что и у предыдущей версии.

Однако восстановить загрузчик семерки можно как автоматически, так и вручную.

Первый способ наиболее удобен и с ним справится даже самый неопытный пользователь, но он не всегда может помочь избавится от проблемы.

Загрузчик системы Windows 7

0x80300024

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

Обычно эта ошибка указывает на недостаток места для установки системы.

Для того, чтоб ошибка не возникала необходимо проверить память на жестком диске и в случае необходимости отформатировать его.

«ERROR»

Известная многим ошибка, которая возникает при запуске системы. Обычно возникает после установки ОС. На белом фоне высвечиваются большие красные буквы.

Для решения проблемы необходимо перезагрузить компьютер с установочным диском внутри и при включении запустить диск.

Дойти до пункта «Восстановление системы», а после поставить галочку возле «Используйте средства восстановления…», однако стоит учесть, что придется выбрать систему.

В командной строке необходимо вписать «bootrec /fixboot». После этого проблема будет устранена.

Startup Repair Offline

Дословно это проблема означает «восстановление запуска не в сети», порой устраняется после перезагрузки.

Однако зачастую система пытается восстановить себя без подключения к сети и у неё не получается. Поэтому придется ей помочь.

Обычно это решается несколькими способами:

Все эти способы требуют определенны знаний и неопытному человеку лучше вызвать человека, который хорошо в этом разбирается.

Решение проблемы Startup Repair Offline

0x0000007b

Наиболее пугающая для пользователей ошибка – «синий экран смерти». Зачастую это означает, что система «легла» и помогут ей только кардинальные меры.

Однако иногда случается и так, что после перезагрузки компьютера ошибка исчезает и больше не проявляет себя, однако стоит понимать, что таким образом компьютер сигнализировал о серьезной проблеме, которую необходимо устранить.

Основных причин проблемы может быть несколько:

В первую очередь необходимо провести диаг6ностику ошибки чтоб выяснить причину проблемы, после чего уже браться за её устранение в зависимости от выявленных причин.

Windows 10

Наиболее новая версия операционной системы также не исключает того, что появится ошибка при загрузке Виндовс 10.

И, хотя разработчики старались максимально исключить изъяны, однако это компьютер, а значит предусмотреть и исключить в се проблемы просто невозможно.

Именно поэтому при появлении ошибок придется справятся своими силами (или если уж совсем всё плохо – при помощи специалистов).

Inaccessible Boot Device

Данная ошибка встречается довольно часто. И как разработчики не пытались устранить все изъяны системы, однако при обновлении десятки, после отката ОС или даже при простой перезагрузке появляется данная ошибка.

В первую очередь необходимо проверить приоритетность устройств в BIOS, так как данная проблема может возникнуть в случае если жесткий диск с установленной ОС стоит не на первом месте в приоритете.

Также необходимо отключить все подключенные USB-устройства и различные карты памяти, так как это тоже может стать причиной проблемы.

Ошибка «Inaccessible Boot Device»

CRITICAL_PROCESS_DIED

Это синий экран с грустным смайлом. Может означать как синий экран смерти, так и ошибку, которая потребует восстановления в высветившемся окне.

Для автоматического восстановления необходимо нажать «Переустановить», после чего система самостоятельно устранит проблему.

Operating system wasn’t found

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

Стоит предположить, что твердый или жесткий диск работаю неправильно вследствие некорректного завершения системы в прошлый раз.

Необходимо переподключить носитель через другой шлейф. Обычно этого достаточно для устранения проблемы.

Ошибка «Operating system wasn’t found»

Выводы

Стоит понимать, что проблем с загрузкой и ошибок при ней может быть очень много и выше изложена лишь небольшая часть. Однако мы рассмотрели наиболее часто встречаемые ошибки при загрузке Windows.

Однако следует знать, что не все ошибки решаются легко (например, при помощи перезагрузки). Любая ошибка оповещает пользователя о том, что произошел какой-либо сбой.

Это значит, что стоит уделить внимание причине проблемы и нормальному её разрешению. Это исключит последующие проблемы с компьютером и продлит время его функционирования.

Некоторые из ошибок сообщают о неполадках в системе ОС, другие сигнализируют о том, что проблемы кроются гораздо глубже – в железе.

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

По сути это замкнутый круг. И если не обращать внимания на проблему, то могут возникнуть серьезные неполадки.

Также понимание того, что не все проблемы можно решить самостоятельно спасут Ваш компьютер от значительного количества ошибок и поломок. Поэтому не стоит пренебрегать вызовом специалиста.

Решение восстановление системы при запуске windows

Ошибки при загрузке Windows: Разбираемся с самыми частыми

Понравилась статья? Подпишитесь на канал, чтобы быть в курсе самых интересных материалов

Источник

Сбои и ошибки ПК. Лечим компьютер сами. Начали!

Из вашего компьютера валит сизый дым? Windows не грузится, и вы видите лишь черный экран? Или же Windows загружается, но потом экран становится синим и по нему бегут «кракозябры»? Из системного блока раздается пронзительный писк? Не паникуйте! И не спешите вызывать мастера. В большинстве случаев сбои компьютера можно «излечить» самостоятельно. Как – научит эта книга. В ней предельно просто рассказывается о наиболее часто встречающихся поломках ПК. Рассматриваются как аппаратные сбои, так и сбои на уровне операционной системы и программного обеспечения. Отдельно обсуждаются вирусы и вредоносные программы.

Оглавление

Приведённый ознакомительный фрагмент книги Сбои и ошибки ПК. Лечим компьютер сами. Начали! предоставлен нашим книжным партнёром — компанией ЛитРес.

Наиболее распространенные аппаратные неисправности

Всем известен факт, что количество поломок всегда зависит от сложности механизма, будь то автомобиль или компьютер. Чем больше составных частей, тем больше вероятность того, что рано или поздно система откажет в работе.

С каждым днем количество электронных компонентов, из которых состоит компьютер, растет, причем растет очень быстро. Чтобы компьютер получил новые возможности, практически всегда требуется аппаратная модернизация его составляющих. Однако самое неприятное в этом то, что любой компонент, насколько бы независимой ни была его работа, всегда связан с большим количеством других компонентов и зачастую выход из строя одной составляющей влечет за собой выход из строя целого ряда других.

Работа компьютера зависит от многих факторов, и результатом такого положения являются частые сбои и появление неисправностей. Если с программными сбоями бороться достаточно просто, то с аппаратными все гораздо сложнее.

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

Не забывайте, что любые ремонтные работы, связанные с электрическим током, необходимо производить при отключенном проводе питания (за исключением случаев, когда наличие питания необходимо).

Итак, какими «болезнями» страдает компьютер и насколько это чревато для обычного пользователя? Таких «болезней» достаточно много, как минимум столько, сколько комплектующих в компьютере. Порой определить причину неисправности компьютера бывает достаточно сложно, даже имея какой-либо опыт ремонта. Однако компьютер сам поможет вам, предложив собственное средство тестирования — часть системы BIOS, которая называется POST.

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

Использование средств BIOS для определения неисправности

Каждое включение или перезагрузка компьютера вызывает автоматический запуск диагностической программы самотестирования — POST (Power On Self-Test), которая записана в микросхеме CMOS-памяти. Эта программа проверяет работоспособность всех важнейших компонентов компьютера: процессора, оперативной памяти, дисковой подсистемы, системной логики (чипсета) и всех устройств, от которых зависит нормальное функционирование компьютера. Информация о результатах диагностики может выдаваться тремя способами.

• Звуковые сигналы. Каждой неисправности соответствует серия звуковых сигналов, которые выдает POST в ходе тестирования устройств. Звуковое оповещение обычно используется в самых критичных случаях, когда компьютер лишен возможности отображения текстовой информации. Звуковые сигналы могут применяться также параллельно с текстовыми сообщениями, и именно на звуковые сигналы в первую очередь необходимо ориентироваться при возникновении неисправности.

• Текстовые сообщения. Этим способом POST пользуется в дополнение к звуковым сигналам, если видеосистема компьютера исправна. При этом на экране появляется сообщение, кратко описывающее неисправность, и код ошибки. По коду неисправность можно изучить более подробно, воспользовавшись документацией к материнской плате или к BIOS. С помощью текстовых сообщений компьютер, как правило, информирует только о незначительных ошибках, например о неполадках с аккумуляторной батареей, неработоспособности контроллера клавиатуры и т. п. Хотя можно увидеть и более «страшные» сообщения: например, о плохом состоянии жесткого диска или сбойной оперативной памяти.

• Шестнадцатеричные коды в конкретный порт по определенному адресу. Независимо от того, выдаются звуковые или текстовые сообщения, система использует и этот способ. Однако, чтобы прочитать шестнадцатеричные коды, необходимо иметь специальное оборудование — POST-карту. К данному способу определения неисправности обращаются специалисты сервисных центров, когда имеются очень серьезные поломки и другие способы оповещения о неисправностях не работают.

Поскольку POST-картой, необходимой для определения неисправности третьим способом, обладают далеко не все пользователи, чаще всего ошибки определяют по звуковым сигналам и текстовым сообщениям POST. Поэтому рассмотрим их более подробно.

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

Если компьютер работает нормально, то есть тестирование POST завершилось успешно, вы услышите один короткий звуковой сигнал, после чего начнется загрузка операционной системы компьютера.

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

Если вы услышали последовательность коротких и длинных сигналов, обязательно посчитайте их количество и обратите внимание на длительность. [1] Подсчитав количество сигналов, найдите данное сочетание в таблице, соответствующей BIOS вашего компьютера, чтобы определить, что означает данный сигнал. В табл. 1.1–1.3 приведены основные варианты серий звуковых сигналов, характерные для BIOS разных производителей, а также краткие пояснения к ним.

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

В табл. 1.4–1.6 приведены возможные варианты сообщений BIOS разных производителей.

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

Неисправности блока питания

Без сомнения, блок питания (рис. 1.1) — самый важный компонент компьютера, поскольку именно он отвечает за снабжение стабильным напряжением всех устройств, установленных в компьютере (в том числе подключенных к USB-портам). В самом простом случае неисправность блока питания приводит к нестабильной работе компьютера, постоянным его зависаниям и т. д.

Рис. 1.1. Блок питания

Блок питания выходит из строя достаточно часто, особенно это касается блоков «со стажем». Самое плохое, что иногда поломка данного устройства влечет за собой выход из строя практически всех установленных компонентов.

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

В домашних условиях блок питания можно починить, если вы имеете достаточный опыт в ремонтных делах и знакомы с основами радиоэлектроники. Если вы совсем новичок в этом деле, то максимум, что вы сможете сделать, — проверить предохранитель и внешне осмотреть компоненты блока питания. Чтобы точно определить неисправное звено, следует вооружиться измерительным прибором.

Намного более предпочтительно купить новый блок питания, поскольку ресурс работы блока достаточно малый, а количество подключаемых устройств и потребление мощности возрастает, что приводит к большой нагрузке на него и быстрому сокращению «жизни».

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

В упрощенном варианте алгоритм работы блока питания выглядит следующим образом. Поступая на вход блока питания, переменное напряжение обрабатывается сетевым фильтром и высоковольтным выпрямителем. Выпрямленное высоковольтным фильтром напряжение поступает на импульсный трансформатор, который понижает его до нужного уровня. Далее пониженное постоянное напряжение поступает на стабилизатор, который контролирует характеристики напряжения и при необходимости преобразует его. В итоге получается набор напряжений, обладающих необходимыми характеристиками: ±5 и ±12 В с нужной силой тока.

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

Таким образом, определив сбойный модуль, достаточно заменить детали исправными. Работа блока питания должна восстановиться, если, конечно, устройство не повреждено настолько серьезно, что это привело к выходу из строя еще нескольких модулей блока питания.

Приближающуюся «кончину» блока питания можно предвидеть. О неисправностях устройства свидетельствуют следующие признаки:

• периодический или полный отказ компьютера включаться;

• появление неприятного запаха из вентиляционных отверстий блока питания;

• внезапные перезагрузки или зависания компьютера во время обычной работы;

• ошибки в функционировании оперативной памяти как при начальном тестировании, так и при работе в операционной системе;

• прекращение работы сразу всех устройств хранения данных (при пропадании напряжения на выводах блока питания) или каждого по очереди;

• заметное повышение температуры в блоке питания и корпусе компьютера (из-за выхода из строя вентилятора или вентиляторов, установленных в блоке питания, или любых других электронных составляющих);

• появление напряжения на корпусе компьютера, что можно ощутить, если приложить руку к корпусу или разъемам на задней стенке;

• появление странных ошибок в работе операционной системы и программ.

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

Большая часть блоков питания, как и большая часть бытовых устройств, снабжена плавким или керамическим предохранителем. Такой предохранитель срабатывает и перегорает при повышенном потреблении тока или резком скачке напряжения (что может произойти по разным причинам). При этом тонкая проволока (или керамический корпус) внутри предохранителя перегорает, и напряжение перестает поступать на другие компоненты блока питания. Это самый простой, но не самый действенный способ предохранить их от поломки.

В этом случае сначала нужно отключить блок питания от напряжения и вытянуть его из корпуса. Далее следует снять с блока питания защитный кожух.

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

Сняв кожух, внимательно рассмотрите плату блока питания. Поскольку предохранитель устанавливается непосредственно за кабелем питания, то и искать его нужно там, где этот кабель припаян к печатной плате.

Как правило, предохранитель выглядит как деталь со стеклянным или керамическим корпусом (рис. 1.2). Если корпус стеклянный, вы без труда увидите внутри тонкую проволоку. Ее отсутствие или обрыв — явный свидетель неисправности предохранителя.

Рис. 1.2. Внешний вид керамического предохранителя

Однако он может иметь другую форму и быть припаянным непосредственно к плате. В этом случае вам придется выпаять предохранитель.

Для замены используйте аналогичный по параметрам предохранитель. Предохранители отличаются током срабатывания, что зависит от мощности блока питания. Например, в блоках питания средней мощности (200–300 Вт) установлены предохранители с током сгорания 4 А. Поэтому обязательно обратите внимание на маркировку предохранителя, нанесенную на один из металлических контактов предохранителя или на его стеклянный корпус. Многие пользователи вместо предохранителя используют тонкую проволоку (так называемый «жучок»), припаяв ее к контактам крепления предохранителя. Этот способ имеет свои недостатки: слишком толстая проволока может не перегореть, когда это нужно, что приведет к выходу из строя других модулей блока питания и появлению невосстановимых неисправностей.

Если после замены предохранителя блок питания включится и компьютер заработает в обычном режиме, значит, проблема решена. Если же, независимо от того, перегорает или не перегорает предохранитель, после подачи напряжения блок питания «молчит», то это говорит о неисправности в каком-то другом модуле блока питания.

Практически в любой электронной аппаратуре в качестве высоковольтного выпрямителя выступает сборка (или несколько сборок) из четырех высоковольтных диодов, включенных по параллельной схеме, задача которой — превращение переменного напряжения в постоянное. Диоды могут находиться в закрытом пластмассовом корпусе, а могут располагаться рядом друг с другом на печатной плате блока питания (рис. 1.3).

В любом случае нужно проверять каждый диод, поскольку неисправность одного из них автоматически приводит к перегоранию предохранителя. Для проверки выпрямителя следует воспользоваться мультиметром, подключая его контакты к каждому из диодов. При этом сопротивление диода в прямом направлении должно составлять примерно 500–600 Ом, а в обратном — 1,1–1,3 МОм. Если сопротивление диода не соответствует приведенным показателям, то его необходимо заменить, выпаяв его из платы.

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

Рис. 1.3. Высоковольтный выпрямитель (диоды)

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

В большинстве случаев для проверки транзистора его не обязательно отпаивать. Обычный транзистор имеет три ножки — базу, коллектор и эмиттер. Транзисторы нужно тестировать и на замыкание, и на внутренний обрыв, поэтому необходимо точно знать, где находится какая ножка. Информацию о конкретном транзисторе можно найти в справочной литературе или в Интернете. Как бы там ни было, рабочий транзистор следует прозванивать от базы к эмиттеру и коллектору, а между эмиттером и коллектором — нет. Поскольку транзистор — родной брат диода, то и сопротивление переходов у них примерно одинаковое. Таким образом, в одну сторону сопротивление должно составлять 100–300 Ом, а в обратную — больше 1 МОм.

Если проверка высоковольтного выпрямителя не дала результатов, следует проверить высоковольтный фильтр. В качестве высоковольтного фильтра выступает набор из нескольких электролитических конденсаторов большой емкости. Именно эти конденсаторы являются причиной выхода из строя блока питания, особенно если их количество слишком мало или электролитические характеристики далеки от нормы (рис. 1.4).

Рис. 1.4. Конденсатор высоковольтного фильтра (обратите внимание: второй конденсатор отсутствует)

Электролитические конденсаторы, как известно, рассчитаны на определенное напряжение и имеют определенную емкость. Емкость конденсатора обеспечивается за счет его специальной конструкции и применения электролита. Таким образом, конденсатор может выйти из строя, если на него подать слишком высокое напряжение или если он теряет емкость при высыхании или вытекании электролита. Такое редко случается с конденсаторами известных производителей, которые устанавливаются в дорогие блоки питания. Если же вы являетесь обладателем дешевого блока питания неизвестного производителя — приготовьтесь к сюрпризам.

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

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

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

Для замены обязательно используйте конденсаторы с достаточным запасом напряжения, например 250–270 В, и емкости, значение которой нанесено на корпус. Как правило, емкость таких конденсаторов составляет 400–1500 мкФ.

Стабилизатор можно считать самым главным модулем блока питания. В этом устройстве применяются интегральные схемы, что говорит о его некоторой интеллектуальности. Стабилизатор состоит из каналов, каждый из которых обрабатывает конкретное напряжение и контролирует его.

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

Если осциллографа у вас нет, то можно воспользоваться способом, который безошибочно определяет неисправность микросхемы. Как правило, в роли стабилизатора выступает микросхема TL494 (или ее аналоги), имеющая 14 выводов, каждый из которых представляет нужное напряжение определенной характеристики (рис. 1.5).

Рис. 1.5. Стабилизатор (микросхема)

Суть способа заключается в проверке стабилизатора, который находится внутри микросхемы. Для этого на двенадцатую ножку подайте постоянное напряжение от +9 до +12 В, а на седьмую — от — 9 до — 12 В (при этом отключите блок питания от сети). Напряжение на четырнадцатой ножке микросхемы должно быть +5 В. Если отклонение от этого значения достаточно сильное (более 0,5 В), то внутренний стабилизатор микросхемы неисправен. В этом случае придется заменить микросхему.

Выход из строя процессора

Центральный процессор (рис. 1.6) — самое востребованное устройство компьютера. От скорости работы процессора во многом зависит скорость всей системы.

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

В нормальных условиях процессор работает долго и без сбоев. Однако многие пользователи, стремясь повысить производительность системы, разгоняют процессор. Это, естественно, негативно влияет на стабильность его работы и к тому же в несколько раз сокращает его долговечность.

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

Отремонтировать процессор невозможно, поэтому относитесь внимательно к этому устройству и без особой нужды не совершайте с ним никаких действий.

Повреждения материнской платы

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

Множество микросхем и электронных блоков сильно усложняют ремонт материнской платы. Кроме того, печатная плата материнской платы содержит до 5–6 слоев, на каждом из которых находится множество печатных проводников. Поэтому естественно, что ремонт материнской платы в домашних условиях возможен лишь при возникновении достаточно мелких поломок. Если же плата получила серьезные механические повреждения, которые привели к внутреннему обрыву проводников, то восстановить ее невозможно даже в сервисном центре.

Рис. 1.7. Материнская плата

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

Большая часть поломок материнской платы происходит по вине пользователя. Остальные неисправности возникают в результате некачественного питания или перегрева участков платы.

Наиболее распространены следующие поломки.

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

• Обрыв конденсаторов или резисторов. Если вы присмотритесь, то увидите, что материнская плата усыпана миниатюрными конденсаторами и резисторами. Их очень легко отломать, орудуя отверткой или неаккуратно вставляя платы расширения.

• Короткое замыкание в электрических цепях. Чаще всего злая судьба в виде рук пользователя повреждает микросхемы, транзисторы и электролитические конденсаторы. Чтобы это сделать, иногда достаточно просто большой отвертки. От этого не застрахован никто, особенно если производить монтаж или фиксацию плат расширения при работающем компьютере.

• Разрушение разъемов и слотов. Разрушить любой разъем на материнской плате достаточно легко, а особенно — IDE-разъем. Для этого достаточно сильно нажать на него или вставлять и вытягивать кабель не равномерно, а под углом. PCI-слоты или AGP-слот также подвержены поломке. Если плата расширения имеет нестандартный размер, а материнская плата прикручена слишком близко к задней стенке системного блока, то для установки платы расширения необходимо приложить достаточную силу, и при внезапном перекосе неаккуратным движением можно повредить слот. Кроме того, наиболее велика вероятность повреждения разъемов и слотов с большим количеством контактов.

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

• Сгорание локальных портов. Многие пользователи в случае надобности (или без нее) вытягивают шнур клавиатуры, мыши, модема и других устройств при работающем компьютере. Это крайне пагубно влияет на порты материнской платы, которые при этом испытывают скачок напряжения. Контролировать это напряжение невозможно, поэтому порты часто сгорают. Особенно это касается портов PS/2.

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

• Некачественные платы расширения. Компьютерный рынок наполнен дешевыми китайскими комплектующими, которые то и дело выходят из строя. Может случиться так, что такой окажется именно ваша материнская плата. Какими будут последствия — предугадать трудно, однако абсолютно точно в таком случае повредится не только само устройство, но и слот, в котором оно установлено, а в худшем случае — система управления питанием материнской платы, что, в свою очередь, может сжечь оперативную память и процессор.

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

• Перегрев компонентов. Эта неисправность также встречается довольно часто. В большей степени перегреву компонентов подвержены материнские платы, которые оборудованы пассивными системами охлаждения. При разгоне такая система охлаждения не справляется с поставленной перед ней задачей, что приводит к повышению тепловыделения. При этом нагреваются не только «виновники», но и близлежащие участки платы. В результате — нестабильность работы компьютера, зависание, перезагрузка и выход из строя дорогостоящих компонентов.

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

Практика показала, что имеющиеся на материнской плате локальные порты ввода-вывода достаточно часто выходят из строя, особенно если устройства подключаются к портам «на ходу» (при включенном компьютере). Чаще всего встречаются неисправности портов LPT, COM и PS/2.

Порты подвержены не только сгоранию, но и механическим повреждениям. Если в первом случае ремонт в домашних условиях невозможен, то механическое повреждение можно устранить и самостоятельно.

Чаще всего это происходит с PS/2-портами, к которым подключаются клавиатуры и мыши. Из-за постоянного использования этих портов (замена устройств, частый перенос компьютера с отключением всех проводов) внутренние контакты разъемов расшатываются. В результате нарушается контакт между разъемами порта и устройства, что ничего хорошего не предвещает.

Для устранения неисправности необходимо заменить неисправный разъем исправным. Как правило, рабочий разъем выпаивают из нерабочей материнской платы, где он уже никогда не пригодится.

Выпаивание и припаивание разъема — не самая сложная, но достаточно трудоемкая и опасная операция. Чтобы вытащить разъем, нужно прогреть всю контактную площадку. Это чревато перегревом печатных проводников, которые могут отстать от платы. Иногда для таких целей используют специальную насадку на жало паяльника, которая позволяет нагревать одновременно все выводы разъема.

После того как разъем выпаян из платы, необходимо привести его в нормальный вид. Для начала нужно выровнять ножки разъема, если они погнулись в процессе выпаивания. Следующий шаг — снятие с них припоя. Для этого воспользуйтесь паяльником или плоским надфилем. Ножки должны быть гладкими и равномерными по толщине. Это гарантирует легкую установку разъема и припаивание на рабочее место.

Кроме того, следует подготовить посадочное место. Для этого пригодится приготовленный вами спирт. Аккуратно протрите нужный участок платы, а затем попробуйте освободить отверстия в посадочном гнезде, которые залил припой в процессе выпаивания разъема. Для этого воспользуйтесь иглой подходящего размера, просовывая ее в отверстия, предварительно разогретые паяльником. Используйте иглу очень осторожно, иначе можно оторвать печатный проводник.

Установить новый разъем достаточно легко. Вставив его на подготовленное место, нанесите немного паяльной жидкости и прогрейте припой возле каждой ножки так, чтобы обеспечить максимальный контакт. При этом не забывайте о возможном перегреве.

Обрыв печатных проводников — достаточно распространенная ситуация, особенно если сборкой или модернизацией компьютера занимается начинающий пользователь. В стремлении сделать все быстрее он забывает об элементарных правилах. Такое нетерпение можно понять, но не менее понятным является и результат этого нетерпения.

Чаще всего проводники повреждаются отверткой, хотя не исключены и другие варианты.

Данную ситуацию можно исправить, если на плате повреждены внешние дорожки. При внутреннем обрыве проводников материнскую плату можно оставить на запасные детали, поскольку работать она больше уже никогда не будет.

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

После этого необходимо протереть спиртом воссозданный участок и убрать скальпелем остатки припоя, которые могут замыкать на соседние проводники.

Одним из возможных побочных эффектов соскальзывания отвертки может стать повреждение одного из многочисленных выводов микросхем материнской платы. Если микросхема имеет множество выводов, что требует их плотного размещения, то некоторые из них могут прижаться друг к другу, что приведет к возникновению короткого замыкания (рис. 1.8) и, возможно, выходу микросхемы из строя.

Рис. 1.8. Повреждение выводов микросхемы

Это довольно сложная ситуация, поскольку выводы таких микросхем чаще всего очень тонкие. При попытке выровнять поврежденные выводы половина из них наверняка оторвется, после чего придется заменить всю микросхему, что в домашних условиях практически невозможно.

Поскольку исправлять поломку все равно нужно, то единственное, что можно сделать, — скальпелем и пинцетом попытаться хоть немного отодвинуть поврежденные ножки друг от друга. Делать это нужно очень осторожно, так как слишком сильный нажим может окончательно повредить микросхему.

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

Размеры конденсаторов и резисторов на материнской плате настолько малы, что оторвать один из них легко, особенно если не соблюдать правила монтажа. Очень часто такое происходит при установке «нестандартного» процессорного кулера. Когда зажим кулера очень жесткий и к тому же еще и короткий, то после нескольких попыток монтажа пользователь теряет терпение и берет на вооружение отвертку, чтобы с ее помощью закрепить непослушную защелку. Этот способ далеко не безопасен и может привести к отрыву деталей (рис. 1.9).

Рис. 1.9. Оторванные мелкие детали

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

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

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

Выход из строя жесткого диска

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

Рис. 1.10. Жесткий диск

Несмотря на то что после изготовления жесткий диск уже имеет брак поверхности (особенности технологического процесса изготовления), при нормальных условиях он будет служить вам долго и надежно. Если же жесткий диск постоянно «в разъездах» и главное его предназначение — перенос фильмов, то нет ничего странного в том, что рано или поздно с ним случится несчастье. Единственное, что можно в этом случае посоветовать, — используйте два винчестера. Один можно установить в компьютер, а другой использовать в качестве внешнего носителя. Так, по крайней мере, вы избавите себя от неприятностей с рабочим диском.

Ремонт жесткого диска в домашних условиях практически невозможен. Единственное, что можно сделать, — с помощью специальных утилит попытаться исправить сбойные участки на поверхности дисков. Для этих целей предназначены некоторые «всеядные» утилиты, умеющие работать практически с любыми моделями жестких дисков, а также «родные» утилиты, которые часто можно скачать с веб-сайта производителя конкретного жесткого диска. Универсальными программами являются, например, SMARTUDM, MHDD и др.

Источник

Здесь вы не увидите ни строчки кода. Мы поговорим об обычных людях — о наших пользователях, точнее о том, как сообщать им, если в системе возникла какая-то непредвиденная ситуация.

В основе статьи доклад Антонины Хисаметдиновой с Heisenbug 2017 Moscow, которая занимается проектировкой пользовательских интерфейсов в компании Собака Павлова.

Кроме того, на Медиуме есть цикл статей «Руководство по проектированию ошибок». Цикл еще не дописан до конца, но дает более полную и цельную картину по теме статьи.

Ошибочный сценарий

Раз за разом мы проектируем основные сценарии самых разнообразных сервисов. В случае интернет-магазина основной будет таким:

Человек заходит на сайт, выбирает товар, заказывает его доставку; оплачивает и получает заказ.

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

Всё это — ошибочные сценарии, возникающие, когда что-то идет не так.

Продуктовые команды часто не уделяют достаточно внимания таким сценариям. Например, очень типичная история: «Что-то пошло не так. У нас проблемы, поэтому просто закройте это сообщение».

Еще пример: «У нас ошибка. Повторите вашу попытку позже»:

И еще одна категория ошибок — моя любимая: неизвестные ошибки.

Зачем работать над ошибочными сценариями?

Обосновать бизнесу необходимость проработки ошибочных сценариев бывает очень сложно. Зачем нам возвращаться назад и что-то исправлять, когда впереди у нас новые фичи? Но у меня есть четыре железных аргумента, которые помогут продемонстрировать вашему product owner’у или бизнесу необходимость такой работы.

Хорошее сообщение об ошибке снижает нагрузку на техническую поддержку и персонал

На слайде представлены некоторые цифры одного из наших клиентов. Это количество звонков пользователей в техподдержку в месяц. Звонки связаны с проблемами определенного рода:

Обратите внимание, 400 человек в месяц звонят просто из-за того, что не могут войти или корректно ввести логин / пароль в соответствующей форме на сайте.

Хорошее сообщение об ошибке помогает пользователю не потеряться в воронке конверсии

Если сообщение об ошибке составлено грамотно, оно возвращает его к основному сценарию, даже если произошел разрыв сессии.

Хорошее сообщение об ошибке обучает работе с сервисом

Возможно, вам даже не потребуется создавать onboarding или какие-то обучающие видео, разработка которых, кстати говоря, тоже стоит приличных денег.

Хорошее сообщение об ошибке позволяет сохранить доверие к сервису в трудную минуту

Это последний, но немаловажный аргумент.

Вообще тема доверия «человек-технология» исследуется довольно давно. Сейчас мы уже достаточно доверяем технологиям. Например, мы никогда не будем перепроверять, отправил ли мессенджер сообщение адресату, или как калькулятор сложил или умножил трехзначные числа (к сожалению, правда, не все сервисы могут похвастаться таким уровнем доверия, как калькуляторы).

Мы доверяем свою жизнь десяткам видов разного программного обеспечения, летая в самолетах. Но это доверие очень легко разрушить. Сделать это может даже самая маленькая ошибка. И такие ошибки случаются как в маленьких, так и в очень больших компаниях.

Из-за чего возникают ошибки

Я несколько раз упомянула «хорошее сообщение об ошибке». Настала пора поговорить о том, что это значит. И для начала разберемся, из-за чего в принципе возникают ошибки.

• первое, что приходит в голову, это какие-то глобальные сбои или технические работы на сервисе;
• специфические баги;
• ошибки пользователя.

Но это далеко не всё. Еще есть:

• проблемы на стороне подключенных сервисов;
• внешние проблемы;
• крайне необычное поведение пользователей или сервиса.

Это не попытка классификации. На самом деле видов ошибок далеко не шесть, их может быть сотня или даже больше. Но в контексте проектирования интерфейсов эти ошибки самые значимые.

Глобальные сбои

Давайте начнем с ситуации, когда ваш сервис полностью недоступен.

К сожалению, такие ошибки могут возникнуть в любых сервисах, от онлайн игр до сложных биржевых профессиональных инструментов.

Хороший вопрос: что в такой ситуации делать?

Пока разработчики спешно чинят какие-то инструменты, несчастные пользователи получают странные сообщения об ошибках и достают вашу техподдержку, пишут неприятные посты в твиттере:

Давайте посмотрим на сообщения, которые в этот момент выводятся:

Они достаточно простые и некоторые из них даже честно извиняются. Но пользователи все равно чувствуют себя некомфортно и пытаются понять, в чем же дело; повторяют вход далеко не через 15 минут; тыкают, куда попало.

Как им помочь?

Подумайте о последствиях

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

Многие в таких ситуациях ограничиваются сообщением: да, у нас есть проблема и мы скоро ее поправим:

Но «скоро» — это когда?

Пользователю не нужно знать, когда вы всё поправите, с точностью до минуты. Но им нужно понимать какие-то значимые временные ориентиры, например, 15 минут, один час, пять часов или даже сутки. Это поможет им сориентироваться в пространстве и спланировать управление своими деньгами.

Еще один резонный вопрос (в ракурсе финансового сервиса): работают ли карточки?

И хорошее сообщение об ошибке сможет на него ответить. Даже если карточки не работают, лучше всё равно об этом сказать, потому что это очень важная информация.

Еще одна история — тут зарплата или перевод должны быть; а когда придут эти деньги?

Вроде бы ничего критичного, но когда человек не может проверить баланс, он начинает сильно паниковать. Поэтому предложите проверить баланс альтернативными методами, если это, конечно, возможно.

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

Важно понимать, что глобальный сбой — это проблема ваша, а не пользователя. Не нужно перекладывать на него мыслительные процессы. Предложите сразу готовые варианты.

Предупредите заранее

Не все пользователи готовы зайти в личный кабинет прямо сейчас, и далеко не все пользователи в принципе зайдут и заметят ошибку. Но если вы предупредите их заранее (например, постом в Twitter, SMS-сообщением или по электронной почте), то когда они столкнутся с сообщением об ошибке, будут готовы.

Отдельно стоит сказать про профессиональные сервисы, от которых ежедневно зависит работа пользователей. Например, сервис Антиплагиат иногда выводит такое сообщение о проведении технических работ:

Обратите внимание, что указана точная дата и точный диапазон времени — это поможет пользователю спланировать свою работу в вашем сервисе.

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

Однако если же мы говорим о профессиональных инструментах, от которых пользователь реально зависит каждый день с утра и до вечера, очень странно не предупредить о проблеме (а частота, с которой допустимо сообщать пользователю о проблемах, при этом сильно зависит от отрасли).

Специфические баги

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

Для нас баги — это знакомая история. Мы четко классифицируем их по разным параметрам: степени опасности, необходимости исправления и т.п.

Но пользователи когда замечают баг, в принципе не понимают, с чем они столкнулись. Многие даже не знают этого термина. Для них баги на самом деле выглядят вот так:

Мы предполагаем, что если пользователь вдруг заметил что-то странное, он конечно же нам об этом сообщит. У него есть для этого пять или даже больше способов:

• раздел «Контакты» и обратная связь;
• онлайн-консультант и звонок в техподдержку;
• социальные сети и чаты компании;
• отзывы (App Store и Play Market)!!!
• блоги и форумы.

Мы предполагаем, что пользователь когда-нибудь проскролит страницу вниз до подвала, найдет там вкладку «Контакты». В разделе контактов найдет среди карт, отделов, офисов продаж и прочего маленькую кнопочку «Обратная связь», нажмет на нее, выберет тему обращения. Напишет подробное письмо о том, как воспроизвести эту ошибку, приложит скриншоты и отправит.
Да, действительно, такие письма приходят. Но если ошибка очень плохая, человек может сразу оставить отзыв с низкой оценкой на App Store, где также подробно распишет, чем ему ваш сервис не нравится.

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

Или могут вообще перестать пользоваться вашим сервисом, как неработающим.
Поэтому в багтрекере ВКонтакте висит такой вот тикет, который называется «отсутствие кнопки «Сообщить о баге»»:

Действительно, это проблема очень многих сервисов.

Создайте специальные окна для сбора обратной связи

Но есть и позитивные примеры, например, Semrush. Почти по всему сервису размещены специальные окна, которые нацелены на то, чтобы забирать фидбэк от человека.

В такой ситуации пользователю стоит меньших усилий написать вам о какой-то ошибке или о фидбеке. Особенно это актуально для бета-тестирования.

Если нельзя исправить баг быстро, предупредите о нем

К сожалению, бывают такие ситуации, когда вы не можете исправить баг быстро. Можно просто предупредить об этом пользователя — как и в предыдущей части доклада.

В качестве примера здесь приведен скриншот, когда с помощью совершенно обычных окошек разработчики иконочного шрифта material design предупреждают пользователей, что есть проблема совместимости, и приносят свои извинения:

Обратите внимание, что они приводят ссылку для тех, у кого возникли эти проблемы. По ссылке инструкция, как всё исправить.

Самое главное, что нужно запомнить про специфические баги, — это необходимость качественного фидбэка. Поэтому создавайте специальные окна, чтобы как можно быстрее получать от пользователей эту информацию. Ну и второе — конечно, предупреждайте, если вам какой-то баг известен, но вы не можете его поправить.

Ошибки пользователей

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

Первый пример узкого места многих сервисов — это, конечно, вход / регистрация:

Например, поле входа в InVision. Маленькая красная полосочка — это, в принципе, всё сообщение об ошибке. Наверное, когда дизайнер его рисовал, думал, что пользователь без труда прочитает сообщение: «Упс, комбинация email и пароля не верна». Проверит сначала email, затем пароль, и снова нажмет кнопочку войти. Но статистика подсказывает, что пользователь делает несколько попыток входа и ввода пароля, прежде чем догадывается, что проблема в email-адресе.

Это происходит, потому что внимание пользователя в момент входа сосредоточено в одной очень узкой области — она называется фокусом внимания:

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

Фишка 1. Разместите сообщение в фокусе внимания

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

Фишка 2. Показывайте, где именно ошибка

Подсвечивание обоих полей — это и есть вторая фишка.
Но и это не всегда помогает.

Например, дизайнеры компании Adobe считают, что пользователи действительно это всё читают:

Еще один классический пример предлагает Xiaomi:

Или, например, сайт Госуслуги (как и многие другие) просто дублирует название поля заголовка в ошибку:

Фишка 3. Используйте понятные и короткие формулировки

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

Но в окружении интерфейса и текущих задач у пользователей это выглядит вот так:

И они не дочитывают до конца. Когда пользователь читает строку, он фокусируется на начале строки. А чтобы прочитать дальше, ему надо приложить усилия:

Ему неохота читать ваши тексты, он хочет дальше решать свои задачи.
Поэтому, сокращая формулировку и размещая сообщение в зоне фокусировки, мы можем быстрее донести смысл.

Фишка 4. Подскажите, как исправить ошибку

Кто сталкивался с кассами самообслуживания?

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

В чем была проблема? Пользователи забывают положить маленькие товары на другую сторону. Поэтому разработчики добавили звуковой сигнал, после чего в 90% таких ситуаций покупатели стали обходиться без помощника. Сигнал заставлял человека поднимать глаза на экран кассы и выходить из состояния, когда он сканирует свою огромную корзину покупок: «Точно, я не положил воду».

У этого сообщения об ошибке есть две из перечисленных «фишек»: оно подсказывает, где именно ошибка, и обучает работе с сервисом.

Фишка 5. Сохраняйте работу пользователя

Последнее, но самое интересное.

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

Чтобы вообще начать пользоваться финансовым сервисом Revolut, я должна сначала подтвердить свой номер телефона. Обратите внимание, они уже автоматически определили и подставили код страны. Спасибо ребятам.

Дальше я должна ввести свое имя и фамилию. Ну раз они определили мою страну, то я начинаю вводить автоматически по-русски, и когда я уже нажимаю «Далее», заполнив всю форму, сервис мне говорит: «Пожалуйста, используйте латинские буквы». Автоматическая валидация уже давно всем известна, и ее нужно обязательно применять! Но на этом дело не заканчивается. Мне нужно заполнить адресную информацию, причем, обратите внимание, страна уже подставлена автоматически и написана кириллицей.

Но меня не обманешь — я ввожу адрес латиницей, нажимаю Continue. И, как вы думаете, что происходит?

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

Поэтому не заставляйте пользователя вводить какие-то поля заново, используйте как можно больше автоматизации.

Проблемы подключенного сервиса

Тестируйте API подключенных сервисов

На днях мне попался интересный отчет на сайте APIFortress. Там был рассказ про компанию, которая поставляла стоковые изображение своим партнерам. Одним из них было агентство, которое занималось сувениркой с мопсами.

Однажды этот мопс-партнер позвонил в стоковую компанию и пожаловался на поломку сервиса.

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

Учите их различать проблемы

Иногда недостаточно просто знать, что где-то там у вас проблема, потому что пользователи будут видеть странные окна, которые не будут им помогать:

И в интерфейсе эту проблему не решить.

Поэтому очень важно потратить усилия, чтобы научить ваш сервис различать причины проблем с API.

Предусмотрите в интерфейсе оповещение о проблемах

Очень хороший пример — сервис-автоматизатор ifthisthenthat. С помощью связок API различных сервисов (например, умного дома или социальных сетей) они заставляют сторонние сервисы делать определенные вещи. Например, если я опубликовала пост в Instagram, он автоматически уходит в мой Facebook. Или, если я вышла из дома, сервис определяет по моей геопозиции, что я нахожусь в офисе, и проверяет, выключила ли я все свои смарт-утюги. А если не выключила, то выключает.

Эти ребята проделали очень большую работу, и не только в интерфейсе.

Во-первых, они выделяют отдельную вкладку для ошибок. Все неудавшиеся операции собираются в этот лог.

Они определяют разные типы ошибок:

В первом случае — сервис Instagram офлайн, и мы понимаем, в чем проблема. Возможно, мы временно вышли из зоны действия сети.

В случае, если пользователь никак не может поспособствовать решению проблемы, выводится просто оповещение.

Внешние проблемы

Что такое внешние проблемы в моем пользовательском понимании?

Весь software завязан на аппаратуру, на датчики и т.п. Всё это тоже создано людьми и может не работать. Поэтому очень важно сообщать об этом пользователю. Хороший сервис может сообщать о таких ошибках, как о своих.

Дайте понять, какие действия в вашем сервисе недоступны из-за внешних проблем

Хороший пример — отсутствие интернет-соединения в коммуникаторе Slack. Если во время работы у меня отвалился интернет, я вижу вот такое сообщение сверху:

Как мы помним про сообщения об ошибках пользователей, в момент ввода какого-то текста пользователь сконцентрирован в этой области:

Slack об этом не забывает и подсвечивает поле желтеньким.

При этом он не блокирует мне набор сообщения. Я могу продолжить писать его дальше, но при попытке отправить Slack-бот отправляет мне вот такое сообщение:

И в принципе очень доступно объясняет, с чем именно проблема. Такую ошибку я замечу достаточно быстро.

Большая проблема с внешними ошибками, которая пришла к нам еще из «древних» времен, когда продукты создавались инженерами для инженеров, — это содержание текстов об ошибках:

Они написаны таким языком, как будто мы сейчас до сих пор подразумеваем, что пользователь знает, что такое firewall, ftp, dll, ядро, kernel и так далее.

Четко разделите уровни компетенции

Техническому специалисту мы показываем одну информацию, а пользователю — другую.

Наверное, стоит отдельно сказать про то, как люди в принципе общаются с техподдержкой.

Для многих это действительно большой стресс. Большая часть сообщений об ошибках совершенно не подразумевает, что они должны быть поняты. Человек, который даже не знает английского языка, пытается как-то объяснить: у меня там что-то сломалось. Он испытывает очень сильный дискомфорт. И всё это влияет в целом на его опыт общения с вашим сервисом. Поэтому старайтесь создавать такие сообщения, которые пользователь сможет осознать и своими словами передать техподдержке.

Например, это фото 3D-принтера, который четко и ясно (с помощью маленького экранчика) говорит, что температурный сенсор испортился — произошла ошибка, поэтому он остановился. Свяжитесь с техподдержкой. Пользователь легко может понять, в чем дело, и для него не сложно описать эту проблему своими словами без технических терминов:

Помогите пользователю оценить приоритет проблемы

Что это значит?

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

В такой ситуации пользователь не понимает, что делать. Некоторые водители-новички вместо того, чтобы прочитать инструкцию, просто продолжают ездить, думая, что всё в порядке. А у других, наоборот, начинается паника — они пытаются вызвать эвакуатор.

А есть еще такая категория: «У меня там до зарплаты неделька… ничего же не случится?»
Поэтому очень важно дать возможность пользователю оценить опасность этой проблемы. Пользователь в этот момент не хочет лезть в какие-то сложные инструкции. Если действительно произошло что-то страшное, важно указать одно —  серьезность проблемы. Иногда «эксплуатацию продолжать нельзя», а иногда и правда можно подождать до зарплаты.

Крайне необычное поведение пользователей или сервисов.

Бывает ситуация, как на графике. Что вызвало такой резкий скачок? К примеру, это температура в двигателе повысилась? Или это просто датчик какой-то забарахлил?

В таких ситуациях лучше всего пользователю дать возможность самому принять решение о том, что же это было.

В качестве примера — хорошая длинная история. В сентябре этого года видеоблогер PewDiePie во время стрима на несколько сотен тыс. человек обозвал своего чернокожего противника словом, которое в англоязычном мире называть в принципе не стоит. Он, конечно, потом извинился, но все равно произошел скандал. Производители разных игр, в том числе, Шон Ванаман, подали жалобу в YouTube с просьбой удалить все видеозаписи того, как PewDiePie играл в их игры.

Но за PewDiePie тоже стояла большая армия поддержки. И на игры Шона Ванамана в Steam (сервис, который продает эти игры) посыпались сотни негативных отзывов. Эти отзывы не отражали качество игры, но могли негативно сказаться на ее продажах. И Steam проделал просто потрясающую работу: они обратили внимание пользователя, что произошло, что замечен нетипичный объем отрицательных отзывов с 11 сентября:

При этом они позволяют пользователю самому решить, исключать эти отзывы или учитывать. Пользователь может сам принять решение, насколько эти отзывы для него важны в контексте покупки игры. Такая работа над ошибками восхищает меня и как usabilist’а, и как пользователя этого сервиса.

Дополнительные возможности — скрытый потенциал

Не все ошибки — просто баги. У многих есть скрытый потенциал. Давайте про это немного поговорим.

Обучайте через ошибки

Во-первых, как я уже говорила ранее, через ошибки можно и нужно обучать.
Например, сервис Skyeng — это онлайн школа английского языка, которая работает только через браузер Google Chrome. Этот браузер автоматически (по дефолту) иногда блокирует входящие видеозвонки или аудиозаписи. И в такой ситуации Skyeng вешает кнопочку, которая ведет на вполне подробную инструкцию:

У этого решения тоже есть некоторые проблемы. Если таких кнопочек в вашем сервисе будет очень много, все эти инструкции будет просто невыносимо, дорого и сложно поддерживать в актуальном виде. А пользователь на самом деле не сильно любит читать какие-то инструкции.

Еще один пример — SEMrush. Это окно входа в сервис:

Оно отображается в том случае, если я пошла по ссылке, которая требует от меня авторизации. Большая часть сервисов в такой ситуации выдает ошибку 404, пользователь уходит и больше не возвращается по этой ссылке. Но в SEMrush не ограничиваются просто формой входа. Они показывают дополнительные картинки и описание работы в той части сервиса, куда ведет эта ссылка. Таким образом пользователь входит в контекст. Он понимает, куда пойдет, если сервис ему знаком. А если сервис не знаком, получит беглое представление о том, что его ждет после входа.

Выводите из тупика

Еще один потенциал сообщений об ошибках — это вывод из тупика.

Часто ошибки являются абсолютно тупиковыми сценариями. Пользователю нужно вспоминать контекст и возвращаться по сценарию выше.

Например, возьмем сервис Avito. Там есть вкладка «Сохраненные поиски»:

Если там ничего нет, пользователь вынужден возвращаться обратно к строке поиска. В соответствии с представленной здесь инструкцией, которую он должен каким-то образом запомнить, он должен выполнить сохранение поиска где-то там на странице.

А можно было сделать вот так:

Мы знаем (сохраняем) историю и выводим ее здесь, чтобы пользователь, не отрываясь от контекста, нажал звездочку и сохранил какой-то нужный ему поиск. Таким образом мы превращаем тупиковый сценарий в возврат к основному пути.

Доступность

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

Меня очень радует, что в последнее время об этом стали много говорить, и много в этом направлении стали делать. Например, недавно UsabilityLab проводили тестирование доступности интернет-банков для людей с нарушениями зрения и слуха.

Но в контексте ошибок мы иногда забываем про разницу восприятия и делаем некоторые вещи, которых делать нельзя.

Например, многие используют только цветовую индикацию ошибки. Так делать не стоит, потому что есть дальтоники:

Многие дизайнеры скажут: «Я всё проверил в специальном сервисе, который показывает, как видит дальтоник». Но на самом деле эти сервисы никогда не покажут точной картины, потому что все дальтоники видят по-разному. И даже если вы подберете яркость / контрастность, всё равно существует риск, что пользователь-дальтоник эту ошибку не распознает.

Например, поле регистрации во Wrike содержит как раз такую ошибку:

У них реализована чисто цветовая дифференциация — при ошибке красным подсвечивается обводка и текст внутри поля. Лучше всего добавить какое-то текстовое сообщение или символ.

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

Человек просто сломает глаза при попытке прочитать такой текст.

Проводите Accessibility testing для сценариев с ошибками

Бизнес-ценность

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

Что нужно делать? Мой коллега выстроил работу в своем коллективе следующим образом. Все ошибки, которые возникают, сначала собираются в какой-то один большой мешок (log). Оттуда вычленяются только те ошибки, которые повторяются.

Повторяющиеся ошибки уже имеют бизнес-ценность. Это те ошибки, на которые стоит потратить время.

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

Я понимаю, что интерфейс — это не всегда часть вашей работы. И даже далеко не все product owner’ы горят желанием выстраивать работу с ошибками в своей команде, потому что это не всегда выгодно (выгода, если и есть, иногда не видна сразу). Но моя цель — немного расширить ваш образ мышления и задать вопрос: вы делаете только свою работу или вы делаете классный продукт?

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

Резюме

Что я предлагаю вам делать со всей этой информацией?

1. Когда вы придете на работу, обсудите доклад с командой и владельцем продукта. Особенно полезно зайти к UX’ерам или к дизайнерам.
2. Проверьте, насколько ваши сообщения об ошибках полезны пользователям.
3. После этого вы сможете комплексно посмотреть на свой продукт, найти его слабые места, которых раньше, возможно, не замечали, и улучшить ошибочные сценарии.
4. И еще один очень важный пункт в контексте тестирования — ошибочные сценарии тоже нужно тестировать и часто на равных правах с остальными.

Что почитать?

Здесь есть несколько ссылок:

1. «Release It!: Design and Deploy Production-Ready Software», Michael T. Nygard
2. «How to write a great error message», Thomas Fuchs, https://goo.gl/4L8YWo
3. Architecting Your Software Errors For Better Error Reporting, Nick Harley, https://goo.gl/7em6cQ

В заключение я хочу сказать, наверное, только одну вещь: ошибки — это тоже опыт. Проектируйте его.

---

Если тема тестирования и обработки ошибок вам так же близка, как и нам, наверняка вас заинтересуют вот эти доклады на нашей майской конференции Heisenbug 2018 Piter:

• Пишем UI тесты для Web, iOS и Android одновременно # python (Игорь Балагуров, Uptick)
• Web Security Testing Starter Kit (Андрей Леонов, SEMrush)
• Бета-тестирование ВКонтакте (Анастасия Семенюк, ВКонтакте)

Так называемый «синий экран смерти» в Windows 10 видоизменился в сравнении с более ранними выпусками операционной системы. Однако, причины его появления и принципы решения проблемы (за исключением некоторых моментов) остались прежними.

Что это такое?

Синим экраном смерти (Blue Screen или BSOD) называется окно с уведомлением для пользователей и специалистов по IT с информацией о возникшей критической ошибке. Как и в прошлых редакциях, в десятой версии ОС от Microsoft BSOD сопутствует серьёзным системным проблемам, аппаратным конфликтам и фатальным сбоям.При этом появляется сообщение, извещающее, что компьютер испытывает проблемы и будет перезагружен, а также краткое описание критической ошибки. В последних редакциях Windows 10 дополнительно появился QR-code, отсканировав который пользователь может подробнее узнать о конкретной ошибке и изучить рекомендации по её исправлению.Цифро-буквенный stop-код, присутствовавший в операционных системах от Microsoft с Windows 95 по Windows 7, больше не актуален.

Почему появляется Blue Screen?

Окно с Blue Screen в Windows 10 может возникнуть, как во время загрузки системы перед появлением экрана приветствия или рабочего стола и после входа в учётную запись, так и спустя определённый интервал времени после начала работы, а также во время запуска какого-либо приложения или игры и во многих других ситуациях.Основные возможные причины появления BSOD, это:Такое большое количество факторов возникновения синего экрана смерти не подразумевает простых и универсальных вариантов решения проблемы. Тем не менее, при желании в Windows 10 разобраться с BSOD сможет и не особо продвинутый пользователь.

Критические ошибки

Чтобы начать действовать, прежде всего следует разобраться в описании конкретной критической ошибки. Сделать это иногда бывает проблематично по той причине, что ПК перезагружается сразу же после появления синего экрана. Если после сбоя система хоть какое-то время работает в нормальном режиме, необходимо отключить перезагрузку вручную:

Описанные манипуляции позволят детально прочитать сообщение синего экрана. Решения по конкретным стоп-кодам (которых, на самом деле, очень много) можно посмотреть в интернете. Наиболее распространённые критические ошибки представлены ниже.

Таблица: 10 распространённых критических ошибок Windows 10

Название стоп-ошибки	Описание и вероятные причины возникновения
DEVICE QUEUE NOT BUSY	Устройство не заняло очередь. Скорее всего, имеются неполадки «железа» либо драйверов.
INVALID DATA ACCESS TRAP	Неверный доступ к данным. Возможно, нарушена работа аппаратной составляющей ПК либо драйверов.
MAXIMUM WAIT OBJECTS EXCEEDED	Превышено максимальное ожидание объекта. Ошибка вызывается работающими программами, чаще играми.
MEMORY MANAGEMENT	Ошибка управления памятью. Причины чаще аппаратные (неисправность, конфликт модулей ОЗУ), иногда неполадки связаны с программами, драйверами, системными файлами.
FILE SYSTEM	Файловая система нарушена. Может быть связано с состоянием системных файлов Windows.
FATAL UNHANDLED HARD ERROR	Фатальный сбой системы. Среди причин появления — повреждение файлов реестра.
INACCESSIBLE BOOT DEVICE	Недоступен Boot-девайс. Вероятно, не инициализирован загрузочный диск, либо считываемый при загрузке файл.
UNABLE TO LOAD DEVICE DRIVER	Невозможна загрузка драйверов устройства. Повреждены либо отсутствуют драйверы.
UNKNOWN HARD ERROR	Серьёзная неизвестная ошибка. Повреждение системного реестра в результате неисправности жёсткого диска.
CRITICAL PROCESS DIED	Критический процесс мёртв. Происходит при удалении, неправильном изменении или повреждении системных файлов.

Способы решения проблемы синего экрана

Как показывает практика, устранение BSOD с использованием стоп-кода зачастую не приводит к положительному результату. Данный путь слишком «тернист» и малоэффективен при отсутствии достаточных познаний в области IT. Действия неопытного пользователя могут привести вплоть до полной неработоспособности Windows.Решить проблему синего экрана можно относительно просто и эффективно, но для этого рекомендуется действовать, придерживаясь изложенных далее методик и их последовательности. После каждого из вариантов выполните перезагрузку, запустите браузер, игру, «Фотошоп» или несколько тяжёлых приложений одновременно. Если система опять «падает» в BSOD, переходите к следующей инструкции.Данные рекомендации могут помочь лишь в том случае, если Windows хоть не надолго загружается после сообщения о критической ошибке. В иной ситуации (когда запуск ограничен синим экраном) следует воспользоваться спасательным Live CD или специальным диском восстановления.

Как загрузиться в Safe Mode?

Довольно часто синий экран смерти появляется прежде, чем пользователь успевает что-либо сделать после входа в Windows (выполнить проверку на вирусы, переустановить драйверы, сбросить или восстановить систему). Если ваш компьютер ведёт себя именно таким образом, попробуйте настроить загрузку системы в безопасном режиме:

В режиме Safe Mode операционная система работает с низким разрешением экрана и без поддержки основных служб и опций. Таким образом обеспечивается минимальная загруженность ПК. Лучше ничего не менять и сразу переходить к устранению Blue Screen.

Удаление вирусов и вредоносных программ

В современном интернете вредоносные программы широко распространены и опасность заражения ими ПК довольно высока даже при наличии мощной антивирусной поддержки. По этой причине, в случае с синим экраном (так же как и во многих других ситуациях, связанных с работоспособностью ПК), проверка компьютера на вирусы является приоритетной.Для выполнения поставленной задачи можно воспользоваться любым сканером-антивирусом. Проверку лучше выполнять в расширенном режиме, такая опция, как «Быстрая проверка» не всегда эффективна. Ниже перечислены некоторые из наиболее мощных утилит-сканеров:Все указанные программы портативны, то есть не требуют установки. Некоторые из них работают только в онлайн-режиме, впрочем, подключение к интернету необходимо всем приложениям для обновления баз антивирусных сигнатур. Встроенные в Windows 10 и в последние версии Google Chrome сканеры, по отзывам и тестам, менее эффективны в сравнении с перечисленным выше софтом.

Обновление драйверов

Если в сообщении синего экрана вы видите название проблемного компонента, это несколько облегчает задачу. Вам необходимо найти данные о модуле, скачать драйвер, например, с официального сайта его производителя, и затем установить через диспетчер устройств.При невозможности найти обеспечение на сбойный модуль или узнать, что именно вызывает критическую ошибку (в данном случае драйверы вам придётся переустановить на все основные устройства, начав с видеокарты). Действуйте следующим образом:

Также вы можете попытаться откатить драйверы, иногда это тоже срабатывает (например, после системных обновлений или установки на какое-либо устройство новых версий драйверов).

Используем точку восстановления

Ещё один метод решения проблемы синего экрана — откат Windows 10 через точку восстановления. Обычно ваша операционная система автоматически создаёт файл для отката при установке новых программ или драйверов (с работоспособными параметрами), поэтому этот вариант весьма эффективный. Восстановление настраивается следующим образом:

• Откройте «Панель управления» — «Система». Активируйте пункт «Защита системы».
• В одноимённой вкладке выделите системный диск (обычно это «Локальный диск C») и нажмите «Восстановить».
• В новом окне отметьте «Рекомендуемое восстановление», при этом будут отменены последние обновления, установки драйверов и другого ПО. Нажмите «Далее».
• При необходимости можно посмотреть, какие драйверы и программы затронет восстановление системы, щёлкнув по соответствующему пункту.
• Закройте окно с описанием удаляемого ПО для продолжения.
• Нажмите кнопку «Готово». Дождитесь окончания процесса восстановления системы и перезагрузки компьютера.

Blue Screen возникает во время работы приложения

Если BSOD беспокоит при запуске или во время работы какого-либо приложения (частая проблема с играми), а переустановка драйверов не помогает, попробуйте для записи отладочной информации поставить меньший дамп памяти:

• Из «Панели управления» перейдите в «Систему», где выберите её «Дополнительные параметры системы».
• В «Дополнительно» вам понадобятся «Параметры» из третьего пункта («Загрузка и восстановление»).
• В «Записи отладочной информации» автоматический дамп поменяйте на малый.
• По завершении нажмите «ОК».
• Подтвердите сохранение внесённых изменений («Применить» и «ОК» в свойствах системы). Перезагрузите компьютер и попробуйте вновь запустить сбойную программу или игру.

Альтернативные варианты — обновление проблемного приложения до последней версии или, в крайнем случае, его деинсталляция.

Проверка жёстких дисков

Утилита chkdsk — системный инструмент, встроенный в Windows, проверяющий на ошибки жёсткие диски. Проверяем следующим образом:

• Запустите «Проводник» и откройте свойства диска C (системного).
• После перехода в сервис «Сервис» в «Проверке на наличие ошибок» активируйте соответствующую кнопку.
• Проверьте диск. При сканировании желательно не пользоваться ПК, хоть рекомендация разработчиков Microsoft и гласит иное.
• Проверка и устранение ошибок (если таковые имеются) может занять до нескольких минут.
• По окончании сканирования закройте системное средство проверки. Возможно, компьютер потребуется перезагрузить.
• Аналогичная операция выполняется и в консоли. Для этого в «Пуске» выбирается «Командная строка (Администратор)», затем вводится chkdsk и нажимается Enter.

Более полная проверка диска на наличие «битых» секторов и ошибки осуществляется с программой Victoria.

Проверка ОЗУ на ошибки

Возникновение синего экрана по причине ошибок оперативной памяти встречается реже, но также возможно. Инструкция по проверке ОЗУ:

• Откройте окно программы «Выполнить» (как это сделать, рассмотрено в начале статьи). Введите mdsched.exe и щёлкните «ОК».
• В окне с названием «Средство проверки памяти Windows» активируйте первый пункт и дождитесь перезагрузки системы.

Более досконально исследовать оперативную память позволяет программа MemTest86.

Сброс до заводских настроек

Если не помогли предыдущие методы, рекомендуется откатить систему к исходным настройкам. Имейте в виду, что при этом удалятся всё программное обеспечение плюс драйверы, которые устанавливали вы. Личная информация — документы, медиа и прочие файлы — не пострадает. Для запуска восстановления:

• Активируйте «Параметры» (значок с шестерёнкой) из меню «Пуск».
• В стартовом окне программы щёлкните «Обновление и безопасность».
• Выберите «Восстановление».
• Начните возвращение компьютера в исходное состояние соответствующей кнопкой.
• Если хотите сохранить свои файлы, выбирайте в следующем окне нужный параметр, при котором удаление ограничится параметрами и приложениями.
• Подтвердите возврат ПК к заводским настройкам.

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

Дополнительная полезная информация по устранению BSOD

Когда вышеописанные способы не срабатывают и ваш компьютер всё так же вываливается в BSOD, с большой долей вероятности можно предположить, что причина синего экрана кроется в «железе».Если вы дружите с техникой, то поиск и устранение неисправностей вполне можете осуществить своими силами, если не знаете, что такое мультиметр, падение напряжения, системная плата, BIOS и блок питания, лучше обратитесь к специалистам.Примерный алгоритм действий поиска и устранения неисправностей таков:На самом деле в Windows 10 «синий экран смерти» по существу таковым не является. Это сообщение пользователю с указанием проблемы и подсказкой по её решению. Описанные в статье методы, как правило, позволяют просто и эффективно нейтрализовать все неполадки.

Ряд пользователей Windows 10 может столкнуться с синим экраном смерти, на котором, кроме предупреждения о возникшей проблеме, может быть размещён QR-код и ссылка на ресурс «Windows.com/stopcode». Появиться такой экран может достаточно внезапно, после чего компьютер часто перезагружается, и проблема повторяется вновь. Что же делать в такой ситуации? В данном материале я расскажу, что такое Windows.com/stopcode, каковы причины его появления и как исправить ошибку на вашем ПК.

Синий экран с Windows.com/stopcode

Автор majli_pudge (Майли Варлок) напишите мне на почту (costigan991@gmail.com), у меня к вам есть интересное предложение. И откажитесь от данного задания.

Что такое Windows.com/stopcode

Примерно с весны 2016 года компания Mайкрософт решила внести некоторые изменения в механизм появления BSoD (синего экрана смерти). Теперь, кроме самого текста об ошибке, BSoD в Виндовс 10 также комплектуется QR-кодом и ссылкой на ресурс Windows.com/stopcode.

Указанный QR-код, будучи считанным с помощью смартфона, открывает уже упомянутую ссылку, по переходе на которую пользователь (в идеале) должен встретить страницу, описывающую причины возникшей проблемы, а также эффективные варианты её решения.

Ныне функционал страницы Windows.com/stopcode проработан далеко не полностью, перейдя по данной ссылке пользователь встретит лишь пару базисных шаблонов решения проблемы (например, установить все имеющиеся обновления для ОС, отключить недавно подключенные к ПК устройства и так далее).

По переходу на Windows.com/stopcode пользователь видит вот такой экран

Причины появления ошибки stopcode

Причины появления «синего экрана» с Windows.com/stopcode обычно разнятся и могут быть следующими:

• Проблема с драйверами (некорректный драйвер, конфликт драйверов и др.);
• Проблема с планками памяти (нестабильная работа, выход из строя и др.);
• Неудачное обновление ОС Виндовс;
• Отсутствие всех необходимых обновлений для вашей версии ОС Виндовс;
• Злокачественное действие вирусных программ;
• Повреждение системного реестра;
• Перегрев системы (часто вследствие оверклокинга, засорения системы охлаждения и так далее);
• Физическая поломка какого-либо компонента системы (материнская плата, видеокарта и др.) и так далее.

  Ошибка Виндовс

Как исправить Windows.com/stopcode

Решение проблемы Windows 10 stopcode может находиться в самом тексте «синего экрана», где часто упомянута специфика ошибки (например: SYSTEM_SERVICE_EXCEPTION или код 80070002). Проблемой здесь может стать постоянная перезагрузка ПК после появления BSoD, которая не даёт пользователю полноценно идентифицировать проблему. В таком случае, после появления BSoD, нужно быстро нажать на клавиатурную кнопку «Pause», и тщательно просмотреть содержимое «синего экрана». Если там будет находиться какая-либо детальная информация о причине BSoD, то её необходимо записать, а затем поискать информацию по её специфике на специализированных ресурсах.

Используйте функционал кнопки «Pause»

Более же общей рецептурой решения проблемы Windows.com/stopcode может стать следующее:

• Если система попросту не загружается, тогда попробуйте использовать стандартные инструменты для восстановления системы, имеющиеся в Виндовс 10 (к примеру, через «Дополнительные параметры» — «Поиск и устранение неисправностей» — «Дополнительные параметры» — «Восстановление системы»);

  Используем «Восстановление системы

• Проверьте корректность установленных в системе драйверов, для чего пригодится встроенная в систему утилита Driver Verifier.

1. Для работы с ней нажмите на кнопку «Пуск», в строке поиска введите verifier и нажмите ввод.
2. После запуска выберите «Создать нестандартные параметры», нажмите «Далее», проставьте всюду галочки кроме «Проверка соответствия DDI» (DDI compliance checking), затем вновь кликните на «Далее».
3. Выберите  «Выбрать имена драйверов из полного списка» (Select driver names from a list) и снова нажмите на «Далее».
4. В списке драйверов выберите все драйвера за исключением от Microsoft и нажмите на «Finish».
5. Система осуществит проверку драйверов, и, вполне возможно, найдёт виновника, от которого будет необходимо избавиться, заменив на более корректный аналог.

Устанавливаем все необходимые галочки

Также можно будет использовать соответствующие программы для автоматической установки свежих драйверов, что поможет установить их свежие версии (Driverpack Solution, Driver Genius и другие).

• Воспользуйтесь функционалом утилиты «Memtest» для проверки работоспособности памяти вашего ПК. Если проблема будет в какой-то из планок памяти, её необходимо будет заменить;
• Установите все обновления для вашей версии ОС;
• Если «синий экран» стал появляться после установки какого-либо из обновлений ОС, деинсталлируйте данное обновление с вашего компьютера;
• Отключите недавно подключенные к ПК устройства (внешние или внутренние), если таковые имеются;
• Откатите систему до точки восстановления, при которой она работала корректно. Нажмите на «Пуск», в строке поиска введите rstrui и нажмите ввод. Выберите стабильную точку восстановления, и откатите систему на указанное состояние.

  Выберите приемлемую точку восстановления

Заключение

Появление ссылки http://www.windows.com/stopcode в BSoD было обусловлено желанием компании Майкрософт решить возникающие в ОС Виндовс проблемы, приводящие к появлению «синего экрана смерти». С помощью перехода по данной ссылке пользователь получал бы детальное описание решения проблемы, что могло помочь в её исправлении. На данном же этапе переход по данной ссылке является малоинформативным, так как знакомит читателя лишь с несколькими базовыми клише по устранению ошибки, и, де факто, не даёт полноценного ответа на вопрос о решении Windows.com/stopcode. Рекомендую воспользоваться советами, которые я перечислил выше, вполне возможно, что они помогут избежать появления «синего экрана смерти» на ваших ПК.

Информация к новости

• Просмотров: 37 660
• Автор: admin
• Дата: 26-09-2017

Изменил: admin26-09-2017

Категория: Windows 10 / Функционал Windows / Программы

Привет друзья! Первый раз я увидел Синий экран смерти ещё будучи студентом в 1998 году, тогда мы только учились работать в Windows 98. Наш наставник шутил над нами, вводя вручную команду C:concon в окне «Выполнить», после этого появлялся BSOD, затем нам предлагалось устранить ошибку и конечно у нас ничего не получалось. Шутки шутками, но уже реально столкнувшись с этой ошибкой я понял, что Blue Screen буквально обозначает гибель системы, так как восстановить её к жизни было очень трудно.О синем экране смерти со времён Windows XP написано множество статей, но применить к Windows 10 что-либо из написанного вряд ли получится, настолько эта система новая. Синий экран смерти, он же «синяя смерть», он же Blue Screen, он же BSOD – это системное уведомление о произошедшей критической ошибке в работе Windows, отображаемое на синем фоне экрана, отчего, собственно, уведомление и получило название (англ.) Blue Screen of Death (BSOD), то есть синий экран смерти. В эпоху расцвета Windows XP и её версий-предшественниц BSOD мог возникнуть и по пустяковым причинам. Смерть системы в её современных версиях почти всегда является обязательным следствием возникновения серьёзной ошибки и уже не появляется по пустякам, но несмотря на это вернуть ОС к жизни всё же можно.За последние 20 лет, работая ещё в Windows 2000, Me, XP, Vista, 7, 8.1, 10, конечно мне приходилось сталкиваться с ошибками синего экрана. К счастью, часто удавалось решить проблему не прибегая к переустановке ОС и сегодня я покажу вам реальный пример возвращения к жизни операционной системы Windows 10 после получения ошибки BSOD.

Какие причины обуславливают появление BSOD в актуальной Windows 10? Как определить их и устранить?

Итак, разберём в подробностях пример возвращения Windows 10 к жизнипосле критической ошибки на синем экране.Работать будем с реальным ноутбуком, который принесли мне на ремонт. На данном ноуте без видимой причины стал появляться BSOD с кодом остановки: 0xc00002e3.

Ноутбук несколько раз перезагружался и затем запускал автоматическое восстановление, но безрезультатно. Хочу сказать, что в большинстве подобных случаев явной причины появления синего экрана почти никогда нет, то есть на вашем компьютере не менялась аппаратная начинка, не проникали вирусы, никаких настроек не вносилось, не происходило никаких иных событий, которые можно было бы логически связать с BSOD, но он всё-таки появился! Сузить поле поиска корня проблемы помогут стоп-коды.

Стоп-коды BSOD

Стоп-коды BSOD – это текстовые и цифровые формулировки ошибки. Их пользователи 7, Vista, XP и более ранних версий Windows могли наблюдать непосредственно на синем экране. 

Начиная с версии системы 8, Microsoft изменила дизайн BSOD. Чем не угодил старый дизайн? Дело в том, что на нём и стандартная формулировка уведомления, и непосредственно стоп-коды отображались одним шрифтом. Это усложняло восприятие информации за ограниченное время отображения BSOD. Причём ещё и всё было на английском языке, что дополнительно вводило в ступор русскоязычных пользователей. Разрабатывая Windows 8, Microsoft посчитала, что пользователи менее критично будут воспринимать синий экран смерти, если на него добавить грустный смайлик. А чтобы упростить запоминание важных данных, компания убрала цифровые стоп-коды, оставив только буквенный. Расчёт был на то, что текстовое описание ошибки, в принципе, можно запомнить. И затем отыскать по нему справку в Интернете.

Но реально стоящие изменения касательно BSOD софтверному гиганту удалось внести лишь в 2016 году в версию Windows 10. Накопительное обновление Anniversary Update добавило на синий экран смерти QR-код ошибки, который пользователь может считать смартфоном. Конечно, если тот окажется под рукой.

QR-код в будущем будет отправлять пользователя на специальный сайт Microsoft http://windows.com/stopcode — нечто глобального хранилища справочной информации по всем возможным стоп-кодам BSOD. А пока хранилище формируется, его роль временно выполняет общий ресурс техподдержки Microsoft и форум Microsoft Community.

QR-код

Итак, на компьютере с Windows 10 появился синий экран смерти — хватаем смартфон и считываем QR-код. Если такой возможности нет, но операционная система загружается, дожидаемся загрузки и действуем другими способами (случаи, когда ОС не загружается мы тоже рассмотрим с вами далее в статье).

Средство автоматического устранения неполадок

Anniversary Update не только привнесло в Windows 10 реализацию QR-кодов для упрощения поиска информации о причинах появления BSOD. Обновление также пополнило арсенал автоматических инструментов устранения неполадок средством для выявления причин синего экрана. Это средство можно отыскать в панели управления версии системы 10, прописав в ней ключевой запрос «экран».

Запустится утилита «Синий экран». Кликаем надпись по центру окна «Дополнительно» и снимаем галочку автоматического применения исправлений. Это необходимо для запуска средства в диагностическом режиме и, соответственно, получения информации о причинах появления BSOD.

Извлечение информации из минидампов BSOD с помощью утилиты BlueScreenView

Важно знать, что при возникновении синего экрана операционная система сохраняет полный или малый аварийные дампы памяти в специальных файлах. Полный дамп сохраняется в папке C:Windows и имеет название Memory.dmp.При появлении новой критической ошибки предыдущий файл перезаписывается новым файлом.

Малый дамп сохраняется в папке C:WindowsMinidump имеет примерно такое название 092517-15843-01.dmp. При появлении новой критической ошибки предыдущий файл не перезаписывается, а создаётся заново.

Так вот, существует такая утилита — BlueScreenView, которая способна извлечь из аварийного дампа памяти полную информацию о файлах виновниках появления синего экрана на вашем компьютере. Отправляемся на официальный сайт утилиты BlueScreenView:http://www.nirsoft.net/utils/blue_screen_view.html#DownloadLinks 

Скачиваем её саму и файл русификации. Русификатор помещаем в папку с утилитой и запускаем её.

В окне утилиты увидим перечень минидампов – по сути, случаев появления BSOD. Ориентируясь на время и дату его возникновения, выбираем нужный. Если синий экран в последнее время зачастил, можем просто выбрать последний минидамп. Двойным кликом левой кнопки мыши открываем его свойства. Графы, выделенные на скриншоте ниже, являются значимыми для определения причины BSOD. В свойствах минидампа также указывается драйвер причины BSOD.

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

Если причина появления BSOD по этим исходным данным не обнаружится, с помощью утилиты в Google можно отправить запрос по текстовому и цифровым стоп-кодам.

• Примечание: друзья, если вы ищите информацию в Google, но не владеете достаточным уровнем знания английского, не забывайте в самом поисковике выставлять фильтрацию результатов на русском языке. Или копируйте поисковой запрос в Яндекс.

Стоп-коды также можно извлечь, представив минидамп в формате синего экрана смерти Windows 7 и версий постарше. Для этого в окне утилиты необходимо нажать F8.

Для возврата в исходное представление данных жмём F6.Как я заметил в начале статьи, иногда Windows 10 при появлении критической ошибки на синем экране может создать полный дамп памяти — Memory.dmp и находиться он будет в папке C:Windows. В этом случае программа BlueScreenView может не открыть его автоматически. Тогда откройте его вручную. Для этого нажмите на кнопку «Advanced Startup Options»

Двойным кликом левой кнопки мыши открываем свойства полного дампа памяти.

В некоторых случаях в свойствах минидампа не будет указан драйвер причины BSOD (пункт Caused By Driver).

Точно таким же способом вы можете просмотреть дамп памяти с другого компьютера. Просто копируйте дамп памяти с другой машинысебе на флешку и уже находясь в своей системе укажите программе BlueScreenView файл на флешке.

• Примечание: друзья, любую найденную в Интернете информацию по стоп-кодам синего экрана необходимо сопоставлять с ближайшими событиями, которые происходили с компьютером. Причём это касается не только аппаратного вмешательства, но также программного. Что в систему устанавливалось, что и каким образом удалялось, какие настройки проводились — всё это может иметь значение для выявления причины BSOD.

Замечу, что в некоторых случаях аварийный дамп памяти может быть сбойным и вам не удастся его открыть, возникнет ошибка The following client application error has occurred. Что делать в этом случае, читайте далее в статье.

Теперь давайте рассмотрим способы восстановления ОС после возникновения критической ошибки.

Как победить синий экран в Windows 10, если операционная система не загружается

Друзья, вот это настоящая проблема, которую довольно сложно разрешитьначинающему пользователю. Остановимся здесь поподробнее.Какая бы причина возникновения синего экрана в вашей операционной системе не была, решить её зачастую можно с помощью восстановления системы (конечно за исключением неисправного железа). Вспомним клиентский ноутбук, о котором я говорил в начале статьи. На этом ноутбуке внезапно стал появляться BSOD с кодом остановки: 0xc00002e3.Ноутбук несколько раз перезагружался и затем система делала попытки восстановить его автоматически, но безрезультатно. Найти причину ошибки 0xc00002e3 в интернете мне не удалось, слишком много файлов могли вызвать подобный сбой и я решил поступить так.

Жмём на «Дополнительные параметры»

Поиск и устранение неисправностей.

Дополнительные параметры.

Восстановление системы.

Далее. 

Выбираем точку восстановления. Например, синий экран возник на моём ноутбуке 25.09.2017, значит точку я выберу от 18 числа.

Готово. 

Да. 

Успешно. Перезагружаемся. 

Загружается Windows 10.

Что делать, если система не предлагает «Дополнительные параметры» для восстановления

Не всё так бывает гладко и часто система не предлагает «Дополнительные параметры» для восстановления,

а снова рекомендует применить «Автоматическое восстановление». Если нажать «Восстановить», то запустится 

«Устранение неполадок», которое будет длиться бесконечно долго и может закончится ничем.

В этом случае стоит попробовать другое решение.

Создаём загрузочную флешку с Windows 10 и загружаем с неё компьютер.

Далее.

Восстановление системы. 

Поиск и устранение неисправностей. 

Затем точно также как и в предыдущем примере применяем откат точкой восстановления системы. 

В некоторых случаях вас будет ждать неудача и вы при восстановлении получите ошибку.

В этом случае поступим по другому.

Загрузка в безопасном режиме

Загрузится в Safe Mode можно даже тогда, когда Win 10 не загружается. В безопасном режиме функционируют только основные системные службы и драйвера, принадлежащие самой ОС. Часто причиной BSOD выступают программы и драйвера сторонних разработчиков, а в безопасном режиме они не работают, поэтому есть шанс загрузится в систему и применить чистую загрузку Windows, при которой система запускается без программ и служб сторонних разрабов. Уже затем можно по одному включать в загрузку приложения и так определить виновное в появлении синего экрана. Обнаруженную проблемную программу или драйвер удалите.

Не буду повторяться и просто дам вам ссылку на свою статью — безопасный режим Windows 10 при сбое загрузки ОС. Также даю ссылку на статью — как произвести чистую загрузку Windows 10.

Идеальный вариант — восстановить Windows 10 с помощью резервного бэкапа

Если вы хорошо владеете программами резервного копирования данных и периодически создаёте бэкапы своей OS, то просто откатитесь с помощью последней созданной резервной копии. Создавать бэкапы можно встроенными в ОС средствами, а также приложениями сторонних разработчиков.

Как просмотреть информацию в аварийном дампе памяти, если Windows не загружается

Однажды один читатель спросил меня, как прочитать информацию в дампе памяти, если ОС не загружается. Желание понятно, человек хотел узнать причину возникновения синего экрана и действовать дальше по обстановке. К примеру, если бы это оказался конкретный системный файл, то он бы просто заменил его оригинальной версией. Сделать это можно так.Загрузить проблемный компьютер с нашего фирменного LiveCD(из него можно сделать загрузочную флешку).

Открыть папку «Софт». 

Запустить утилиту BlueScreenView.

Нажмите на кнопку «Advanced Options».  

Отметьте пункт «Load a single MiniDump File: и жмите кнопку «Browse».

Откроется Проводник. Найдите в нём Полный дамп памяти Memory.dmp в папке C:Windows или Малый дамп в папке C:WindowsMinidump.

Выделите его левой кнопкой мыши и нажмите «Open».

ОК. 

Двойным щелчком левой мыши откройте свойства дампа памяти. 

Откроются все подробности ошибки BSOD. 

В конце статьи рассмотрим частые причины BSOD и способы их устранения 

В Windows 10 изменился только дизайн синего экрана смерти, а вот частные причины его появления такие же, как и в версиях-предшественницах. Что это за причины и как они устраняются?1. Повреждение системных файловBSOD может вылетать, если вследствие проникновения вирусов или внедрения сторонних программ повредятся значимые для работы системы файлы. Решение в таком случае – восстановление целостности системных файлов, сделать это можно даже, если ОС не загружается.2. Конфликт ПОСиний экран может быть следствием запуска на компьютере двух конфликтующих программ, например, двух антивирусов, двух программ типа «Неубиваемая Windows» или двух гипервизоров. Кстати, конфликт последних как раз таки и был причиной появления BSOD в нашем тестовом случае. Установленный в Windows 10 Hyper-V препятствовал установке в систему различных Android-эмуляторов. Конфликтовать также могут драйверы, сторонние программы с системными компонентами. Решение в таком случае – отказаться от конфликтующей программы, попробовать её другие версии или аналоги.3. Некорректная работа драйверовВызывать BSOD могут проблемные драйверы – некорректно написанные, старые, новые (толком не протестированные альфа-версии) и т.п. Решение в таком случае – переустановка или обновление драйвера с использованием дистрибутива с официального источника.4. Неудачное обновлениеНеудачные обновления могут иметь разные последствия, включая BSOD. Если Microsoft сама не решит эту проблему путём исправления обновления, поможет восстановление Windows 10.5. Установка на слабый компьютер ресурсоёмких игрПрежде установки на компьютер серьёзных игр следует выяснить, отвечает ли система хотя бы минимальным аппаратным их требованиям. Игра на слабый ПК или ноутбук может установиться, но при запуске выдавать BSOD.  6. ПерегревСиний экран – это естественная реакция Windows на перегрев комплектующих компьютера, в частности, процессора, видеокарты, жёсткого диска. Необходимо устранять причину перегрева.7. Настройки BIOSНеверные настройки BIOS могут вызывать синий экран, а в некоторых случаях, как, например, при смене режима контроллера SATA (IDE / AHCI / RAID), даже воспрепятствуют загрузке Windows. В приведённом примере проблема может быть решена твиком системного реестра, но лучше, конечно, чтобы Windows устанавливалась на уже произведённые настройки BIOS. Если не удаётся вспомнить, какие настройки менялись, можно сбросить BIOS к дефолтным настройкам.8. Контакты внутри системника BSOD может возникать из-за окисленных, плохо прижатых или повреждённых контактов. Контакты нужно аккуратно почистить ластиком, проверить все соединения, возможно, переключить шлейфы в другие порты материнской платы.9. РазгонСиний экран нередко возникает после разгона процессора или видеокарты. Нужно пересмотреть параметры разгона.10. Несовместимость и неисправности комплектующихЕсли аппаратный арсенал компьютера недавно был пополнен планкой несовместимой оперативной памяти, BSOD обязательно даст об этом знать. Подтвердить подозрения поможет тестирование оперативной памяти. Решение в таком случае – замена планки на совместимую.Синий экран может свидетельствовать об аппаратных неполадках компьютера, к примеру, о повреждении процессора, материнской платы, блока питания, жёсткого диска. Но только последний, не обладая специальными навыками, можно проверить в домашних условиях. Например, протестировать программой Виктория. По поводу остального железа лучше обратиться к специалистам.Друзья, утилита BlueScreenView не одна может производить анализ дампов памяти и в следующей статье мы рассмотрим пакет Debugging Tools for Windows, способный извлечь из аварийного дампа намного больше информации.Также читайте статью — Как узнать причину возникновения синего экрана смерти (BSOD) в случае, если Windows 10 не загружается. Или как пользоваться инструментом «Анализатор сбоев» загрузочного диска восстановления Microsoft Diagnostic and Recovery Toolset 10 x64 (MSDaRT)ВернутьсяКомментариев: 13 Дорогой посетитель, Вы можете задать на сайте любой вопрос и обязательно получите ответ! Используемые источники:

• https://masterservis24.ru/309-siniy-ekran-smerti-windows-10.html
• https://lifehacki.ru/windows-comstopcode-kak-reshit/
• https://remontcompa.ru/windows/windows-10/1344-siniy-ekran-v-windows-10.html