Visual Studio 2015 RTM - отладка не работает
Я установил VS 2015 RTM (больше ничего) и не могу отладить какое-либо решение, независимо от того, существующее оно или совершенно новое (созданное с VS 2015 и скомпилированное с использованием.Net Framework 4.6), оно открывает только Новая вкладка в VS, которая называется Break Mode, со следующим текстом: Приложение находится в режиме break. Ваше приложение вошло в состояние break, но не выполняется код, поддерживаемый выбранным механизмом отладки (например, выполняется только собственный код времени выполнения).). И если я проверяю окно "Отладка -> Модуль: VS2015Test.vshost.exe", символы не загружаются (даже если я нажимаю "загрузить", он не работает) Символы VS2015Test.exe загружаются.
И это также не показывает вывод на консоль (это консольное приложение, которое просто имеет следующие строки кода:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("TEST");
Console.ReadKey();
}
}
Я попытался переустановить VS 2015, перезагрузил компьютер, удалил все файлы в%temp%/AppData/Microsoft/Visual Studio/14, запустил VS в режиме администратора, но, похоже, ничего не работает.
Одна вещь, которая делает отладку работающей, это эта опция: Инструменты -> Параметры -> Отладка -> Использовать режим управляемой совместимости
^^ Но это не может быть решением использовать старый / старый режим.
Кстати: отладка в VS 2013 работает нормально.
Любая помощь будет оценена.
25 ответов
В моем случае это решение полезно:
Решение: отключите опцию "Просто мой код" в настройках "Отладка / Общие".
Ссылка: c-sharpcorner
У меня была такая же проблема с VS2015. Я сбросил настройки, как и предлагалось, но все еще возникли проблемы.
Чтобы исправить это, мне нужно было проверить "Использовать режим управляемой совместимости" и "Использовать режим собственной совместимости". Не уверен, какой из этих 2 необходим, но проверяю оба, и у меня больше не возникает проблема режима прерывания.
Недавно у меня была очень похожая проблема, связанная с настройками отладки.
Во-первых, вы пытались сбросить все настройки? Я думаю, что это может быть связано с этим, так как вы говорите, что это не зависит от проекта, и вы удалили все данные приложения.
Сервис-> Мастер импорта и экспорта настроек -> Сбросить все настройки
Не волнуйтесь, это дает вам возможность сохранить текущие настройки.
Во-вторых, если это не удастся, я бы предложил посмотреть журнал событий.
Вход в режим прерывания предполагает, что DE (механизм отладки) отправляет синхронизированное событие остановки в Visual Studio, например, IDebugExceptionEvent2. Я хотел бы взглянуть на журнал событий на наличие исключений, таких как сбои при загрузке сборок, на которые есть ссылки (например, среды выполнения.NET и т. Д.) Или ограничения доступа к среде.
Что-то говорит отладчику остановить ваше работающее приложение, это просто случай его обнаружения.
Думал, что выложу это на случай, если это кому-нибудь поможет Я установил чистую Win 10 и Visual Studio 2015, попытался отладить существующее решение и возникли проблемы. Следовал некоторым советам, перечисленным здесь и в других местах, но ни один не помог.
Как отладка работала как обычно, я изменил конфигурацию решения чуть ниже меню. Ранее я установил его в режим Release, изменил его на Debug, а затем очистил / перекомпилировал, и привет, отладка начала работать как обычно. Смотрите изображение для информации:
Мое решение внезапно перестало работать в режиме отладки. Я получил сообщение во время отладки. 
[Название окна] Microsoft Visual Studio [Основная инструкция] Вы отлаживаете сборку выпуска NettoProWin.exe. Использование Just My Code со сборками Release с использованием оптимизации компилятора приводит к ухудшению процесса отладки (например, точки останова не будут достигнуты). [Остановить отладку] [Отключить только мой код и продолжить] [Продолжить отладку] [Продолжить отладку (не спрашивать снова)]
Я решил продолжить отладку, но она все равно не сработала.
Решение было простым. Нужно в свойствах проекта -> в разделе сборки -> удаленная проверка "Оптимизированный код" 
Проверьте "Тип кода" перед подключением к процессу. Например, мне пришлось перейти с CoreCLR на v4.*
- Прекратите отладку.
- Отредактируйте файл csproj.user
- Найти раздел написал ниже:
True - Изменить значение на "Ложь"
- Выгрузите и перезагрузите ваш проект в Visual Studio.
- Иногда нужно было закрыть Visual Studio.
ПТК. Я попал в нижнюю часть этой страницы, поэтому я начал разрывать свой проект. Я нашел решение для моей конкретной проблемы.
Моя проблема: я не смог достичь точки останова в многопоточном процессе. Ничего особенного, я просто запускаю новый поток в консольном приложении, и отладчик не останавливался на точках останова. Я заметил, что поток создавался, но он зависал во внешних вызовах.Net Framework и, в частности, в ThreadStart_Context. Это объясняет, почему мои контрольные точки так и не были достигнуты, потому что.Net Framework что-то зависает.
Проблема: я обнаружил, что могу решить эту проблему, изменив код запуска. По какой-то причине у меня был файл program.cs, который содержал Main() и был внутри класса Program, как и следовало ожидать от консольного приложения. Внутри Main() я создавал другой класс с помощью этого кода;
new SecondClass();
Обычно это работает нормально, и у меня есть куча других проектов с вызовами Threaded, где все работает нормально (ну, я не отлаживал их в течение некоторого времени, поэтому, возможно, появился пакет обновления, который вызывает регрессию).
Решение: переместите Main() в мой SecondClass и вместо вызова конструктора SecondClass с помощью 'new SecondClass()' обновите конструктор SecondClass, чтобы он стал стандартным статическим методом, а затем вызовите его из Main. После внесения этих изменений я снова могу отладить поток.
Надеюсь это поможет.
У меня были похожие проблемы с моим приложением svc, запущенным в Visual Studio 2015, решение состояло в том, чтобы изменить платформу решения с "Любой процессор" на "x86", если вы не видите опцию x86, нажмите "Configuration Manager" и перейдите к целевой проект и изменение платформы, вам нужно будет выбрать раскрывающийся список и нажать "Создать", во всплывающем окне выбрать раскрывающийся список под "новой платформой" и выбрать x86, сохранить изменения и перестроить (см. в приложении). 
)
Я отключил защиту файловой системы avast, после чего все снова заработало нормально. Установочное колесо avast = активная защита - верхняя кнопка выключена.
То же самое требуется для публикации проектов. Настоящий кошмар
У меня была проблема, подобная этой, когда я пытался использовать Debugger.Launch для отладки веб-приложения: окно выбора JIT Debugger никогда не появлялось. Я знал, что это не проблема с самим механизмом отладки VS, потому что он прекрасно работал с консольным приложением.
В конце концов, коллега упомянул "глобальную настройку реестра отладчика", которая включила лампочку.
Несколько месяцев назад я использовал DebugDiag от Microsoft для устранения неполадок, связанных со сбоем IIS, и у меня было зарегистрировано правило для записи аварийных дампов IIS, которое (ретроспективно) зарегистрировало службу диагностики отладки как отладчик для w3wp (рабочий процесс IIS).
Удаление правила в DebugDiag или остановка службы диагностики отладки ("C:\Program Files\DebugDiag\DbgSvc.exe") снова включили отладку JIT в Visual Studio.
Надеюсь, это кому-нибудь поможет.
После установки vs 2017 во время отладки решения возникла ошибка типа "Webkit перестал работать правильно; Visual Studio больше не сможет отлаживать ваше приложение"., это делает невозможным продолжить отладку. Чтобы решить эту проблему, перейдите в Инструменты-> Параметры-> Отладка-> Общие, затем отключите отладку javascript для asp.net.
В моем случае,
Я изменил платформу с x86 на x64 в диспетчере конфигурации отладки. Это сработало для меня.
У нас возникла эта проблема, после попытки всех других параметров, таких как удаление папки.vs, переименование имени папки IISExpress, обновление различных настроек свойств и т. Д., Она не работала. Однако сработало удаление IISExpress 10.0 и его переустановка, а также включение всех функций, связанных с IIS, из компонентов Windows. Надеюсь, это кому-нибудь поможет.
У меня была эта проблема, и ни один из (множества) постов здесь не помог. Большинство людей указывают на настройки или параметры, включение режима отладки и т. Д. Все это у меня уже было (я знал, что это не так, поскольку вчера все работало нормально).
Для меня это оказалось проблемой со ссылками, виновата была комбинация DLL, которые были включены. Я не могу точно сказать, в чем проблема, но у меня есть пара классов, которые расширяют базовые классы из другого проекта, реализованный интерфейс, который сам расширяется из другого интерфейса и т. Д.
Кислотный тест состоял в том, чтобы создать новый класс (в моем случае, модульный тест) в том же проекте, в котором не удалось выполнить отладку, затем создать пустой метод и установить для него точку останова. Это сработало, что еще раз подтвердило тот факт, что мои настройки / опции / и т. Д. Были хорошими. Затем я скопировал в тело метода, который не удалось отладить, и, конечно же, новый метод тоже начинает отказывать.
В конце я удалил все ссылки и закомментировал все строки в моем методе. Добавляя их обратно по очереди, проверяя отладку на каждом шаге, пока я не нашел виновника. У меня, очевидно, была где-то мошенническая ссылка...
В моем случае я обнаружил подсказку в окне вывода о том, что исключение, которое останавливало отладчик, было исключением ContextSwitchDeadlock, которое по умолчанию проверяется в настройках исключений. Это исключение обычно возникает через 60 секунд в консольных приложениях. Я только снял исключение, и все работало нормально.
У друга была такая же проблема, он не мог отлаживать в VS2015, но в VS2013 все было в порядке. (наш проект в.Net v4.0)
Мы обнаружили, что это был параметр "Тип кода" в "Отладке / Присоединении к процессу", который был установлен как "Управляемый (v3.5, v3.0, v2.0)" вместо "Управляемый (v4.5, v4.0").)"
Я обнаружил, что должен был зайти в настройки проекта -> Интернет и установить флажок "Включить редактирование и продолжить". Я не могу сказать, почему это было непроверено для начала, но это решило это для меня. 
Я изменил свою цель платформы с "Любой процессор" на "x64".
Настройка доступна в: Свойства проекта -> Сборка -> Общие: "Цель платформы"
Я использую VS 2015.
из обозревателя решений -> Интернет -> Свойства
выберите вкладку Build -> Combobox конфигурации:
Просто измените свою конфигурацию с "Release" на "Active (Debug)"
В моем случае это было связано с тем, что цели проекта были разными.
Рассмотрим: ProjectA (Entry) -> ProjectB
Платформа ProjectA в свойствах была установлена на x64. И платформа ProjectB была "AnyCPU".
Поэтому после установки целевой платформы ProjectB на x64 эта проблема была исправлена.
Примечание: просто целевая платформа должна быть синхронизирована, будь то x64 или "любой процессор"
У меня была такая же проблема. В моем случае dll, который я пытался отладить, был установлен в GAC. Если ваша точка отладки достигает точки, когда вы не ссылаетесь на какой-либо объект в целевой сборке, но нет, когда вы ссылаетесь на сборку, это может иметь место для вас.
Я тоже в этом вопросе. Я использую VS 2015 (обновление 3) в Windows 10 и пытаюсь отладить приложение Windows Forms. Ни одно из предложений не сработало для меня. В моем случае мне пришлось отключить IntelliTrace:
Сервис> Параметры> IntelliTrace
Я не знаю причину, почему, но это сработало. Я обнаружил корень проблемы, когда открыл Resource Monitor (из диспетчера задач Windows) и понял, что процесс IntelliTrace считывает тонны данных. Я подозреваю, что это вызывало блокировки в процессе vshost, потому что он потреблял 100% ядра процессора.
У меня была эта проблема после деинсталляции RemObjects Elements 8.3 Пробная версия. Переустановите элементы 8.3 - это быстрое исправление.
У меня такая же проблема. Попробовав другие решения здесь без удачи, мне пришлось восстанавливать установку через установщик.
Панель управления> Программы> Программы и компоненты
Затем прокрутите вниз до Microsoft Visual Studio, щелкните правой кнопкой мыши и выберите "Изменить". Затем в нижней части окна нажмите "Восстановить". Процесс восстановления займет приличное количество времени, и в конце вам придется перезагрузить компьютер.
Это решило проблему для меня, и я надеюсь, что это поможет вам.