"Работает на моей машине" - Как исправить непоправимые ошибки?

Ответ 1

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

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

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

Ответ 2

Обширная регистрация обычно помогает.

Ответ 3

Самый простой способ - всегда видеть клиента в действии (при условии, что он легко воспроизводится клиентом). Зачастую проблемы возникают из-за проблем с компьютерной средой клиента, конфликтов с другими программами и т.д. - это детали, которые вы не сможете поймать на своей dev-установке. Поэтому посещение сайта может оказаться полезным; но если это не удобно, инструменты, такие как RealVNC, также могут помочь вам увидеть, как клиент "делает свою работу".

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

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

Ответ 4

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

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

Клиенты также обычно (sorta) впечатлены тем, что я знаю об их проблеме, как только они сталкиваются с ней!

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

Ответ 5

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

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

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

Ответ 6

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

Телепатия также будет полезна...

Ответ 7

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

Ответ 8

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

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

Ответ 9

Copilot (предполагая, что клиент где-то холодный и дождливый:)

Ответ 10

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

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

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

Ответ 11

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

Переход из

он сломался!

to

он сломался! и вот скриншоты из каждый вариант, который я выбрал генерируя этот отчет

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

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

Ответ 12

У меня были и эти проблемы. Мое решение состояло в том, чтобы добавить много протоколирования и предоставить клиенту сборку отладки со всей возможной информацией об отладке. Затем убедитесь, что dr Watson (он был в Windows NT) создал дамп памяти с достаточной информацией. После загрузки дампа памяти в отладчике я мог узнать, где и почему он разбился.

EDIT: О, это, очевидно, работает только в том случае, если приложение сильно оканчивается...

Ответ 13

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

Ответ 14

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

Когда включен Bug.. Есть несколько факторов, которые могут произойти.

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

• Получить системную информацию
• какой другой процесс клиент сделал до этого.
• Период времени. его редких или частых
• его следующее действие произошло после выпуска (его всегда одно или несколько)
• Найдите факторы для этой ошибки (как разработчик)
• Найдите точное место, где эта проблема произошла.
• Найти ВСЕ СИСТЕМНЫЕ ФАКТОРЫ того времени
• проверить все утечки памяти или ошибки пользователя или неправильные условия в коде
• Список всех факторов, которые могут вызвать эту проблему.
• Как влияет каждый фактор на это и варит, данные содержат эти факторы.
• Проверьте проблемы с памятью.
• проверить у клиента текущий код обновления, как ваш
• проверить весь журнал с по крайней мере 1 месяц и найти любую ненормальную операцию. держать примечание

Ответ 15

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

Ответ 16

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

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

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

При этом рассмотрим:

1) Какие существуют различия между этой системой и другими рабочими системами.

2) Что недавно изменилось в конфигурации вашего продукта или клиента, что вызвало возникновение проблемы.

Привет

Ответ 17

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

Для приложений .Net мы также были Trace.Writeline, тогда мы можем заставить пользователя запустить DbgView и отправить нам вывод.

Ответ 18

Просто короткий анекдот (отсюда "wiki сообщества" ): на прошлой неделе я подумал, что в приложении Django было умной идеей импортировать модуль pprint для печати данных Python только в том случае, если DEBUG был True:

if settings.DEBUG:
    from pprint import pprint

Затем я использовал здесь и там команду pprint как инструкцию для отладки:

pprint(somevar) # show somevar on the console

После завершения работы я протестировал приложение с настройкой DEBUG=False. Вы можете догадаться, что произошло: сайт повредил ошибки HTTP500 повсюду, и я не знал, почему, потому что нет трассировки, если DEBUG is False. Я был озадачен тем, что ошибки исчезли волшебным образом, если я вернусь в режим отладки.

Мне потребовалось 1-2 часа сложения операторов print по всему коду, чтобы обнаружить, что код сбой происходит именно в указанной выше строке pprint(). Затем мне потребовалось еще полчаса, чтобы убедить себя, чтобы я не стучал головой о стол.

Теперь приходит мораль истории:

• В конце концов, не всякая вещь, которая выглядит как умная идея в первом представлении, такая подкованная.

• Важным моментом для отладки этих ошибок являются все параметры конфигурации и коммутаторы платформы, которые сам по себе делает. Это может быть намного больше, чем некоторые пользовательские настройки. Хороший документ, если вы сделаете предположение о пользовательской платформе (например, если вы протестируете только для Win/Mac/Linux, будет ли ваш код разбит на BSD или Solaris?)

Приветствия,

Ответ 19

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

Кроме того, одним из наиболее важных подходов является информационный богатый журнал. Я также использую много перечислений для описания состояния процесса в зависимости от рассматриваемого сценария. для примера я использовал, как Initiated, Triggered, Running, Waiting Repaired и т.д., чтобы описать состояния расписаний и сохранил их в БД на разных этапах.

Ответ 20

Не упоминается, но "обзор направленного кода" - одно из лучших решений, особенно если вы не сделали надлежащего обзора (по крайней мере 1 час на 100 строк кода) до выпуска.

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

Ответ 21

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

Вот общие проблемы, которые я видел, которые приводят к типам проблем, которые вы описываете:

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

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

Ответ 22

Вы можете использовать такие инструменты, как Microsoft SharedView или TeamViewer для подключения к удаленному компьютеру и проверки проблемы непосредственно на сайте. Конечно, вам нужно сотрудничество с клиентом.