Присоединиться к процессу visual studio что это

Присоединение к программе

Область применения:Visual Studio Visual Studio для Mac Visual Studio Code

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

Выбор способа присоединения

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

Для программ, запускаемых подсистемой отладки с помощью метода LaunchSuspended (типичный для интерпретированных языков, например), SDM получает интерфейс IDebugProgramNodeAttach2 из объекта IDebugProgramNode2, связанного с присоединенной программой. Если SDM может получить IDebugProgramNodeAttach2 интерфейс, SDM вызывает метод OnAttach . Метод IDebugProgramNodeAttach2::OnAttach возвращается S_OK , чтобы указать, что он не был присоединен к программе и что другие попытки можно выполнить для присоединения к программе.
Если SDM может получить интерфейс IDebugProgramEx2 из подключенной программы, SDM вызывает метод Attach . Этот подход является типичным для программ, которые были запущены удаленно поставщиком портов.
Если программа не может быть подключена через IDebugProgramNodeAttach2::OnAttach метод или IDebugProgramEx2::Attach методы, SDM загружает подсистему отладки (если она еще не загружена), вызывая CoCreateInstance функцию, а затем вызывает метод Attach . Этот подход является типичным для программ, запускаемых локально поставщиком портов. Кроме того, поставщик пользовательского порта может вызвать IDebugEngine2::Attach метод в реализации поставщика пользовательского IDebugProgramEx2::Attach порта. Как правило, в этом случае поставщик пользовательского порта запускает подсистему отладки на удаленном компьютере. Вложение достигается, когда диспетчер отладки сеанса вызывает метод Attach . Если вы запускаете de de в том же процессе, что и приложение для отладки, необходимо реализовать следующие методы IDebugProgramNode2:

GetHostName
GetHostPid
GetProgramName IDebugEngine2::Attach После вызова метода выполните следующие действия в реализации IDebugEngine2::Attach метода:

Примечание. При реализации IDebugProgramNodeAttach2 интерфейса программа GUID передается методу IDebugProgramNodeAttach2::OnAttach . Используется GUID для возвращаемых методом IDebugProgram2::GetProgramId программ GUID .

Примечание. Это не тот же IDebugProgram2 объект, который был передан в IDebugEngine2::Attach метод. Ранее переданный IDebugProgram2 объект распознается только портом и является отдельным объектом.

Связанный контент

Вложение на основе запуска
Отправка событий
LaunchSuspended
IDebugProgram2
IDebugProgramCreateEvent2
IDebugProgramNodeAttach2
OnAttach
IDebugProgramNode2
GetProgramId
IDebugProgramEx2
Присоединить
Присоединить

Удаленная отладка в Visual Studio Code по SSH

В инструкции описано, как используя стандартные средства Visual Studio Code подключиться к Jupyter Server по SSH.

Перед началом работы
Подключиться к Visual Studio Code по SSH
Результат

Перед началом работы

Убедитесь, что скачан требуемый SSH-ключ. Подробнее в инструкции .

Подключиться к Visual Studio Code по SSH

Для удаленной отладки через Visual Studio Code:

Установите в Visual Studio Code расширение Remote Development.
В Visual Studio Code нажмите F1 и найдите «Add New SSH Host…».
Выберите конфигурационный файл, например path/to/private_id_rsa_key.txt , и в пункте Remote-SSH: Connect to Host… введите:

ssh name.ai0001011-00560@ssh-jupyter.ai.cloud.ru -p 2222 -i path/to/private_id_rsa_key.txt

Результат

В результате будет осуществлено подключение с помощью стандартных средств Visual Studio Code.

Руководство по удаленной отладке через SSH в Visual Studio Code
Команда для подключения по SSH
Расширение для работы на удаленном хосте
Инструкция по выбору интерпретатора

Не удается присоединиться к процессу

Область применения:Visual Studio Visual Studio для Mac Visual Studio Code

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

Существуют два типичных скрипта, вызывающих эту ошибку:

Сценарий 1. Компьютер A работает под управлением Windows XP. Компьютер B работает под управлением Windows Server 2003. Реестр на компьютере B содержит следующее значение DWORD:

Пользователь 1 запускает сеанс службы терминалов (сеанс 1) на компьютере B и запускает управляемое приложение из этого сеанса.

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

Сценарий 2. Один пользователь зашел в систему на двух компьютерах — A и B — в одной и той же рабочей группе, используя одинаковые пароли на обоих компьютерах. Отладчик выполняется на компьютере A и пытается подключиться к управляемому приложению, работающему на компьютере B. Компьютер A имеет сетевой доступ: модель общего доступа и безопасности для локальных учетных записей , для которых задано значение Guest.

Решение скрипта 1

Запустите отладчик и управляемое приложение под одним и тем же именем учетной записи пользователя и паролем.

Решение скрипта 2

В меню Пуск выберите Панель управления.
На панели управления дважды щелкните Администрирование.
В окне «Администрирование» дважды щелкните пункт Локальная политика безопасности.
В окне «Локальная политика безопасности» выберите Локальные политики.
В столбце Политики дважды щелкните Сетевой доступ: модель совместного доступа и безопасности для локальных учетных записей.
В диалоговом окне Доступ к сети: модели безопасности и совместного использования локальных учетных записей измените локальный параметр безопасности на Классический и нажмите кнопку ОК.

Внимание Изменение модели безопасности на обычную может привести к непредвиденным возможностям доступа к общим файлам и DCOM-компонентам. Если сделать это, удаленный пользователь сможет проходить проверку подлинности под локальной учетной записью пользователя вместо записи «Гость». Если удаленный пользователь совпадает с именем пользователя и паролем, он сможет получить доступ к любой папке или объекту DCOM, которым вы предоставили общий доступ. Если вы используете эту модель безопасности, убедитесь, что все учетные записи пользователей на компьютере имеют надежные пароли или настройте изолированный сетевой остров для отладчика и отладки компьютеров, чтобы предотвратить несанкционированный доступ.

См. также

Выявление неисправностей работы служб Windows

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

Разработку службы лучше всего начинать с создания сборки со всеми желаемыми функциональными возможностями и тестового клиентского приложения. Тогда отладку и обработку ошибок можно производить самым обычным образом, а когда тестовое приложение будет готово, просто создать службу с использованием этой сборки. Разумеется, впоследствии со службой могут возникать и другие проблемы. Ниже приведен ряд рекомендаций:

Не отображайте сообщения об ошибках службы в окне сообщений (если только служба не является интерактивной, запускаемой на клиентской системе). Вместо этого следует применять службу регистрации событий, чтобы все ошибки фиксировались в журнале событий. Естественно, в клиентском приложении, где используется служба, можно отображать окно с сообщениями об ошибках для уведомления пользователей.
Запускать службу в отладчике нельзя, но зато отладчик можно подключить к работающему процессу службы. Для этого необходимо сначала открыть решение с исходным кодом службы и расставить точки останова, а затем в меню Debug (Отладка) в Visual Studio выбрать команду Processes (Процессы) и присоединиться к работающему процессу службы.
Для наблюдения за активностью служб можно применять программу Performance Monitor (Монитор производительности). Она позволяет добавлять для службы собственные объекты производительности. В результате можно получить дополнительную информацию для отладки. Например, для службы цитат можно было бы создать объект, отслеживающий общее количество возвращаемых цитат, время, затрачиваемое на инициализацию и т.д.

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