Сайт о телевидении

Инструкция

Нажмите кнопку «Пуск» для вызова главного меню системы и введите значение cmd в поле строки поиска для инициации процедуры отключения отладчика ядра.

Вызовите контекстное меню найденного инструмента «Командная строка» кликом правой кнопки мыши и укажите команду «Запуск от имени администратора».

Укажите значение Kdbgctrl.exe -d в текстовое поле утилиты командной строки для выполнения отключения процедуры отладки ядра в текущем сеансе и нажмите функциональную клавишу Enter для подтверждения выполнения команды.

Используйте значение bcdedit /debug off в текстовом поле командной строки для отключения процесса отладки ядра процессора для всех сеансов работы в операционных системах Windows Vista и Windows 7 и выполите нажатие функциональной клавиши Enter для подтверждения своего выбора.

Введите значение dir /ASH в текстовое поле командной строки для выполнения поиска скрытого защищенного файла boot.ini, находящегося на системном диске, для осуществления процедуры отключения отладчика ядра для всех сеансов во всех более ранних версий операционной системы Microsoft Windows и откройте найденный файл в приложении «Блокнот».

Произведите удаление параметров:

- /debug;
- debugport;
- /baudrate

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

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

Используйте команду gn в текстовом поле окна программы «Отладчик ядра» при появлении сообщения о возникшей ошибке User break exception (Int 3).

Используйте режим Debugging Mode при загрузке компьютера в безопасном режиме для выполнения включения службы отладчика ядра.

Полезный совет

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

Источники:

• Ошибка: отладка невозможна, поскольку в системе включен отладчик ядра

Отладчик ядра представляет собой специальное программное обеспечение, которое работает на уровне ядра всей операционной системы персонального компьютера. Под процессом «отладки ядра операционной системы» понимается процедура сканирования различных ошибок в ядре системы. При работе с Daemon Tools часто возникает ошибка Initialization error... Kernel debugger must be deactivated. Устранить ее можно отключением отладчика ядра.

Вам понадобится

• Права администратора.

Инструкция

Если данное предупреждение появилось в процессе установки приложения, необходимо выключить службу под названием Machine debug manager. Для этого запустите «Панель Управления» и зайдите в радел «Администрирование». Далее нажмите на ярлык «Службы». Найдите в списке Machine Debug Manager. Кликните по названию кнопкой мыши и нажмите «Стоп».

Отключите процессы дебаггеров в «Диспетчере задач». Для этого кликните правой кнопкой мыши в свободной области и выберите пункт «Диспетчер задач». Можете нажать комбинацию клавиш Alt + Ctrl + Delete. Перейдите на вкладку «Процессы» и отключите все процессы mdm.exe, dumprep.exe и drwatson.exe. Если вам не удобно искать их в списке, нажмите вкладку «Имя образа», чтобы список был отсортирован по имени. Как правило, подобные операции осуществляются вручную, от имени администратора персонального компьютера.

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

Удалите приложение Daemon Tools из автозапуска. Для этого нажмите кнопку «Пуск». Далее нажмите «Выполнить» и введите команду msconfig. Как только появится системное окно, снимите флажок рядом с приложением Daemon Tools. Во время установки программы отключите антивирусное программное обеспечение. При возникновении описанной ошибки установку приложения следует запустить заново, после устранения всех причин на персональном компьютере.

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

Инструкция

Отключить отображение скрытых файлов и папок в операционной системе Windows ХР можно двумя способами. Откройте любую папку. На панели верхнего меню выберите пункт меню «Сервис», далее «Свойства папки». Диалоговое окно откроется на вкладке «Общие». Перейдите на вкладку «Вид».

В поле «Дополнительные параметры» пролистайте список вниз. Найдите пункт «Скрытые файлы и папки». Поставьте значение на нужном пункте – «Не показывать скрытые файлы и папки», «Показывать скрытые файлы и папки». Если вам нужно отобразить все скрытые файлы , рекомендуется также снять галочку с пункта «Скрывать защищенные системные файлы (рекомендуется)». Далее нажмите кнопки «Применить» и «Ок».

Чтобы не утомлять вас, я расскажу короткую историю. Две машины, идентичные системы на них, идентичные программы (в основном). У одного есть Visual Studio, у вас есть... uhmm, что-то еще.

Иногда, когда я пытаюсь установить приложения, скажем, на компакт-диск, появляется всплывающее окно Visual Studio Just-In-Time Debugger, сообщает "необработанное исключение win32 в..." и спрашивает, хочу ли я отлаживать использование "Новый экземпляр Microsoft VIsual Studio 2010". Если я выберу "Да", он запускает VS, если я выберу "Нет", он закрывает эту вещь, а я снова в проводнике Windows.

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

Итак, как мне избавиться от этой вещи (отладчик точно в срок)?

Я не хочу удалять VS, потому что я использую его ежедневно, конечно.

Изменить 1:: Я попытался отключить отладку "Just-In-Time" в VS Tools/Options/Debugging/Just-In-Time, а затем снятие всех трех галочек, но это просто дало еще одну ошибку при попытке запустить исполняемую программу установки.

Необработанное исключение win32 произошло в файле autorun.exe [некоторое число]. Отладка "Just-In-Time" при отладке этого исключения завершилась со следующей ошибкой: ни один из установленных отладчиков не включил отладку Just-In-Time. В Visual Studio отладка "Just-In-Time" может быть включена с...

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

Очень информативно:/

Изменить 2:: Приложение отлично работает на другом компьютере, на котором не установлено VS. В значительной степени программное обеспечение на обеих машинах одинаково, с некоторыми незначительными отличиями (системы, установленные из образа). Незначительные отличия: notepad2, ++, git,... некоторые мелкие вещи, которые оставляют самостоятельно.

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

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

8 ответов

У меня была эта проблема сегодня с Visual Studio 2013. Эта статья MSDN: Работает на меня вовремя - отладка в Visual Studio . В моем случае я просто переименую Debugger в Debugger_del и DbgManagedDebugger в DbgManagedDebugger_del .

Чтобы отключить отладку Just-In-Time, отредактировав реестр

В меню Начать найдите и запустите regedit.exe

В окне Редактор реестра найдите и удалите следующие разделы реестра:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger

• Если на вашем компьютере установлена ​​64-разрядная операционная система, удалите также следующие разделы реестра:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger

    Включение или отключение отладки "Just-In-Time"

    Вы можете включить или отключить отладку "Just-In-Time" в диалоговом окне "Параметры". Чтобы включить или отключить отладку "Just-In-Time"

    Я добавляю этот ответ, хотя это старая тема, потому что я потратил большую часть дня на эту самую проблему и, наконец, решил ее. Каждое найденное мной решение фокусировалось на отключении или отключении отладки JIT в Visual Studio, удалении ключей из реестра или изменении параметров отладки IE script. Но если у вас нет зарегистрированной копии VS, у вас есть проблема. Разумеется, многие из решений работают по-разному, но после этого вы остаетесь с ошибкой выше " не установлен установленный отладчик с включенной возможностью отладки , который, как представляется, не имеет ответа для, Однако ответ заключается не в отключении JIT, а в прекращении отладки серверной части приложения. Если вы на самом деле не хотите выполнять отладку на стороне сервера, это не обязательно для включения.

    Теперь это имеет смысл, потому что в ASP была включена отладка серверной части. Перед установкой VS это не имело значения, потому что отладчик не был назначен для обработки ошибок, поэтому они были отправлены в браузер. Как только я установил VS, JIT взял на себя и сделал то, что должен был делать.

    Итак, быстрый ответ, откройте IIS, щелкните по сайтам по умолчанию или вашим сайтам и в настройках вашего приложения, ASP в моем случае отключит отладку на стороне сервера!!

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

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

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

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

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

    • Перевод

    От переводчика: я наткнулся на эту статью случайно, когда искал информацию по управлению загрузкой символов во время отладки. И хотя по этому вопросу информации было не так много, я с удовольствием прочитал всю статью. Большая часть были мне известна и до этого, но не всё. Уверен, что многие найдут в ней для себя что-то полезное. Статья написана полтора года назад, однако не все переходят на новые версии студии и сопутствующих инструментов сразу после их появления, так что актуальности статья не потеряла.
    
    Баги встречаются на двух этапах жизненного цикла кода: во время разработки и в продакшене. Часто ошибки, которые вылезают в течение 10-15 минут с момента написания кода, мы даже не считаем за баги – они просто часть процесса написания кода. А багами мы гораздо чаще называем проблемы, которые проявляются в продакшене или при тестировании кода, написанного несколько дней назад; вероятно потому, что их сложнее отловить (код уже успел подзабыться). В любом случае, если код не делает того, что должен, это баг и его нужно отловить и исправить.

    4 столпа эффективной отладки

    • Правильные инструменты. Это то, чему посвящена статья. Но инструменты бесполезны без других трех.
    • Использование практик построения архитектуры и кода, отдающих предпочтение слабо связанным объектам и написанию того, что я называю Совершенно Очевидный Код – СОК (Really Obvious Code – ROC rocks!). Эти практики помогают находить баги и избегать внесения изменений, лишь добавляющих новые. И никогда не поздно перечитать Brian W. Kernighan and P. J. Plauger"s «The Elements of Programming Style» (Computing Mcgraw-Hill, 1978) .
    • Использование TDD (разработки через тестирование). Если вы разрабатываете что-то кроме сильно связанного пользовательского интерфейса и не используете TDD – вы разработчик с одной рукой, связанной за спиной. Вы менее продуктивны, чем могли бы быть, и ваш код менее надежен, чем должен быть.
    • Методика отладки. Многие разработчики сразу переходят к шагу «разработка решения», что в результате редко приводит к исправлению бага, зато часто создает новые.

    Методика отладки

    1. Опишите баг. Соберите всю информацию для полного описания симптомов бага, акцентируя внимание на том, когда симптомы проявляются, а когда – нет.
    2. Зафиксируйте баг. Опишите последовательность действий, которая всегда приводит к появлению бага. Так вы убедитесь, что правильно определили условия, приводящие к появлению симптомов бага. Проверьте, что симптомы не проявляются при других условиях.
    3. Локализуйте баг. Убедитесь, что вы можете описать, в чем именно истинная причина появления бага и что описание соотносится с шагами 1 и 2.
    4. Разработайте и примените решение. Определите, боретесь ли вы с истинной причиной бага или с его симптомами. Напишите код.
    5. Проверьте решение. Проверьте, что симптомы больше не проявляются при выполнении действий, описанных в шаге 2.
    6. Проведите регрессионное тестирование. Проверьте, что не появилось новых багов.
    7. Примените изменения. Перенесите изменения в продакшен.
    Если вы применяете TDD, баг означает одну из трех вещей: требования не были корректно переведены в тесты; один из имеющихся тестов неверный (не тестирует то что должен); какой-то тест отсутствует. Фиксация бага (шаг 2) представляет собой исследование этих трех проблем путем исправления или добавления тестов; проверка решения (шаг 5) означает написание новых тестов; регрессионное тестирование (шаг 6) означает запуск нужных наборов тестов; применение решения включает в себя каталогизацию новых тестов.

    Использование точек останова

    Многие разработчики не знают всех возможностей отладки в Visual Studio, потому что отладка «и так работает». Например, хотя каждый VS-разработчик знаком с точками останова, многие не знают, что можно сделать в окне Breakpoints.

    Чтобы открыть окно Breakpoins, выберите Debug | Windows | Breakpoints; в окне отобразится список всех установленных вами точек останова. Если вы не уверены, какая точка какой строке кода соответствует, просто кликните по ней двойным кликом и в редакторе откроется связанный с ней код.

    Определившись с нужной точкой, вы можете управлять тем, что происходит, когда она срабатывает. Я видел разработчиков, которые проверяют одни и те же переменные раз за разом, поставив точку останова в цикле. По правому клику на точке останова, выбрав When Hit (условие срабатывания), вы можете задать сообщение, которое выводится в окно Intermediate при каждом ее срабатывании. В сообщение можно включать некоторые константы: например, используя $Caller, можно вывести имя метода, вызвавшего код, содержащий точку останова. Также можно включить любые переменные, заключив их в фигурные скобки: например, {Me.NameTextBox.Text} в сообщении выведет значение поля Text.

    Другая возможность диалога When Hit позволяет задавать, должно ли останавливаться выполнение программы на точке останова. Если выбрать остановку, то вы увидите каждое сообщение в момент его создания; в противном случае вы сможете просмотреть все сообщения после выполнения программы.

    Если вы хотите остановить выполнение только при определенном условии, вы можете выбрать опции Condition или Hit Count. Опция Condition позволяет задать логическое условие, при котором произойдет остановка (например, Position > 30). Также можно выполнить остановку, если одна из переменных изменилась с момента последней остановки. Опция Hit Count прерывает выполнение только если точка останова сработала в n-й раз (или каждые n раз). Это особенно полезно, когда вам нужно остановиться где-то в конце цикла.

    Между прочим, мой опыт говорит, что если в какой-то части приложения возникли проблемы, они продолжат там возникать. Если ваш опыт говорит о том же, вам понравятся дополнительные возможности Visual Studio 2010. Вы можете дать точкам останова названия, чтобы не забыть, для чего нужна каждая из них, и экспортировать их в XML-файл. В следующий раз, когда они вам понадобятся, вы можете импортировать их и начать отладку. Импорт/экспорт можно сделать с помощью тулбара вверху окна Breakpoints.

    Показ и пропуск кода

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

    В любой версии Visual Studio, в пункте Debug | General диалога настроек вы можете выбрать опцию Just My Code и перестать видеть код, который вы не писали. Если впоследствии вам понадобится это отключить (например, если где-то в сгенерированном коде возникает исключение), вы можете это сделать, выбрав Options and Settings в меню Debug (этот пункт есть только в VS2010 – прим. перев ).

    Если же вы устали ходить по какой-то части вашего кода, вы можете использовать один из двух атрибутов. Поставьте на метод атрибут DebuggerHidden и вы никогда не попадете в этот метод. Если же поставить атрибут DebuggerNonUserCode , вы не будете в него попадать при включенной опции Just My Code и будете при выключенной. Я рекомендую вам использовать второй способ.

    С другой стороны, если ошибка возникает где-то в коде Microsoft .NET Framework, вам может понадобится пройти не только по сгенерированному коду, но и по коду классов фрэймворка. И вы можете это сделать! Во-первых, убедитесь, что отключена опция Just My Code. Затем в диалоге Options and Settings в разделе Symbols выберите Microsoft Symbol Server (в VS 2010) или задайте путь к символам как referencesource.microsoft.com/symbols (в VS2008). Это позволит вам загрузить символы, которые поддерживают хождение по коду классов.NET. Однако вам еще нужно их загрузить. В VS2010 вы можете кликнуть кнопку Load All Symbols, но нужно набраться терпения на время скачивания.

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

    Я один из тех, кто пишет в свойствах полезный код и хочет иметь возможность пошагово их отладить. Начиная с VS2008SP1, появилась опция (Step over properties and operators), выключающая пошаговую отладку свойств и операторов. И в VS2010 она по умолчанию включена, так что вам может понадобиться ее выключить.

    Визуализация данных

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

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

    Кстати о подсказках – вы можете с их помощью менять значение переменной. В VS2010 даже более того: подсказку можно заставить висеть в окне, существовать всё время сеанса отладки, и даже после его окончания она будет отображать значение переменной из последнего сеанса. Однако, самые крутые инструменты (Debugger Canvas и IntelliTrace) доступны только в VS2010 Ultimate Edition.

    Только в VS2010 Ultimate Edition

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

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

    Если Debugger Canvas позволяет смотреть «через модули», то IntelliTrace – «через время», что дает понимание того, как вы попали в данную точку останова. IntelliTrace собирает и показывает отладочную информацию, которая была доступна в предыдущие моменты времени сеанса отладки.

    Еще лучше Debugger Canvas и IntelliTrace работают в связке: в Debugger Canvas есть опция, позволяющая видеть логи IntelliTrace рядом с кодом.

    Внешние инструменты

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

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

    В подобной ситуации вы можете настроить Just-in-Time (JIT) отладку и автозапуск – сеанс отладки начнется, когда служба запустится или когда возникнет ошибка. Но чтобы это сделать, вам нужно воспользоваться внешними инструментами.

    Так как настройка JIT-отладки выходит за рамки данной статьи, вы можете обратиться к соответствующей статье в MSDN . Эта статья советует использовать Global Flags Editor (gflags.exe); на случай, если вы не можете его найти, описывается, как подправить реестр, чтобы включить JIT-отладку. Однако вам придется научиться пользоваться WinDbg.

    WinDbg: за пределами отладчика Visual Studio

    Если вам интересна отладка глубже исходного кода, Microsoft .NET Framework включает в себя несколько прекрасных инструментов.
    Вот несколько из них:

    • Windows Debugger (WinDbg.exe)
    • SOS Debugging Extension (SOS.dll, которая может быть использована в консоли Visual Studio или с WinDbg.exe)
    • Assemble Binding Log Viewer (Fuslogvw.exe, который я обсуждал в блоге.NET Tips)

    Если вы не использовали раньше WinDbg, это не так страшно, как может показаться – WinDbg имеет GUI (в отличие от консольных инструментов типа NTSD, KD и CBD) и может загружать PDB-файлы с отладочными символами для вашего приложения (просто убедитесь, что вы скомпилировали ваше приложение в Debug-режиме и файл символов гарантированно подходит). Вдобавок к SOS, есть еще несколько других расширений WinDbg для выполнения типичных отладочных задач.
    Однако, самый полезный инструмент для использования с WinDbg – это книга Mario Hewardt, Patrick Dussud «Advanced .NET Debugging» (Addison-Wesley Professional, 2009) . Она не просто рассказывает, как использовать все эти инструменты, но делает это в контексте отлавливания типичных для.NET проблем.
    

    Сторонние визуализаторы

    Я уже говорил про визуализаторы Visual Studio, но есть еще множество сторонних. DotNetDan’s DataSet Visualizer – весьма чудесен, если вам нужно знать, что лежит в датасете (я упоминал его в блоге)

    

    С того времени я уже обнаружил RightHand DataSet Visualizer и стал использовать его. Это MDI-приложение, которое позволяет открыть окно для каждой таблицы датасета. Кроме того, окно Relations показывает таблицы, связанные с текущей просматриваемой.

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

    Следует отметить, что DotNetDan’s DataSet Visualizer быстрее загружает данные, так что я оставил его на случай, когда не нужна вся мощь RightHand.

    Еще есть Web Visualizer для приложений ASP.NET. Этот визуализатор доступен на всплывающей подсказке любого объекта страницы ASP.NET (включая Me и this в коде ASP.NET)

    С помощью Web визуализатора можно смотреть любые данные коллекции Server Variables объекта Server и коллекции Forms объекта Request. Также можно посмотреть строку запроса браузера и содержимое объектов Session и Application. Однако, в случае Session и Application для любых объектов, кроме скалярных данных, вы увидите только название типа объекта.

    Есть и другие визуализаторы, включая те, что позволяют смотреть Cache и LINQ-запросы к Entity Framework (EF), а также позволяющие увидеть SQL на выходе LINQ-запросов к EF. Печально только то, что нет единого каталога визуализаторов.

    Не все, но многие можно найти через Visual Studio Extension Manager. В том числе, ASP.NET MVC Routing Visualizer. Если вы используете маршрутизацию в ASP.NET MVC или в простом ASP.NET, вам пригодится этот инструмент. Взаимодействие между правилами маршрутизации может выдавать неожиданные результаты («Почему я получаю эту страницу?»), и отладка этих правил может быть непростой. Визуализатор позволяет вам ввести URLы и посмотреть, как маршрутизатор их декодирует, включая информацию о том, какое правило используется для каждого URL. Чтобы использовать его в режиме останова, переключитесь на ваш файл global.asax и наведите курсор на RouteTable. Когдя появится всплывающая подсказка, промотайте до коллекции Routes и кликните на значок лупы.

    Трассировка

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

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

    Когда дело доходит до чтения полученных логов, я использую Log Parser Lizard от Lizard Labs. В бесплатной версии некоторые возможности ограничены (цена платной – около 25$), однако мне они ни разу не понадобились. Log Parser Lizard использует SQL-подобный синтаксис для построения запросов к логам (включая файлы формата CSV и XML) и прямо из коробки понимает форматы логов IIS, событий Windows и log4net. Результаты отображаются в таблице, что делает его похожим на Server Explorer, с которым мне очень нравится работать.

    Заключение

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