Необычное поведение с отладчиком Visual Studio; "Не удалось найти местоположение сети" (ERROR_NETWORK_UNREACHABLE)

Ответ 1

Хорошо, это так неправильно

У меня также есть проблемы с этой ошибкой, и в моем случае это произошло каждый другой сеанс отладки. Это означает, что debug → stop → debug → bug → restart visual studio → go to start (повторяется каждую минуту в течение всего дня).

Излишне говорить, что меня заставили найти решение. Поэтому вчера я попробовал procmon, часами смотрю на различия в мониторинге API, посмотрел на плагины, netstat и т.д. И т.д. И т.д. И ничего не нашел. Я сдался.

Сегодня

До сегодняшнего дня.

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

void* dst = _aligned_malloc(4096, 32);
memcpy(dst, src, 8192);

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

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

Итак, что происходит,

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

Я вижу, что вы думаете: нет, этого не должно быть... вы правы; но, по-видимому, это так.

Итак, как это исправить? В основном исправление вашей программы (более конкретно: проблемы с повреждением кучи), похоже, устраняет ошибку отладчика VS. Использование appverifier.exe(оно в средствах отладки для Windows) даст вам начало.

Почему это работает

Поскольку VS2012, VС++ использует другой способ управления кучей. Ханс Пассант объясняет это здесь: Использует ли msvcrt другую кучу для распределений с (vs2012/2010/2013).

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

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

"Тест"

• Перед использованием apverifier - ошибка запускается каждые 2 минуты
• При использовании appverifier - отладчик VS был стабильным в течение 5 дней (и подсчета)

Ответ 2

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

• Начиная с VS2012, библиотека времени C имела довольно резкую модификацию, которая может очень затруднить диагностику неправильного поведения, если ваша программа развращает кучу. Многое напоминает @atlaste. Поскольку временный мемориал, CRT всегда создавал свою собственную кучу, основным вызовом был HeapCreate(). Нет больше, теперь он использует GetProcessHeap(). Это очень удобно, гораздо проще теперь обращаться к DLL, которые были построены с помощью /MT. Но с довольно резким краем вы теперь можете легко повредить память, принадлежащую коду Microsoft. Не сильно указано, если вы не можете повторно подключить 64-разрядную программу, вам нужно будет убить msvsmon.exe, чтобы очистить повреждение.

• Сервер Microsoft Symbol поставляет PDB для исполняемых файлов Microsoft. У них обычно есть информация об источнике + номер строки, но не все. В частности, не для ЭЛТ, например. Эти PDB были построены на сервере сборки, принадлежащем DevDiv в Редмонде, который имел исходный код на диске F:. Несколько из них были построены с диска E:, Patterns + Practices использует это (маловероятно в программе на С++). Ваш отладчик пойдет посмотреть там, чтобы попытаться найти исходный код. Обычно это заканчивается хорошо, оно быстро отбрасывается, но не в том случае, если ваша машина также использует эти буквы дисков. Диагностируйте, очистив кеш символов и отключив сервер символов с помощью инструментов + Параметры, Отладка, Символы.

• Winapi страдает от двух неприятных вирусных инфекций, которые он унаследовал от другой ОС, которые добавляют глобальное состояние к любому процессу. Переменная окружения PATH и рабочий каталог по умолчанию. Используйте Панель управления + Система + Дополнительно + Среда, чтобы просмотреть PATH, скопировать/вставить содержимое преднамеренно маленьких текстовых полей в текстовый редактор. Удостоверьтесь, что он скрипучий чистый, некоторый паралич при обычном беспорядке - нормальный кстати. Не берите пленников. Проблемы с каталогом по умолчанию гораздо труднее устранить. Оба должны выскочить, когда вы используете Process Monitor.

Никаких объяснений, это сложная проблема, но темные углы вы можете посмотреть.

Ответ 3

У меня та же проблема. Думал, что это связано с 64-битными консольными приложениями, где он очень легко запускается практически с любого сеанса отладки. Но это также происходит и в 64-битных окнах. Теперь я вижу это в 32-битных Windows-приложениях. Я запускаю Windows 8.1 pro на одном рабочем столе с последней версией vs 2013 и без удаленной отладки. Мои (добавленные) расширения - это Visual Assist, Advanced Installer, ClangFormat, выравнивание кода, сравнение кода, дублирующий выбор, инструменты Powerivity 2013 и Visual SVN.

Я обнаружил, что файл "Visual Studio 2013\Settings\CurrentSettings.vssettings" поврежден. Вы можете удалить этот файл и воссоздать его, перезапустив VS, или вы можете попробовать отредактировать XML. Затем я сохраняю копию хорошего файла настроек, который я использую для замены, когда он снова повреждается.

В моем случае поврежденная строка начинается с

</ToolsOptionsSubCategory><ToolsOptionsSubCategory name="XAML" RegisteredName="XAML"

... и это очень долго (я думаю, именно поэтому он подвержен коррупции).

Ответ 4

Я просто отключен в меню

Инструменты > Параметры

Отладкa > Изменить и продолжить

Параметры только для родного вариантa > Включить native Изменить и продолжить

и теперь это не дает ту тупую ошибку, которая препятствовала запуску приложения debuggee.

Ответ 5

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

Наконец, решение, упомянутое в https://social.msdn.microsoft.com/Forums/vstudio/en-US/8dce0952-234f-4c18-a71a-1d614b44f256/visual-studios-2012-cannot-findlaunch-project-exe?forum=vsdebug

работал. Reset все настройки визуальной студии с помощью Tools- > Import and Export settings. Теперь проблема не возникает.