Tlist exe windows 10 где находится

Обновлено: 07.07.2024

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

закрытое виртуальное адресное пространство, являющееся набором адресов виртуальной памяти, которым процесс может воспользоваться;
исполняемую программу, определяющую исходный код и данные, и отображаемую на виртуальное адресное пространство процесса;
перечень открытых дескрипторов (описателей) различных системных ресурсов — семафоров, коммуникационных портов и файлов, доступных всем потокам процесса;
связанную с процессом среду безопасности, называемую маркером доступа, идентифицирующим пользователя, группы безопасности, права доступа, виртуализированное состояние системы управления учетными записями пользователей — User Account Control (UAC), сессию и ограниченное состояние учетной записи пользователя;
уникальный идентификатор, называемый идентификатором процесса, - process ID (внутренняя часть идентификатора называется идентификатором клиента — client ID);
как минимум один поток выполнения (хотя возможен и абсолютно бесполезный «пустой» процесс).

Каждый процесс также указывает на свой родительский процесс или процесс-создатель. Если родительского процесса больше нет, эта информация не обновляется. Поэтому процесс может указывать на уже несуществующий родительский процесс. Это не создает никаких проблем, поскольку от актуальности этой информации ничего не зависит. При использовании программы исследования процессов ProcessExplorer берется в расчет время запуска родительского процесса, чтобы избежать присоединения дочернего процесса на основе повторно используемого идентификатора процесса. Такое поведение иллюстрируется экспериментом, описанным ниже.

Эксперимент: просмотр дерева процессов.

Одним из уникальных атрибутов, относящихся к процессу и неотображаемых большинством инструментальных средств, является идентификатор родительского процесса или процесса-создателя (parent or creator process ID).

Это значение можно извлечь с помощью Системного монитора (Performance Monitor) или программным способом, путем запроса Creating Process ID.

Дерево процессов может показать такое средство, как Tlist.exe (из состава предназначенных для Windows средств отладки Debugging Tools), используемое с ключом /t. Рассмотрим пример вывода, полученного в результате выполнения команды tlist /t:

System Process (0)

conhost.exe (3076) OleMainThreadWndName

dwm.exe (2912) DWM Notification Window

taskhost.exe (2816) Task Host Window

explorer.exe (2968) Program Manager

cmd.exe (1832) Administrator: C:\Windows\system32\cmd.exe - "c:\tlist.exe" /t

Чтобы показать взаимоотношения каждого процесса с его родительскими и дочерними процессами, применяются отступы. Процессы, родители которых прекратили свое существование, выровнены по левому краю (как Explorer.exe в предыдущем примере), поскольку, даже при наличии прародительского процесса, способов обнаружения связи с ним просто не существует. Windows сохраняет только идентификатор процесса-создателя и не дает ссылок на создателя этого создателя и т. д.

Чтобы продемонстрировать тот факт, что Windows не отслеживает более одного идентификатора родительского процесса, выполните следующие действия:

Откройте окно командной строки.
Наберите title Parent, чтобы изменить заголовок окна на «Parent» (родительский).
Наберите start cmd (что приведет к запуску второго окна командной строки).
Наберите во втором окне командной строки title Child, чтобы изменить заголовок окна на «Child» (дочерний).
Откройте Диспетчер задач.
Наберите во втором окне командной строки mspaint (команду, запускающую Microsoft Paint).
Снова обратитесь ко второму окну командной строки и наберите exit. (Заметьте, что Paint остается в рабочем состоянии.)
Перейдите в Диспетчер задач.
Щелкните на вкладке "Приложения".
Щелкните правой кнопкой мыши на задаче Parent и выберите пункт "Перейти к процессу".
Щелкните правой кнопкой мыши на процессе cmd.exe и выберите пункт "Завершить дерево процессов".
В окне подтверждения Диспетчера задач щелкните на кнопке "Завершить дерево процессов".

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

Для просмотра процессов и информации о них (а также для внесения изменений) используется несколько инструментальных средств. В описанных ниже экспериментах иллюстрируются различные виды информации о процессах, которые могут быть получены с помощью некоторых из этих средств. Большинство этих средств входит в состав самой Windows, а также в состав отладочного комплекта Debugging Tools for Windows и в состав Windows SDK, но есть и другие автономные средства под маркой Sysinternals. Многие из этих средств показывают частично совпадающие поднаборы сведений об основных процессах и потоках, которые иногда идентифицируются по-разному.

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

tlist.exe это исполняемый файл, который является частью Инструменты отладки для Windows x64 Программа, разработанная Корпорация Microsoft, Программное обеспечение обычно о 15.21 MB по размеру.

Расширение .exe имени файла отображает исполняемый файл. В некоторых случаях исполняемые файлы могут повредить ваш компьютер. Пожалуйста, прочитайте следующее, чтобы решить для себя, является ли tlist.exe Файл на вашем компьютере - это вирус или троянский конь, который вы должны удалить, или это действительный файл операционной системы Windows или надежное приложение.

Это tlist.exe безопасно, или это вирус или вредоносная программа?

Первое, что поможет вам определить, является ли тот или иной файл законным процессом Windows или вирусом, это местоположение самого исполняемого файла. Например, такой процесс, как tlist.exe, должен запускаться, а не где-либо еще.

Для подтверждения откройте диспетчер задач, выберите «Просмотр» -> «Выбрать столбцы» и выберите «Имя пути к изображению», чтобы добавить столбец местоположения в диспетчер задач. Если вы обнаружите здесь подозрительный каталог, возможно, стоит дополнительно изучить этот процесс.

Еще один инструмент, который иногда может помочь вам обнаружить плохие процессы, - это Microsoft Process Explorer. Запустите программу (не требует установки) и активируйте «Проверить легенды» в разделе «Параметры». Теперь перейдите в View -> Select Columns и добавьте «Verified Signer» в качестве одного из столбцов.

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

Самые важные факты о tlist.exe:

Если у вас возникли какие-либо трудности с этим исполняемым файлом, вы должны определить, заслуживает ли он доверия, перед удалением tlist.exe. Для этого найдите этот процесс в диспетчере задач.

Найдите его местоположение (оно должно быть в C: \ Program Files \ средства отладки для Windows (x64)) и сравните размер и т. Д. С приведенными выше фактами.

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

Могу ли я удалить или удалить tlist.exe?

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

Согласно различным источникам онлайн, 9% людей удаляют этот файл, поэтому он может быть безвредным, но рекомендуется проверить надежность этого исполняемого файла самостоятельно, чтобы определить, является ли он безопасным или вирусом. Лучшая диагностика для этих подозрительных файлов - полный системный анализ с Reimage, Если файл классифицирован как вредоносный, эти приложения также удалят tlist.exe и избавятся от связанных вредоносных программ.

Однако, если это не вирус, и вам нужно удалить tlist.exe, вы можете удалить Средства отладки для Windows x64 со своего компьютера, используя его деинсталлятор, который должен находиться по адресу: MsiExec.exe / I . Если вы не можете найти его деинсталлятор, то вам может потребоваться удалить средства отладки для Windows x64, чтобы полностью удалить tlist.exe. Вы можете использовать функцию «Установка и удаление программ» на панели управления Windows.

1. в Меню Пуск (для Windows 8 щелкните правой кнопкой мыши в нижнем левом углу экрана), нажмите Панель управления, а затем под Программы:
o Windows Vista / 7 / 8.1 / 10: нажмите Удаление программы.
o Windows XP: нажмите Установка и удаление программ.

2. Когда вы найдете программу Инструменты отладки для Windows x64щелкните по нему, а затем:
o Windows Vista / 7 / 8.1 / 10: нажмите Удалить.
o Windows XP: нажмите Удалить or Изменить / Удалить вкладка (справа от программы).

3. Следуйте инструкциям по удалению Инструменты отладки для Windows x64.

Наиболее распространенные ошибки tlist.exe, которые могут возникнуть:

• «Ошибка приложения tlist.exe».
• «Ошибка tlist.exe».
• «tlist.exe столкнулся с проблемой и должен быть закрыт. Приносим извинения за неудобства».
• «tlist.exe не является допустимым приложением Win32».
• «tlist.exe не запущен».
• «tlist.exe не найден».
• «Не удается найти tlist.exe».
• «Ошибка запуска программы: tlist.exe.»
• «Неверный путь к приложению: tlist.exe.»

Аккуратный и опрятный компьютер - это один из лучших способов избежать проблем с Debugging Tools for Windows x64. Это означает выполнение сканирования на наличие вредоносных программ, очистку жесткого диска cleanmgr и ПФС / SCANNOWудаление ненужных программ, мониторинг любых автозапускаемых программ (с помощью msconfig) и включение автоматических обновлений Windows. Не забывайте всегда делать регулярные резервные копии или хотя бы определять точки восстановления.

Если у вас возникла более серьезная проблема, постарайтесь запомнить последнее, что вы сделали, или последнее, что вы установили перед проблемой. Использовать resmon Команда для определения процессов, вызывающих вашу проблему. Даже в случае серьезных проблем вместо переустановки Windows вы должны попытаться восстановить вашу установку или, в случае Windows 8, выполнив команду DISM.exe / Online / Очистка-изображение / Восстановить здоровье, Это позволяет восстановить операционную систему без потери данных.

Чтобы помочь вам проанализировать процесс tlist.exe на вашем компьютере, вам могут пригодиться следующие программы: Менеджер задач безопасности отображает все запущенные задачи Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записи автозапуска. Единый рейтинг риска безопасности указывает на вероятность того, что это шпионское ПО, вредоносное ПО или потенциальный троянский конь. Это антивирус обнаруживает и удаляет со своего жесткого диска шпионское и рекламное ПО, трояны, кейлоггеры, вредоносное ПО и трекеры.

Обновлено ноябрь 2021 г .:

Мы рекомендуем вам попробовать это новое программное обеспечение, которое исправляет компьютерные ошибки, защищает их от вредоносных программ и оптимизирует производительность вашего ПК. Этот новый инструмент исправляет широкий спектр компьютерных ошибок, защищает от таких вещей, как потеря файлов, вредоносное ПО и сбои оборудования.

(опциональное предложение для Reimage - Cайт | Лицензионное соглашение | Политика конфиденциальности | Удалить)

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

Эти тулзы содержат мощные отладчики (WinDbg, Cdb) и позволяют делать всякие полезности, типа создания symservers (symstore.exe), создания дампа с процесса (cdb, windbg), отладки мемори ликов (umdh.exe) и других ошибок работы с памятью (gflags — позволяет включать многие «скрытые» системные проверки как для конкретного exe файла, так и для всей системы в целом). Также в комплекте есть много других полезных тулзов, типа просмотрщика debug output.

Например, как получить мемори лики для любой программы:
Нам понадобится umdh.exe, tlist.exe и gflags.exe. Все их надо запускать с админскими правами.
Запускаем gflags.exe, выставляем галочку Create user mode stack database. Перезагружаемся — теперь для всех запущенных программ будет создаваться этот database. Можно для каждого приложения отдельно настроить.
Далее запускаем нужную программу, ждем, пока все загрузится и получаем PID программы с помощью tlist.exe (или как угодно еще). Например, PID == 111.
Далее запускаем umdh.exe -p:111 -f:c:\temp\log1.log
Эта строка сохранит в файл log1.log инфу о всех текущих выделениях памяти в процессе 111.
Далее работаем в программе, ждем сколько-нибудь времени и снова пишем:
umdh.exe -p:111 -f:c:\temp\log2.log
Получаем второй лог с выделениями памяти.
Теперь их можно сравнить и получить лики:
umdh.exe -d -v -l c:\temp\log1.log c:\temp\log2.log 1> c:\temp\log_result.log
Теперь у нас в log_result.log будут все выделенные и не освобожденные куски памяти с калстэками!
Чтобы калстэки были правильные, нужно настроить enviroment variable _NT_SYMBOL_PATH. В хелпе написано, как его настроить для майкрософтовских exe и dll.
Свои pdb лучше всего сохранять на symbol server, который можно пополнять после билдов с помощью symstore.exe — тогда всегда отладчик будет иметь правильный pdb.
Если сервера нет, можно просто положить pdb рядом с ехе — должен подцепиться. Если не подцепится, то добавить путь к pdb в _NT_SYMBOL_PATH.

Если у вас есть дамп файл и надо его проверить, то опять же проще всего использовать WinDbg. Он использует ту же переменную _NT_SYMBOL_PATH и, в отличие от VisualStudio, он не требует ни исходников ни правильных бинарников для отладки. Просто дамп и подходящий pdb! Запускаешь WinDbg.exe, File\open crash dump. открываешь дамп, пишешь !analyze -v, потом !uniqstack и уже обычно этого достаточно в простых случаях. Видишь, какие pdb нашлись, какие нет и получаешь анализ дампа. Можно открыть окошки с callstack, Processes and threads и отлаживаться. Если надо увидеть код — File\Source File Path… — указать путь к исходникам и можно смотреть место в коде, где что произошло (лучше сразу эти пути прописать в enviroment variable _NT_SOURCE_PATH, чтобы не вбивать их каждый раз). Короче, опять все просто и удобно, если есть правильный pdb :)

Проблемы с зависаниями чего-либо отлично решаются с помощью создания дампа зависшего процесса. Для этого можно использовать тот же WinDbg или специальные проги или стандартную системную фичу в висте в таск менеджере — создать дамп:)
Причем DebuggingTools можно установить уже после зависания — никакой перезагрузки не надо. Установил — снял дамп. Для снятия дампа юзеру не надо никаких pdb.
Потом этот дамп анализируешь и исправляешь (в Windbg есть специальные команды для поиска дедлоков и т.п. — команда !locks и другие).

Вывод:
Чтобы не иметь проблем с отладкой, надо озаботиться системой хранения pdb файлов для КАЖДОГО билда ну или хотя бы для официальных билдов. А также изучить Debugging tools и написать простые рекоммендации тестерам и программистам — что делать в случае ошибки или зависания, как создавать дамп, куда его класть и с какими коментариями. А некоторые тестеры даже могут запускать WinDBG и копипастить в отчет о баге оттуда нужные данные типа калстэка с ошибкой — очень помогает в предварительном анализе.

WinDBG – прекрасный отладчик. Возможно, у него не очень дружественный интерфейс и нет по умолчанию черного фона, но это один из самых мощных и стабильных отладчиков в ОС Windows в настоящее время. В этой статье я познакомлю вас с основами WinDBG, чтобы вы могли начать с ним работу.

Автор: Брэд Антониевич (Brad Antoniewicz)

Эта первая статья из цикла, посвященного WinDBG. Перечень всех статей, входящих в этот цикл:

Часть 1 – установка, интерфейс, символы, удаленная/локальная отладка, система помощи, модули, регистры.
Часть 2 – точки останова.
Часть 3 – инспектирование памяти, пошаговая отладка программ, советы и трюки.

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

Установка WinDBG

По сравнению с Windows 7 процесс установки WinDBG в Windows 8 претерпел небольшие изменения. В этом разделе мы рассмотрим установку отладчика для обеих операционных систем.

Установка WinDBG в Windows 8

В Windows 8 WinDBG включается в пакет Windows Driver Kit (WDK). Вы можете установить Visual Studio и WDK или установить отдельно пакет «Debugging Tools for Windows 8.1», который включает WinDBG.

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

Рисунок 1: Выбор типа установки

В следующем окне вам необходимо снять флажки со всех пунктов кроме «Debugging Tools for Windows» и нажать на кнопку «Download».

Как только установщик закончит свою работу, зайдите в директорию, куда загрузился пакет (по умолчанию это c:\Users\Username\Downloads\Windows Kits\8.1\StandaloneSDK) и пройдите процедуру установки.

Установка WinDBG в Windows 7 и более ранних версиях

Во время установки я выбираю опцию «Debugging Tools» в разделе «Redistributable Packages», чтобы создать автономный инсталлятор для облегчения последующих установок.

Рисунок 2: Выбор опций установки для создания автономного инсталлятора

По завершению установки, у вас должны появиться инсталляторы WinDBG для различных платформ (в директории c:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\ ).

Рисунок 3: Папка с инсталляторами WinDBG для различных платформ

Далее процесс установки довольно прост. Вам нужно лишь скопировать соответствующий файл на ту машину, где вы собираетесь проводить отладку, и пройти процедуру установки.

Интерфейс WinDBG

Рисунок 4: Внешний вид WinDBG

Как только вы впервые увидите внешний вид WinDGB, то поймете, что отладчик пугающе прост. Большинство функций WinDBG узнаются во время отладки процесса. Вместо того чтобы тратить время на описание интерфейса, в последующих разделах мы рассмотрим только самые важные моменты.

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

Рисунок 5: Командное окно WinDBG

В большинстве случаев WinDBG не требует особых настроек и корректно работает прямо «из коробки». Но одну важную вещь, которую необходимо настроить, - это символы. Символы – это файлы, которые генерируются вместе с исполняемым файлом во время компиляции программы и содержат отладочную информацию (функции и имена переменных). Отладочная информация позволяет исследовать функциональность приложения во время отладки или дизассемблирования. Многие компоненты Microsoft компилируются вместе с символами, которые распространяются через Microsoft Symbol Server. С остальными исполняемыми файлами все не так радужно, - очень редко файлы с отладочной информацией идут в комплекте с приложением. В большинстве случаев компании ограничивают доступ к подобной информации.

Рисунок 6: Настройка Microsoft Symbol Server

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

Добавление символов во время отладки

Если вам нужно импортировать символы во время отладки, то можно сделать это при помощи .sympath (окно для ввода команд появится, когда вы подцепитесь к процессу). К примеру, чтобы добавить папку c:\SomeOtherSymbolFolder, введите следующую команду:

Будет не лишним выполнить перезагрузку символов после добавления или изменения путей:

0:025> .reload
Reloading current modules
.
.

Проверка загруженных символов

Чтобы увидеть, для каких модулей загружены символы, вы можете воспользоваться командой x*!. Хотя WinDBG загружает символы только по мере надобности, команда x*! покажет символы, которые могут быть загружены. Можно принудительно загрузить символы при помощи команды ld * (на это может уйти некоторое время, и вы можете остановить этот процесс, зайдя в Debug:Break).

Рисунок 7: Принудительная загрузка символов

Теперь мы можем увидеть символы для каждого модуля.

Рисунок 8: Перечень символов

Отладка локального процесса

При отладке локального процесса у вас есть два пути:

Подцепиться к уже запущенному процессу.
Запустить процесс через WinDBG.

У каждого способа есть свои преимущества и недостатки. Если, допустим, вы запустили программу через WinDBG, то вам доступны некоторые специальные отладочные опции (например, отладка кучи), которые могут привести к краху приложения. С другой стороны, существуют также и программы, которые аварийно заканчиваются свою работу, когда вы цепляете к ним отладчик. Некоторые приложения (в особенности, вредоносы) во время запуска проверяют присутствие отладчика в системе и, соответственно, в этом случае имеет смысл цепляться к уже запущенному процессу. Иногда происходит отладка службы под управлением ОС Windows, которая устанавливает некоторые параметры во время запуска, так что для упрощения процесса отладки, также лучше подцепляться к запущенному процессу, а не запускать службу через отладчик. Некоторые люди утверждают, что запуск процесса через отладчик серьезно сказывается на производительности. Короче говоря, попробуйте и то и другое и выберите то, что подходит вам лучше всего. Если вы по каким-то причинам предпочитаете какой-то конкретный способ, поделитесь своими соображениями в комментариях!

Запуск процесса

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

Запустить процесс не составляет труда. Зайдите в «File:Open Executable» и выберите тот исполняемый файл, который хотите отладить. Вы также можете указать аргументы или установить стартовую директорию:

Рисунок 9: Выбор исполняемого файла для отладки

Подключение к процессу

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

Чтобы подцепиться к уже запущенному процессу зайдите в «File:Attach to a Process», а затем выберите PID или имя процесса. Помните о том, что вам необходимо иметь соответствующие права, чтобы подцепиться к процессу.

Рисунок 10: Выбор процесса, к которому нужно подцепиться

Если после подключения, приложения приостановило свою работу, вы можете использовать режим «Noninvaise», поставив соответствующий флажок.

Отладка удаленного процесса

Возможно, иногда вам будет требоваться отладка процесса на удаленной системе. Было бы намного более удобно решать эту задачу при помощи локального отладчика, вместо использования виртуальной машины или RDP. Или, быть может, вы отлаживаете процесс LoginUI.exe, который доступен только в случае, когда система заблокирована. В подобных ситуациях вы можете использовать локальную версию WinDBG и удаленно подключаться к процессам. Для решения этих задач существует два наиболее распространенных способа.

Существующие отладочные сессии

Если вы уже начали локальную отладку программы (посредством подключения или запуска процесса через WinDBG), то можете ввести определенную команду, и WinDBG запустит «слушатель» (listener), к которому сможет подключиться удаленный отладчик. Для этого используйте команду .server:

После запуска вышеупомянутой команды вы можете увидеть такое предупреждение:

Затем WinDBG сообщит, что сервер запущен:

0:005> .server tcp:port=5005
Server started. Client can connect with any of these command lines
0: <debugger> -remote tcp:Port=5005,Server=USER-PC

Теперь вы может подключиться с удаленного хоста к уже существующей отладочной сессии, зайдя в «File:Connect to a Remote Session» и введя в текстовое поле примерно следующее: tcp:Port=5005,Server=192.168.127.138

Рисунок 12: Удаленное подключение к отладочной сессии

После подключения вы получите подтверждение на удаленном клиенте:

Server started. Client can connect with any of these command lines
0: <debugger> -remote tcp:Port=5005,Server=USER-PC
MACHINENAME\User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013

MACHINENAME\User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013

Создание удаленного сервера

Вы также можете создать отдельный сервер с WinDBG, удаленно подключаться к нему и выбирать процесс для отладки. Это можно сделать, используя файл dbgsrv.exe там, где вы планируете отлаживать процессы. Для запуска подобного сервера запустите следующую команду:

dbgsrv.exe -t tcp:port=5005

Рисунок 13: Запуск удаленного сервера

И опять же вы можете получить предупреждение о безопасности, которое вам следует принять:

К серверу отладки вы можете подключиться, если зайдете в файл «File: Connect to Remote Stub» и введете в текстовое поле следующую строку: tcp:Port=5005,Server=192.168.127.138

Рисунок 15: Подключение к отладочному серверу

После подключения вы не получите каких-то сигналов о том, что вы подключились, однако если вы зайдете в «File:Attach to a Process», то увидите перечень процессов отладочного сервера (там, где запущен dbgsrv.exe). Теперь вы можете подцепляться к процессу, как если бы делали это локально.

Система помощи

Система помощи в WinDBG – великолепна. Помимо изучения чего-то нового, вы должны уметь получать справочную информацию о какой-либо команде. Используйте команду .hh для доступа к справке WinDBG:

Вы также можете получить справочную информацию по определенной команде. Например, чтобы получить помощь по команде .reload, используйте следующую команду:

windbg> .hh .reload

Или просто зайдите в раздел «Help:Contents».

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

После подключения к процессу WinDBG автоматически отобразит загруженные модули. К примеру, ниже показаны модули, после того, как я подключился к calc.exe:

Позже в процессе отладки вы можете вновь вывести этот список при помощи команды lmf:

Также вы можете узнать адрес загрузки для конкретного модуля при помощи команды «lmf m»:

0:005> lmf m kernel32
start end module name
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll

Вы также можете получить информацию о заголовке (image header) конкретного модуля при помощи расширения !dh (восклицательный знак указывает на расширение):

0:005> !dh kernel32

File Type: DLL
FILE HEADER VALUES
14C machine (i386)
4 number of sections
4A5BDAAD time date stamp Mon Jul 13 21:09:01 2009

0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL

Debug Directories(2)
Type Size Address Pointer
cv 25 c549c c4c9c Format: RSDS, guid, 2, kernel32.pdb
( 10) 4 c5498 c4c98

(da8.b44): Break instruction exception - code 80000003 (first chance)

После подключения к calc.exe WinDBG автоматически отображает информацию о следующих регистрах:

eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

Позже можно продублировать эту информацию еще раз при помощи команды r:

0:005> r
eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77663540 cc int 3

Если мы хотим получить значение конкретного регистра, то можем выполнить такую команду:

0:005> r eax
eax=7ffd9000

Информацию одновременно из нескольких регистров можно получить так:

0:005> r eax,ebp
eax=7ffd9000 ebp=02affdc8

Указатель на инструкцию

Последняя команда посвящена запускаемым инструкциям. Здесь информация также выводится на экран, как и в случае с командой r, того, что содержит регистр EIP. EIP – это регистр, содержащий местонахождение следующей инструкции, которую должен выполнить процессор. То, что отображает WinDBG, – эквивалент команды u eip L1, после выполнения которой WinDBG идет по адресу, указанному в регистре EIP, преобразует этот участок в ассемблерный код и отображает его на экране.

ntdll!DbgBreakPoint:
77663540 cc int 3

Оставайтесь на связи

В следующих статьях мы рассмотрим, как использовать WinDBG в боевых условиях: точки останова, пошаговую отладку и просмотр памяти. Не переключайтесь! J.

Читайте также: