Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом разделе перечислены все предварительные шаги, которые могут потребоваться перед отладкой приложения-службы. Какие шаги необходимы в вашем сценарии, зависит от выбранного варианта подключения и выбранной конфигурации отладки. Список этих вариантов см. в разделе Выбор оптимального метода отладки приложения-службы.
Каждый из этапов подготовки, описанных в этом разделе, определяет условия, при которых требуется. Эти действия можно выполнить в любом порядке.
Включение отладки кода инициализации
Если вы планируете отладить приложение-службу с начала его выполнения, включая код инициализации, этот подготовительный шаг требуется.
Найдите или создайте следующий раздел реестра, где ProgramName — это имя исполняемого файла приложения-службы:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ProgramName
ProgramName должен включать расширение имени файла, но не путь. Например, ProgramName может быть Myservice.exe или Thisservice.dll.
В этом разделе реестра создайте строковое значение данных с названием Debugger. Значение этой строки должно содержать полный путь и имя файла отладчика, которое будет присоединено к служебному приложению.
Если вы планируете выполнить локальную отладку, используйте следующую строку:
c:\Debuggers\windbg.exe
Не выбирайте этот параметр, если вы используете Windows Vista или более позднюю версию Windows.
Если вы планируете использовать удаленную отладку, укажите NTSD с параметром -noio. Это приводит к запуску NTSD без какой-либо консоли, доступной только через удаленное подключение. Например:
c:\Debuggers\ntsd.exe -server ServerTransport -noio -y SymbolPath
Если сеанс отладки начинается до полной загрузки Windows, возможно, вы не сможете получить доступ к символам из удаленной общей папки; В таком случае необходимо использовать локальные символы. ServerTransport должен указать транспортный протокол, который реализуется ядром Windows без взаимодействия со службой пользовательского режима, например TCP или NPIPE. Для синтаксиса ServerTransportсм. Активация сервера отладки.
Если вы планируете управлять отладчиком пользовательского режима из отладчика в режиме ядра, укажите NTSD с параметром -d. Например:
c:\Debuggers\ntsd.exe -d -y SymbolPath
Если вы планируете использовать этот метод, а символы пользовательского режима будут доступны с сервера символов, этот метод следует объединить с удаленной отладкой. В этом случае укажите NTSD с параметром -ddefer. Выберите транспортный протокол, реализованный ядром Windows без взаимодействия со службой пользовательского режима, например TCP или NPIPE. Например:
c:\Debuggers\ntsd.exe -server ServerTransport -ddefer -y SymbolPath
Для получения подробной информации см. Управление отладчиком User-Mode с помощью ядра отладчика.
После завершения этого изменения реестра отладчик запускается всякий раз, когда служба с этим именем запускается или перезапускается.
включение приложения-службы в отладчик
Если вы хотите, чтобы приложение-служба остановилось в отладчике в случае сбоя или исключения, необходимо выполнить этот подготовительный шаг. Этот шаг также требуется, если вы хотите, чтобы приложение-служба перешло в режим отладки, вызвав функцию DebugBreak.
Примечание Если вы включили отладку кода инициализации (шаг, описанный в подразделе "Включение отладки кода инициализации"), следует пропустить этот шаг. При включении отладки кода инициализации отладчик подключается к приложению-службе при запуске, благодаря чему все сбои, исключения и вызовы DebugBreak перенаправляются в отладчик без необходимости дополнительных подготовок.
Этот подготовительный шаг предполагает регистрацию выбранного отладчика в качестве посмертного отладчика. Это делается с помощью параметров -iae или -iaec в командной строке отладчика. Рекомендуется использовать следующие команды, но если вы хотите их изменить, см. сведения о синтаксисе в Включении отладки после завершения работы.
Если вы планируете выполнить локальную отладку, используйте следующую команду:
windbg -iae
Не выбирайте этот параметр, если вы используете Windows Vista или более позднюю версию Windows.
Если вы планируете использовать удаленную отладку, укажите NTSD с параметром -noio. Это приводит к запуску NTSD без какой-либо консоли, доступной только через удаленное подключение. Чтобы установить отладчик postmortem, включающий параметр -server, необходимо вручную изменить реестр. См. раздел Включение отладки postmortem для получения более подробной информации. Например, значение ключа AeDebug для Отладчик может быть следующим:
ntsd -server npipe:pipe=myproc%x -noio -p %ld -e %ld -g -y SymbolPath
В спецификации канала маркер %x заменяется идентификатором процесса процесса, запускающего отладчик. Это гарантирует, что если несколько процессов запускают отладчик postmortem, каждый из них имеет уникальное имя канала. Если сеанс отладки начинается до полной загрузки Windows, возможно, вы не сможете получить доступ к символам из удаленной общей папки; В таком случае необходимо использовать локальные символы. ServerTransport должен указать транспортный протокол, который реализуется ядром Windows без взаимодействия со службой пользовательского режима, например TCP или NPIPE. Для синтаксиса ServerTransportсм. Активация сервера отладки.
Если вы планируете управлять отладчиком пользовательского режима из отладчика в режиме ядра, укажите NTSD с параметром -d. Например:
ntsd -iaec -d -y SymbolPath
Если этот метод выбран и планируется получить доступ к символам пользовательского режима с сервера символов, этот метод следует объединить с удаленной отладкой. В этом случае укажите NTSD с параметром -ddefer. Выберите транспортный протокол, реализованный ядром Windows без взаимодействия со службой пользовательского режима, например TCP или NPIPE. Чтобы установить отладчик postmortem, включающий параметр -server, необходимо вручную изменить реестр; Дополнительные сведения см. в разделе Включениеотладки postmortem. Например, значение Debugger ключа AeDebug может быть следующим:
ntsd -server npipe:pipe=myproc%x -ddefer -p %ld -e %ld -g -y SymbolPath
Для получения подробной информации см. Управление отладчиком User-Mode с помощью ядра отладчика.
При выполнении одной из этих команд отладчик postmortem заносится в реестр. Этот отладчик запускается всякий раз, когда любая программа пользовательского режима, включая приложение-службу, обнаруживает исключение или запускает функцию DebugBreak.
настройка времени ожидания приложения-службы
Если вы планируете автоматически запустить отладчик (либо при запуске службы, либо при возникновении исключения), этот подготовительный шаг требуется.
Найдите следующий ключ реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
В этом разделе найдите или создайте значение данных DWORD с именем ServicesPipeTimeout. Задайте для этой записи время в миллисекундах, которое требуется, чтобы служба ждала до истечения времени ожидания. Например, значение 60 000 составляет одну минуту, а значение 86 400 000 составляет 24 часа. Если это значение реестра не задано, время ожидания по умолчанию составляет около тридцати секунд.
Значимость этого показателя заключается в том, что с запуском каждой службы начинают отсчитываться часы, и когда достигается значение времени ожидания, все отладчики, подключенные к службе, завершаются. Поэтому выбранное значение должно превышать общее время, которое истекает между запуском службы и завершением сеанса отладки.
Этот параметр применяется к каждой службе, запущенной или перезапускаемой после завершения редактирования реестра. Если какая-либо служба завершается сбоем или зависает, и этот параметр все еще активен, проблема не обнаруживается Windows. Поэтому следует использовать эту настройку только во время отладки, а после её завершения вернуть значение ключа реестра к исходному.
Изоляция службы
Иногда несколько служб объединяются в единственный процесс службы хоста (Svchost). Если вы хотите отладить такую службу, необходимо сначала изолировать ее в отдельном процессе Svchost.
Существует три метода, с помощью которых можно изолировать службу. Корпорация Майкрософт рекомендует метод перемещения службы в собственную группу. Альтернативные методы (изменение типа службы и дедупликация двоичного файла SvcHost) можно использовать на временной основе для отладки, но поскольку они изменяют способ выполнения службы, они не так надежны, как первый метод.
Предпочтительный метод: перемещение сервиса в собственную группу
Выполните следующую команду средства настройки службы (Sc.exe), где Имя_службы — это имя службы:
sc qc ServiceName
Здесь отображаются текущие значения конфигурации для службы. Значение интереса — BINARY_PATH_NAME, указывающее командную строку, используемую для запуска программы управления службами. В этом сценарии, так как служба еще не изолирована, эта командная строка содержит путь к каталогу, Svchost.exeи некоторые параметры SvcHost, включая параметр -k, а затем имя группы. Например, это может выглядеть примерно так:
%SystemRoot%\System32\svchost.exe -k LocalServiceNoNetwork
Помните этот путь и имя группы; они используются в шагах 5 и 6.
Найдите следующий ключ реестра:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SvcHost
Создайте новое значение REG_MULTI_SZ с уникальным именем (например, TempGrp).
Задайте это новое значение, равное имени службы, которую требуется изолировать. Не включайте ни один путь к каталогу или расширение имени файла. Например, можно задать новое значение TempGrp равным MyService.
В том же разделе реестра создайте новый раздел с тем же именем, который использовался на шаге 2. Например:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SvcHost\TempGrp
Теперь ключ SvcHost содержит значение с новым именем и имеет подчиненный ключ с таким же именем.
Найдите другой ключ, подчиненный ключу SvcHost, который имеет то же имя, что и группа, которую вы нашли на шаге 1. Если такой ключ существует, проверьте все значения в нем и создайте дубликаты в новом ключе, созданном на шаге 4.
Например, старый ключ может называться следующим образом:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SvcHost\LocalServiceNoNetwork
и он может содержать такие значения, как CoInitializeSecurityParam, AuthenticationCapabilitiesи другие значения. Вы перейдете к только что созданному ключу:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SvcHost\TempGrp
и создайте в нем значения, идентичные имени, типу и данным, которые находятся в старом ключе.
Если старый ключ не существует, вам не нужно создавать новый ключ.
Используйте следующую команду средства настройки службы, чтобы изменить путь, найденный на шаге 1.
sc config ServiceName binPath= "RevisedPath"
В этой команде
ServiceName — это имя службы, а RevisedPath — это новое значение, которое вы предоставляете для BINARY_PATH_NAME. Для RevisedPathиспользуйте тот же самый путь, что и на шаге 1, включая все параметры, показанные в этой строке, внося только одно изменение: замените параметр, следующий за переключателем -k, на имя нового значения реестра, созданного на шаге 2. Заключите RevisedPath в кавычки. Пробел после знака равенства требуется.Например, команда может выглядеть следующим образом:
sc config MyService binPath= "%SystemRoot%\System32\svchost.exe -k TempGrp"
Вы можете снова использовать команду sc qc, чтобы просмотреть внесенные изменения.
Эти параметры вступают в силу при следующем запуске службы. Чтобы очистить эффекты старой службы, рекомендуется перезапустить Windows, а не просто перезапустить службу.
После завершения отладки, если вы хотите вернуть эту службу на узел общей службы, используйте команду sc config еще раз, чтобы вернуть двоичный путь к исходному значению и удалить новые разделы реестра и значения, которые вы создали.
альтернативный метод : изменение типа службы
Выполните следующую команду средства настройки службы (Sc.exe), где Имя_службы — это имя службы:
sc config ServiceName type= own
Пробел после знака равенства требуется.
Перезапустите службу с помощью следующих команд:
net stop ServiceName net start ServiceName
Это не рекомендуемый метод, так как он может изменить поведение службы. Если вы используете этот метод, используйте следующую команду, чтобы вернуться к нормальному поведению после завершения отладки:
sc config ServiceName type= share
Альтернативный метод: дублирование исполняемого файла SvcHost
Исполняемый файл Svchost.exe находится в каталоге System32 Windows. Создайте копию этого файла, назовите его svhost2.exeи поместите его в каталог system32.
Выполните следующую команду средства настройки службы (Sc.exe), где Имя_службы — это имя службы:
sc qc ServiceName
Эта команда отображает текущие значения конфигурации для службы. Значение интереса — BINARY_PATH_NAME, указывающее командную строку, используемую для запуска программы управления службами. В этом сценарии, так как служба еще не изолирована, эта командная строка будет содержать путь к каталогу, Svchost.exeи, вероятно, некоторые параметры SvcHost. Например, это может выглядеть примерно так:
%SystemRoot%\System32\svchost.exe -k LocalServiceNoNetwork
Чтобы изменить этот путь, выполните следующую команду:
sc config ServiceName binPath= "RevisedPath"
В этой команде
ServiceName — это имя службы, а RevisedPath — это новое значение, которое вы предоставляете для BINARY_PATH_NAME. Для RevisedPathиспользуйте точно такой же путь, как показано на шаге 2, включая все параметры, указанные в этой строке, с единственным изменением: замените Svchost.exe на Svchost2.exe. Заключите RevisedPath в кавычки. Пробел после знака равенства требуется.Например, команда может выглядеть следующим образом:
sc config MyService binPath= "%SystemRoot%\System32\svchost2.exe -k LocalServiceNoNetwork"
Вы можете использовать команду sc qc еще раз, чтобы просмотреть изменения, которые вы внесли.
Перезапустите службу с помощью следующих команд:
net stop ServiceName net start ServiceName
Это не рекомендуемый метод, так как он может изменить поведение службы. Если вы используете этот метод, используйте команду sc config, чтобы изменить путь обратно на исходное значение после завершения отладки.