Как найти ошибку в коде windows - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

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

Шаг 1: Занесите ошибку в трекер

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

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

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

Вы должны записать в трекер следующую информацию:

Что делал пользователь.
Что он ожидал увидеть.
Что случилось на самом деле.

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

Шаг 2: Поищите сообщение об ошибке в сети

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

Шаг 3: Найдите строку, в которой проявляется ошибка

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

Шаг 4: Найдите точную строку, в которой появилась ошибка

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

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

Шаг 5: Выясните природу ошибки

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

Ошибка на единицу
Вы начали цикл for с единицы вместо нуля или наоборот. Или, например, подумали, что метод .count() или .length() вернул индекс последнего элемента. Проверьте документацию к языку, чтобы убедиться, что нумерация массивов начинается с нуля или с единицы. Эта ошибка иногда проявляется в виде исключения Index out of range.
Состояние гонки
Ваш процесс или поток пытается использовать результат выполнения дочернего до того, как тот завершил свою работу. Ищите использование sleep() в коде. Возможно, на мощной машине дочерний поток выполняется за миллисекунду, а на менее производительной системе происходят задержки. Используйте правильные способы синхронизации многопоточного кода: мьютексы, семафоры, события и т. д.
Неправильные настройки или константы
Проверьте ваши конфигурационные файлы и константы. Я однажды потратил ужасные 16 часов, пытаясь понять, почему корзина на сайте с покупками виснет на стадии отправки заказа. Причина оказалась в неправильном значении в /etc/hosts, которое не позволяло приложению найти ip-адрес почтового сервера, что вызывало бесконечный цикл в попытке отправить счет заказчику.
Неожиданный null
Бьюсь об заклад, вы не раз получали ошибку с неинициализированной переменной. Убедитесь, что вы проверяете ссылки на null, особенно при обращении к свойствам по цепочке. Также проверьте случаи, когда возвращаемое из базы данных значение NULL представлено особым типом.
Некорректные входные данные
Вы проверяете вводимые данные? Вы точно не пытаетесь провести арифметические операции с введенными пользователем строками?
Присваивание вместо сравнения
Убедитесь, что вы не написали = вместо ==, особенно в C-подобных языках.
Ошибка округления
Это случается, когда вы используете целое вместо Decimal, или float для денежных сумм, или слишком короткое целое (например, пытаетесь записать число большее, чем 2147483647, в 32-битное целое). Кроме того, может случиться так, что ошибка округления проявляется не сразу, а накапливается со временем (т. н. Эффект бабочки).
Переполнение буфера и выход за пределы массива
Проблема номер один в компьютерной безопасности. Вы выделяете память меньшего объема, чем записываемые туда данные. Или пытаетесь обратиться к элементу за пределами массива.
Программисты не умеют считать
Вы используете некорректную формулу. Проверьте, что вы не используете целочисленное деление вместо взятия остатка, или знаете, как перевести рациональную дробь в десятичную и т. д.
Конкатенация строки и числа
Вы ожидаете конкатенации двух строк, но одно из значений — число, и компилятор пытается произвести арифметические вычисления. Попробуйте явно приводить каждое значение к строке.
33 символа в varchar(32)
Проверяйте данные, передаваемые в INSERT, на совпадение типов. Некоторые БД выбрасывают исключения (как и должны делать), некоторые просто обрезают строку (как MySQL). Недавно я столкнулся с такой ошибкой: программист забыл убрать кавычки из строки перед вставкой в базу данных, и длина строки превысила допустимую как раз на два символа. На поиск бага ушло много времени, потому что заметить две маленькие кавычки было сложно.
Некорректное состояние
Вы пытаетесь выполнить запрос при закрытом соединении или пытаетесь вставить запись в таблицу прежде, чем обновили таблицы, от которых она зависит.
Особенности вашей системы, которых нет у пользователя
Например: в тестовой БД между ID заказа и адресом отношение 1:1, и вы программировали, исходя из этого предположения. Но в работе выясняется, что заказы могут отправляться на один и тот же адрес, и, таким образом, у вас отношение 1:многим.

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

Шаг 6: Метод исключения

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

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

Шаг 7: Логгируйте все подряд и анализируйте журнал

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

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

Шаг 8: Исключите влияние железа или платформы

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

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

Ради интереса, переключите кабель питания в другую розетку или к другому ИБП. Безумно? Почему бы не попробовать?

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

Шаг 9: Обратите внимание на совпадения

Ошибка появляется всегда в одно и то же время? Проверьте задачи, выполняющиеся по расписанию.
Ошибка всегда проявляется вместе с чем-то еще, насколько абсурдной ни была бы эта связь? Обращайте внимание на каждую деталь. На каждую. Например, проявляется ли ошибка, когда включен кондиционер? Возможно, из-за этого падает напряжение в сети, что вызывает странные эффекты в железе.
Есть ли что-то общее у пользователей программы, даже не связанное с ПО? Например, географическое положение (так был найден легендарный баг с письмом за 500 миль).
Ошибка проявляется, когда другой процесс забирает достаточно большое количество памяти или ресурсов процессора? (Я однажды нашел в этом причину раздражающей проблемы «no trusted connection» с SQL-сервером).

Шаг 10: Обратитесь в техподдержку

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

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

Полезные советы (когда ничего не помогает)

Позовите кого-нибудь еще.
Попросите коллегу поискать ошибку вместе с вами. Возможно, он заметит что-то, что вы упустили. Это можно сделать на любом этапе.
Внимательно просмотрите код.
Я часто нахожу ошибку, просто спокойно просматривая код с начала и прокручивая его в голове.
Рассмотрите случаи, когда код работает, и сравните их с неработающими.
Недавно я обнаружил ошибку, заключавшуюся в том, что когда вводимые данные в XML-формате содержали строку xsi:type='xs:string', все ломалось, но если этой строки не было, все работало корректно. Оказалось, что дополнительный атрибут ломал механизм десериализации.
Идите спать.
Не бойтесь идти домой до того, как исправите ошибку. Ваши способности обратно пропорциональны вашей усталости. Вы просто потратите время и измотаете себя.
Сделайте творческий перерыв.
Творческий перерыв — это когда вы отвлекаетесь от задачи и переключаете внимание на другие вещи. Вы, возможно, замечали, что лучшие идеи приходят в голову в душе или по пути домой. Смена контекста иногда помогает. Сходите пообедать, посмотрите фильм, полистайте интернет или займитесь другой проблемой.
Закройте глаза на некоторые симптомы и сообщения и попробуйте сначала.
Некоторые баги могут влиять друг на друга. Драйвер для dial-up соединения в Windows 95 мог сообщать, что канал занят, при том что вы могли отчетливо слышать звук соединяющегося модема. Если вам приходится держать в голове слишком много симптомов, попробуйте сконцентрироваться только на одном. Исправьте или найдите его причину и переходите к следующему.
Поиграйте в доктора Хауса (только без Викодина).
Соберите всех коллег, ходите по кабинету с тростью, пишите симптомы на доске и бросайте язвительные комментарии. Раз это работает в сериалах, почему бы не попробовать?

Что вам точно не поможет

Паника
Не надо сразу палить из пушки по воробьям. Некоторые менеджеры начинают паниковать и сразу откатываться, перезагружать сервера и т. п. в надежде, что что-нибудь из этого исправит проблему. Это никогда не работает. Кроме того, это создает еще больше хаоса и увеличивает время, необходимое для поиска ошибки. Делайте только один шаг за раз. Изучите результат. Обдумайте его, а затем переходите к следующей гипотезе.
«Хелп, плиииз!»
Когда вы обращаетесь на форум за советом, вы как минимум должны уже выполнить шаг 3. Никто не захочет или не сможет вам помочь, если вы не предоставите подробное описание проблемы, включая информацию об ОС, железе и участок проблемного кода. Создавайте тему только тогда, когда можете все подробно описать, и придумайте информативное название для нее.
Переход на личности
Если вы думаете, что в ошибке виноват кто-то другой, постарайтесь по крайней мере говорить с ним вежливо. Оскорбления, крики и паника не помогут человеку решить проблему. Даже если у вас в команде не в почете демократия, крики и применение грубой силы не заставят исправления магическим образом появиться.

Ошибка, которую я недавно исправил

Это была загадочная проблема с дублирующимися именами генерируемых файлов. Дальнейшая проверка показала, что у файлов различное содержание. Это было странно, поскольку имена файлов включали дату и время создания в формате yyMMddhhmmss. Шаг 9, совпадения: первый файл был создан в полпятого утра, дубликат генерировался в полпятого вечера того же дня. Совпадение? Нет, поскольку hh в строке формата — это 12-часовой формат времени. Вот оно что! Поменял формат на yyMMddHHmmss, и ошибка исчезла.

_{Перевод статьи «How to fix bugs, step by step»}

Источник

Представляем перевод статьи «How to fix bugs, step by step», опубликованный сайтом tproger.ru.

Шаг 1: Занесите ошибку в трекер

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

Вы должны записать в трекер следующую информацию:

Что делал пользователь.
Что он ожидал увидеть.
Что случилось на самом деле.

Шаг 2: Поищите сообщение об ошибке в сети

Шаг 3: Найдите строку, в которой проявляется ошибка

Шаг 4: Найдите точную строку, в которой появилась ошибка

Шаг 5: Выясните природу ошибки

Ошибка на единицу
Вы начали цикл for с единицы вместо нуля или наоборот. Или, например, подумали, что метод .count() или .length() вернул индекс последнего элемента. Проверьте документацию к языку, чтобы убедиться, что нумерация массивов начинается с нуля или с единицы. Эта ошибка иногда проявляется в виде исключения Index out of range.
Состояние гонки
Ваш процесс или поток пытается использовать результат выполнения дочернего до того, как тот завершил свою работу. Ищите использование sleep() в коде. Возможно, на мощной машине дочерний поток выполняется за миллисекунду, а на менее производительной системе происходят задержки. Используйте правильные способы синхронизации многопоточного кода: мьютексы, семафоры, события и т. д.
Неправильные настройки или константы
Проверьте ваши конфигурационные файлы и константы. Я однажды потратил ужасные 16 часов, пытаясь понять, почему корзина на сайте с покупками виснет на стадии отправки заказа. Причина оказалась в неправильном значении в /etc/hosts, которое не позволяло приложению найти ip-адрес почтового сервера, что вызывало бесконечный цикл в попытке отправить счет заказчику.
Неожиданный null
Бьюсь об заклад, вы не раз получали ошибку с неинициализированной переменной. Убедитесь, что вы проверяете ссылки на null, особенно при обращении к свойствам по цепочке. Также проверьте случаи, когда возвращаемое из базы данных значение NULL представлено особым типом.
Некорректные входные данные
Вы проверяете вводимые данные? Вы точно не пытаетесь провести арифметические операции с введенными пользователем строками?
Присваивание вместо сравнения
Убедитесь, что вы не написали = вместо ==, особенно в C-подобных языках.
Ошибка округления
Это случается, когда вы используете целое вместо Decimal, или float для денежных сумм, или слишком короткое целое (например, пытаетесь записать число большее, чем 2147483647, в 32-битное целое). Кроме того, может случиться так, что ошибка округления проявляется не сразу, а накапливается со временем (т. н. Эффект бабочки).
Переполнение буфера и выход за пределы массива
Проблема номер один в компьютерной безопасности. Вы выделяете память меньшего объема, чем записываемые туда данные. Или пытаетесь обратиться к элементу за пределами массива.
Программисты не умеют считать
Вы используете некорректную формулу. Проверьте, что вы не используете целочисленное деление вместо взятия остатка, или знаете, как перевести рациональную дробь в десятичную и т. д.
Конкатенация строки и числа
Вы ожидаете конкатенации двух строк, но одно из значений — число, и компилятор пытается произвести арифметические вычисления. Попробуйте явно приводить каждое значение к строке.
33 символа в varchar(32)
Проверяйте данные, передаваемые в INSERT, на совпадение типов. Некоторые БД выбрасывают исключения (как и должны делать), некоторые просто обрезают строку (как MySQL). Недавно я столкнулся с такой ошибкой: программист забыл убрать кавычки из строки перед вставкой в базу данных, и длина строки превысила допустимую как раз на два символа. На поиск бага ушло много времени, потому что заметить две маленькие кавычки было сложно.
Некорректное состояние
Вы пытаетесь выполнить запрос при закрытом соединении или пытаетесь вставить запись в таблицу прежде, чем обновили таблицы, от которых она зависит.
Особенности вашей системы, которых нет у пользователя
Например: в тестовой БД между ID заказа и адресом отношение 1:1, и вы программировали, исходя из этого предположения. Но в работе выясняется, что заказы могут отправляться на один и тот же адрес, и, таким образом, у вас отношение 1:многим.

Шаг 6: Метод исключения

Шаг 7: Логгируйте все подряд и анализируйте журнал

Шаг 8: Исключите влияние железа или платформы

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

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

Шаг 9: Обратите внимание на совпадения

Ошибка появляется всегда в одно и то же время? Проверьте задачи, выполняющиеся по расписанию.
Ошибка всегда проявляется вместе с чем-то еще, насколько абсурдной ни была бы эта связь? Обращайте внимание на каждую деталь. На каждую. Например, проявляется ли ошибка, когда включен кондиционер? Возможно, из-за этого падает напряжение в сети, что вызывает странные эффекты в железе.
Есть ли что-то общее у пользователей программы, даже не связанное с ПО? Например, географическое положение (так был найден легендарный баг с письмом за 500 миль).
Ошибка проявляется, когда другой процесс забирает достаточно большое количество памяти или ресурсов процессора? (Я однажды нашел в этом причину раздражающей проблемы «no trusted connection» с SQL-сервером).

Шаг 10: Обратитесь в техподдержку

Полезные советы (когда ничего не помогает)

Позовите кого-нибудь еще.
Попросите коллегу поискать ошибку вместе с вами. Возможно, он заметит что-то, что вы упустили. Это можно сделать на любом этапе.
Внимательно просмотрите код.
Я часто нахожу ошибку, просто спокойно просматривая код с начала и прокручивая его в голове.
Рассмотрите случаи, когда код работает, и сравните их с неработающими.
Недавно я обнаружил ошибку, заключавшуюся в том, что когда вводимые данные в XML-формате содержали строку xsi:type='xs:string', все ломалось, но если этой строки не было, все работало корректно. Оказалось, что дополнительный атрибут ломал механизм десериализации.
Идите спать.
Не бойтесь идти домой до того, как исправите ошибку. Ваши способности обратно пропорциональны вашей усталости. Вы просто потратите время и измотаете себя.
Сделайте творческий перерыв.
Творческий перерыв — это когда вы отвлекаетесь от задачи и переключаете внимание на другие вещи. Вы, возможно, замечали, что лучшие идеи приходят в голову в душе или по пути домой. Смена контекста иногда помогает. Сходите пообедать, посмотрите фильм, полистайте интернет или займитесь другой проблемой.
Закройте глаза на некоторые симптомы и сообщения и попробуйте сначала.
Некоторые баги могут влиять друг на друга. Драйвер для dial-up соединения в Windows 95 мог сообщать, что канал занят, при том что вы могли отчетливо слышать звук соединяющегося модема. Если вам приходится держать в голове слишком много симптомов, попробуйте сконцентрироваться только на одном. Исправьте или найдите его причину и переходите к следующему.
Поиграйте в доктора Хауса (только без Викодина).
Соберите всех коллег, ходите по кабинету с тростью, пишите симптомы на доске и бросайте язвительные комментарии. Раз это работает в сериалах, почему бы не попробовать?

Что вам точно не поможет

Паника
Не надо сразу палить из пушки по воробьям. Некоторые менеджеры начинают паниковать и сразу откатываться, перезагружать сервера и т. п. в надежде, что что-нибудь из этого исправит проблему. Это никогда не работает. Кроме того, это создает еще больше хаоса и увеличивает время, необходимое для поиска ошибки. Делайте только один шаг за раз. Изучите результат. Обдумайте его, а затем переходите к следующей гипотезе.
«Хелп, плиииз!»
Когда вы обращаетесь на форум за советом, вы как минимум должны уже выполнить шаг 3. Никто не захочет или не сможет вам помочь, если вы не предоставите подробное описание проблемы, включая информацию об ОС, железе и участок проблемного кода. Создавайте тему только тогда, когда можете все подробно описать, и придумайте информативное название для нее.
Переход на личности
Если вы думаете, что в ошибке виноват кто-то другой, постарайтесь по крайней мере говорить с ним вежливо. Оскорбления, крики и паника не помогут человеку решить проблему. Даже если у вас в команде не в почете демократия, крики и применение грубой силы не заставят исправления магическим образом появиться.

Ошибка, которую я недавно исправил

Источник

Дебаг и поиск ошибок

Время на прочтение
6 мин

Количество просмотров 5.3K

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

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

Как обнаружить ошибку

Прочитай информацию об исключении

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

В каждом языке есть свои способы уведомления об исключениях. Например в JavaScript для обработки ошибок связанных с Web Api существует DOMException. Для пользовательских сценариев есть базовый тип Error. В обоих случаях в них содержится информация о наименовании и описании ошибки.

Для .NET существует класс Exception и каждое исключение в приложении унаследовано от данного класса, который представляет ошибки происходящие во время выполнения программы. В свойстве Message читаем текст ошибки. Это даёт общее понимание происходящего. В свойстве Source смотрим в каком объекте произошла ошибка. В InnerException смотрим, нет ли внутреннего исключения и если было, то разворачиваем его и смотрим информацию уже в нём. В свойстве StackTrace хранится строковое представление информации о стеке вызова в момент появления ошибки.

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

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

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

Разверните стек

Когда выбрасывается исключение, помимо самого описания ошибки полезно изучить стек выполнения. Для .NET его можно посмотреть в свойстве исключения StackTrace. Для JavaScript аналогично смотрим в Error.prototype.stack (свойство не входит в стандарт) или можно вывести в консоль выполнив console.trace(). В стеке выводятся названия методов в том порядке в котором они вызывались. Если то место, где падает ошибка зависит от аргументов которые пришли из вызывающего метода, то если развернуть стек, мы проследим где эти аргументы формировались.

Загуглите текст ошибки

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

Прочитайте документацию

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

Проведите исследовательское тестирование

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

Бинарный поиск

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

Где обитают ошибки

Ошибки в своём коде

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

Ошибки в чужом коде

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

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

Ошибки в библиотеках

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

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

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

Ошибки не воспроизводимые локально

Ошибка воспроизводится на develop стенде или в production, но не воспроизводится локально. Такие ошибки сложнее отлавливать потому что не всегда есть возможность запустить дебаг на удалённой машине. Поэтому убеждаемся, что ваше окружение соответствует внешнему.

Проверьте версию приложения

На стенде и локально версии приложения должны совпадать. Возможно на стенде приложение развёрнуто из другой ветки.

Проверьте данные

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

Проверьте соответствие окружений

Если проект на стенде развёрнут в контейнере, то в некоторых IDE (JB RIder) можно дебажить в контейнере. Если проект развёрнут не в контейнере, то воспроизводимость ошибки может зависеть от окружения. Хотя .Net Core мультиплатформенный фреймворк, не всё что работает под Windows так же работает под Linux. В этом случае либо найти рабочую машину с таким же окружением, либо воспроизвести окружение через контейнеры или виртуальную машину.

Коварные ошибки

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

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

Дополнительные материалы

Алгоритм отладки

Повтори ошибку.
Опиши проблему.
Сформулируй гипотезу.
Проверь гипотезу — если гипотеза проверку не прошла то п.3.
Примени исправления.
Убедись что исправлено — если не исправлено, то п.3.

Подробнее ознакомиться с ним можно в докладе Сергея Щегриковича «Отладка как процесс».

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

Итого

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

Источник

Вчера всё работало, а сегодня не работает / Код не работает как задумано

или

Debugging (Отладка)

В чем заключается процесс отладки? Что это такое?

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

Заметка: Отладка производится как правило в IDE (Интегрированная среда разработки). Что это такое можно чуть подробнее ознакомиться в вопросе

Какие есть способы предупреждения ошибок, их нахождения и устранения?

В данном случае будет рассмотрен пример с Visual Studio, но отладить код можно и в любой другой IDE.

Подготовка

Достаточно иметь в наличии IDE, например Visual Studio

Запуск

Для начала в левой части панели с кодом на любой строке можно кликнуть ЛКМ, тем самым поставив точку останова (breakpoint — брейкпойнт). Это то место, где отладчик автоматически остановит выполнение C#, как только до него дойдёт. Количество breakpoint’ов не ограничено. Можно ставить везде и много.

Отладка запускается сочетанием F5 или выбором в верхнем меню Debug → Start Debugging

В данном случае, т.к. функция вызывается сразу на той же странице, то при нажатии кнопки Debug — отладчик моментально вызовет метод, выполнение «заморозится» на первом же брейкпойнте. В ином случае, для активации требуется исполнить действие, при котором произойдет исполнение нужного участка кода (клик на кнопку в UI, передача POST запроса с данными и прочие другие действия)

Цифрами обозначены:

Стэк вызовов, все вложенные вызовы, которые привели к текущему месту кода.
Переменные. На текущий момент строки ниже номера 8 ещё не выполнилась, поэтому определена лишь data и numsStringArr
Показывает текущие значения любых переменных и выражений. В любой момент здесь можно вписать имя любой переменной в поле name и посмотреть её значение в реальном времени. Например data или nums[0], а можно и nums[i] и item.test.data.name[5].info[key[1]] и т.д. На текущий момент строки ниже номера 24 ещё не выполнилась, поэтому num (которая появляется лишь в цикле foreach) во вкладке Watch обозначена красным цветом с надписью «The name ‘num’ does not exist in the current context».

Процесс

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

Show Next Statement (Alt+Num *) — переносит в файл и текущую линию отлаживаемого скрипта. Например если файлов много, решили посмотреть что в других вкладках, а потом забыли где у вас отладка

Step Over (F10) — делает один шаг не заходя внутрь функции. Т.е. если на текущей линии есть какая-то функция, а не просто переменная со значением, то при клике данной кнопки, отладчик не будет заходить внутрь неё.

Step Into (F11) — делает шаг. Но в отличие от предыдущей, если есть вложенный вызов (например функция), то заходит внутрь неё.

Step Out (Shift+F11) — выполняет команды до завершения текущей функции. Удобна, если случайно вошли во вложенный вызов и нужно быстро из него выйти, не завершая при этом отладку.

Restart (Ctrl+Shift+F5) — Перезапустить отладку

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

Stop Debugging (Shift+F5) — Завершить отладку

…

Итак, в текущем коде видно значение входного параметра:

data = "23 24 11 18" — строка с данными через пробел
numsStringArr = {"23", "24", "11", "18"} — массив строк, который получился из входной переменной.

Если нажмем F10 2 раза, то окажемся на строке 11; во вкладках Watch и Variables и в самой странице с кодом увидим, что nums была инициализирована и в ней лежит массив целых чисел {23, 24, 11, 18} .

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

Дальнейшие нажатия F10 переместит линию кода на строки 15, 16 и, наконец, 20.

Дополнительно

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

Это удобно, если останов нужен только при определённом значении, а не всегда (особенно в случае с циклами).

Больше информации об отладке можно посмотреть в Сведения об отладке кода C# с помощью Visual Studio.

Источник

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

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

Совет 1. Откройте процесс в окне отладчика

Когда система не получает никаких сведений о проблеме, можно определить, как протекает процесс, с помощью отладчика (windbg.exe). Более подробные сведения о том, как приступить к работе с отладчиком, можно найти в статье «Диагностика неисправностей: рекомендации администраторам», опубликованной в «Windows IT Pro/RE» № 8 за 2009 год. Перед запуском процесса в отладчике нужно будет открыть командную строку, чтобы ввести в ней имя программы windbg и запустить этот процесс. Открыть командную строку можно с помощью программы Process Explorer (technet.microsoft.com/en-us/sysinternals/bb896653.aspx); чтобы получить доступ к командной строке, дважды щелкните на процессе, и вы увидите командную строку, отображенную на вкладке Image.

Открыв окно отладчика Windows из группы Debugging Tools for Windows меню Start, можно запустить диспетчер Device Manager, выбрав в меню File элемент Open Executable. Введите командную строку, которая обычно используется для инициализации процесса.

Совет 2. Получите максимум данных до начала процесса отладки

Перед тем как браться за отладчик, соберите базовые сведения относительно кода, который намереваетесь изучать. Поиски ответа на вопрос, с чего начинать отладку, часто начинаются вне программного отладчика. Необходимо каким-то образом выявить имена функций, имеющих отношение к рассматриваемой проблеме. Если, к примеру, ваше приложение сообщает об ошибке, поясняя, что не удалось открыть некий раздел реестра, требуется выяснить, какая именно функция ответственна за открытие этих разделов. А как можно определить функции, применяемые для решения различных задач? Иногда ответ содержится в названии функции, но можно воспользоваться MSDN, сетью для разработчиков на платформе Windows, чтобы выяснить, какие вызовы происходят. К примеру, быстрый поиск по ключевым словам registry functions позволит вам обнаружить документы MSDN с перечислением этих функций по адресу msdn.microsoft.com/en-us/library/ms724875(VS.85).aspx. И там вы увидите, что для открытия разделов реестра используется функция RegOpenKeyEx.

Для получения информации о соответствующих функциях можно воспользоваться бесплатно распространяемым средством Dependency Walker (depends.exe), доступным для загрузки по адресу www.dependencywalker.com. Программа Dependency Walker показывает, какие библиотеки DLL используются двоичным файлом, а также имена функций, применяемых файлом из DLL. Получить эти сведения просто: запустите программу depends.exe, затем откройте исследуемый двоичный файл с помощью команды open из меню File. После этого Dependency Walker отобразит имена функций, вызываемых данным приложением при его выполнении. Эта информация будет иметь большое значение при проведении операции отладки, поскольку она позволяет выявить интересные вызовы, которые, возможно, имеют отношение к рассматриваемой проблеме. Так, если ваше приложение выдает сообщение о том, что попытка сетевого соединения не удалась, нужно просмотреть выходные данные Dependency Walker и найти там имена функций, которые, по-видимому, имеют отношение к установлению сетевых соединений. Затем вы сможете с помощью отладчика расследовать соответствующие вызовы.

В качестве примера давайте воспользуемся Dependency Walker для открытия файла devmgr.dll. Этот бинарный файл содержит код, который программа mmc.exe задействует для создания оснастки Device Manager. Как видно на экране 1, Dependency Walker показывает, что файл devmgr.dll импортирует различные функции, связанные с перечислением устройств, из файла setupapi.dll. Если вас интересует вопрос, как я определил, что файл devmgr.dll представляет собой библиотеку DLL, применяемую для создания диспетчера Device Manager, поясняю, что файл devmgmt.msc фактически является XML-файлом, упоминающим файл devmgr.dll в тексте. Чтобы его открыть, можно воспользоваться редактором Notepad.

Совет 3. Установите точки прерывания

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

Вы можете установить точку прерывания против функции с помощью команды bp (set breakpoint). Далее можно воспользоваться командой g (go), чтобы возобновить выполнение потоков процесса до тех пор, пока другие обстоятельства не заставят отладчик вновь приостановить процесс. Ниже приводятся соответствующие команды и выходные данные:

0: 000> bp setupapi! CM_Get_Device_ID_
List_ExW
0: 000> g
Breakpoint 0 hit

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

В предыдущем фрагменте кода отладчик проинформировал нас о том, что мы дошли до точки прерывания «ноль». Составить список этих точек прерывания можно с помощью команды bl (breakpoint list). У нас имеется лишь одна точка прерывания, и она имеет номер ноль.

0: 000> bl
0 e 770 edf2 d
0001 (0001)
0:****
setupapi! CM_Get_
Device_ID_List_
ExW

Итак, каким же образом искать имена функций, против которых целесообразно поставить точки прерывания? Команда x (examine symbols) может использовать информацию о символах для получения функций и других данных, соответствующих шаблону. В примере, приведенном на экране 2, перечисляются все символьные данные, соответствующие шаблону *Devices* из модуля devmgr. Затем вы сможете установить точки прерывания против любой из этих функций.

Совет 3. Установите точки прерывания

0: 000> bp setupapi! CM_Get_Device_ID_
List_ExW
0: 000> g
Breakpoint 0 hit

0: 000> bl
0 e 770 edf2 d
0001 (0001)
0:****
setupapi! CM_Get_
Device_ID_List_
ExW

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

0: 000> sxe ld: setupapi
0: 000> g
ModLoad: 770 e0000 771 e8000 c:
windowssystem32setupapi.dll

Совет 4. Определите поток вызовов

При достижении точки прерывания вы сможете выяснить, какая команда вызвала данную функцию и какую процедуру упомянутая функция вызывает (т. е. определить поток вызовов), проанализировав стек с помощью команды kC (отобразить обратную трассировку стека). В нашем примере я выполнил команду kC по достижении точки прерывания, которую я выставил на setupapi! PNP_GetDeviceList. Приращение стеков происходит снизу вверх. Это значит, что в начале списка отображается функция, которая вызывалась последней. В результате выполнения команды kC будет отображен стек, образовавшийся при достижении точки прерывания, которая была установлена на setupapi! PNP_GetDeviceList. Модуль devmgr.dll вызвал файл setupapi.dll для формирования списка устройств.

Для определения вызовов, осуществленных функцией, а также для регистрации ее выполнения можно использовать одну из самых мощных команд, реализованных в отладчике Windows, команду wt (watch trace). Данную команду можно выполнять с момента начала вызова функции; тогда на экране будут отображены все вызовы, выполненные этой функцией. В примере, показанном на экране 3, я использовал параметр -l2 для ограничения глубины выходных данных двумя уровнями. В этом примере функция setupapi! PNP_Get-DeviceList вызвала функцию setupapi! NdrClientCall2, которая, в свою очередь, вызвала функцию rpcrt4! NdrClientCall2.

Совет 5. Определите, была ли после вызова функции возвращена ошибка

Допустим, точка прерывания, установленная вами для некоей функции, достигнута. Как определить, возвратили ли эти функции сообщение об ошибке? Нужно запустить команду gu (go up), чтобы вернуться из функции, а затем применить команду r, чтобы исследовать возвращенное значение.

Команда gu возобновляет выполнение до возвращения результата текущей функцией. В данном случае команда gu запускает функцию PNP_GetDeviceList, а затем останавливает исполнение непосредственно по завершении выполнения функции. Команда r (register) возвращает содержимое регистров. Переменная $retreg представляет регистр возврата, который можно использовать для определения того, закончилось ли выполнение функции успешно или она вернула сообщение об ошибке. Мы получили сообщение об ошибке с кодом 0x1d от функции PNP_Get-DeviceList(). Я обнаружил, что возвращенное значение для функции PNP_GetDeviceList было задокументировано в файле, размещенном по адресу msdn.microsoft.com/en-us/library/cc239018(PROT.10).aspx: An error occurred during an attempt to read the registry.

Заключительные шаги

Проблема диспетчера устройств была решена с использованием команды p (step), выполняющей трассировку процесса выполнения функции. Трассировка в ходе отладки показала, что функция setupapi! PNP_GetDeviceList осуществила удаленный вызов процедуры, направленный на интерфейс 8d9f4e40-a03d-11ce-8f69-08003e30051b. С помощью монитора процессов я обнаружил, что на этот удаленный вызов процедуры ответила функция umpnpmgr.dll! PNP_GetDeviceList (), которая выполнялась в процессе services.exe. Этот вызов завершился с ошибкой NAME_NOT_FOUND вследствие повреждения реестра. Я перезагрузил систему, используя конфигурацию Last Known Good registry configuration. Проблема была решена!

Райан Мангипано — инженер по технической поддержке подразделения Microsoft Global Escalation Services. Специализируется на диагностике ядра Windows и новых методах отладки. Дополнительная информация по отладке Windows — по адресу blogs.msdn.com/ntdebugging

Источник