Как запустить debug в windows 7

Как запустить debug в windows 7

Debugging Tools for Windows — Инструменты отладки кода операционных систем Windows. Представляют собой набор свободно распространяемых программ от Microsoft, предназначенных для отладки кода пользовательского режима и режима ядра: приложений, драйверов, служб, модулей ядра. В состав инструментария входят отладчики консольного и GUI- режимов, утилиты для работы с символами, файлами, процессами, утилиты для обеспечения удаленной отладки. Инструментарий содержит в себе утилиты, с помощью которых можно находить причины сбоев в различных компонентах системы. Debugging Tools for Windows с определенного момента недоступны для скачивания в форме автономного дистрибутива и входят в состав Windows SDK (Windows Software Development Kit). Набор инструментальных средств Windows SDK, в свою очередь, доступен в виде части программы подписки MSDN или же может быть свободно загружен в качестве отдельного дистрибутива с сайта msdn.microsoft.com. По заявлению разработчиков, последняя и самая актуальная версия Debugging Tools for Windows содержится именно в Windows SDK.

Debugging Tools for Windows обновляются и выкладываются в публичный доступ достаточно часто и процесс этот никак не зависит от выпуска операционных систем. Поэтому, периодически проверяйте наличие новых версий.

Давайте теперь посмотрим, что же, в частности, позволяют нам средства Debugging Tools for Microsoft Windows:

  • Отлаживать локальные приложения, службы (сервисы), драйвера и ядро;
  • Отлаживать по сети удаленные приложения, службы (сервисы), драйвера и ядро;
  • Отлаживать работающие приложения в режиме реального времени;
  • Анализировать файлы дампов памяти приложений, ядра и системы в целом;
  • Работать с системами на базе архитектур x86/x64/Itanium;
  • Отлаживать программы пользовательского режима и режима ядра;

Доступны следующие версии Debugging Tools for Windows: 32-bit x86, Intel Itanium, 64-bit x64. Нам потребуются две из них: x86 либо x64.

Доступны несколько способов установки Debugging Tools for Windows, в данной же статье мы будем рассматривать лишь основные из них:

  • Установка посредством web-инсталлятора.
  • Установка Debugging Tools for Windows с ISO-образа Windows SDK.
  • Установка Debugging Tools for Windows непосредственно из пакетов dbg_amd64.msi / dbg_x86.msi .

Остается неясен еще во какой момент, зачем мне инсталлировать отладочный инструментарий на компьютер? Зачастую ведь сталкиваешься с ситуацией, когда вмешательство в рабочую среду крайне нежелательно! И уж тем более что инсталляция нового продукта, то есть внесение изменений в реестр/файлы системы, может быть совершенно недопустима. Примерами могут служить критически-важные сервера. Почему бы разработчикам не продумать вариант с портабельными (portable) версиями приложений, не требующих установки?
От версии к версии процесс установки пакета Debugging Tools for Windows претерпевает некоторые изменения. Давайте теперь перейдем непосредственно к процессу установки и рассмотрим способы, которыми можно установить инструментарий.

Установка Debugging Tools for Windows при помощи web-инсталлятора

Переходим на страницу Архив Windows SDK и находим раздел под названием Windows 10 и ниже пункт "Windows 10 SDK (10586) и эмулятор устройства с Windows 10 Mobile (Майкрософт) (версия 10586.11)".

Щелкаем по пункту УСТАНОВИТЬ ПАКЕТ SDK . После щелчка скачиваем и запускаем файл sdksetup.exe , который и инициирует процесс онлайн-установки Windows SDK. На начальном этапе инсталятор проверит наличие в системе установленного пакета .NET Framework последней версии (в данный момент это 4.5). Если пакет отсутствует, что будет предложена установка и по окончании выполнена перезагрузка станции. Сразу после перезагрузки, на этапе авторизации пользователя, стартует процесс инсталляции уже непосредственно Windows SDK.

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

После завершения инсталляции Debugging Tools for Windows расположение файлов отладки при данном методе инсталляции у нас будет следующим:

  • 64-битные версии: C:Program Files (x86)Windows Kitsx.xDebuggersx64
  • 32-битные версии: C:Program Files (x86)Windows Kitsx.xDebuggersx86

* где x.x — определенная версия комплекта разработки;
Заметили, что версии 8 и выше, пути инсталляции заметно отличаются от классических для всех предыдущих версий средств отладки?

Огромным плюсом данного способа установки Debigging Tools for Windows является установка версий отладочных средств сразу всех архитектур.

Установка Debugging Tools for Windows с ISO-образа Windows SDK

Данный метод подразумевает установку Debugging Tools for Windows с использованием полного инсталляционного образа Windows SDK (Software Developers Kit). До определенного времени, скачать образ ISO для соответствующей системы можно было на странице Архив Windows SDK. Однако, в данный момент, получить ISO-образ SDK можно через запуск web-инсталлятора sdksetup.exe , и выбора пункта Download the Windows Software Development Kit в стартовом окне инсталлятора:

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

Соответственно, на странице необходимо подобрать требуемый дистрибутив, для меня (да и думаю для многих) в данный момент это "Пакет Windows SDK для Windows 7 и .NET Framework 4" и чуть ниже нажать на ссылку "Получить ISO-образ DVD-диска".

При работе с сайтом msdn.microsoft.com советую воспользоваться браузером Internet Explorer, поскольку были замечены случаи неработоспособности конкурирующих продуктов!

Далее у нас имеется выбор между тремя вариантами образа:

Имя Назначение
GRMSDK_EN_DVD.iso Образ SDK для систем с архитектурой x86 (32-битных).
GRMSDKIAI_EN_DVD.iso Образ SDK для систем с архитектурой ia64.
GRMSDKX_EN_DVD.iso Образ SDK для систем с архитектурой x64 (64-битных).

Соответственно, необходимо выбрать исключительно по необходимости. Обычно разрядность Debugging Tools for Windows совпадает с разрядностью системы. У меня исследуемые системы, в основном, 64-битные, поэтому я в большинстве случаев скачиваю образ для 64-битной системы GRMSDKX_EN_DVD.iso .
Затем, после скачивания образа, нам необходимо с имеющимся ISO-образом как-то работать. Традиционным способом является, конечно же, запись компакт-диска, но ведь это достаточно долгий и иногда затратный метод. Предлагаю воспользоваться бесплатными утилитами по созданию в системе виртуальных дисковых устройств. Лично я для этой цели предпочитаю пользоваться программой DEAMON Tools Lite. У кого-то могут быть и другие предпочтения, более прямые или легковесные утилиты, на вкус и цвет, как говорится.. После инсталляции DAEMON Tools Lite, я просто щелкаю два раза на файл образа GRMSDKX_EN_DVD.iso и в системе у меня появляется новый виртуальный компакт диск:

Читайте также:  Биос american megatrends 2012 загрузка с флешки

Уже затем двойным щелчком активирую автозагрузку и запускаю инсталляцию Windows SDK:

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

Все именно так, на скриншоте отмечено две опции: "Windows Performance Toolkit" и "Debugging Tools for Windows". Выбирайте обе, потому как Windows Performance Toolkit Вам непременно пригодится в работе! Далее, после нажатия кнопки "Next" инсталляция продолжается в обычном режиме. И в конце вы увидите надпись "Installation Complete".
По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:

  • Для версии x86: C:Program Files (x86)Debugging Tools for Windows (x86)
  • Для версии x64: C:Program FilesDebugging Tools for Windows (x64)

На этом установку Debugging Tools for Windows можно считать оконченной.

Установка Debugging Tools for Windows через .msi файл

В случае возникновения проблем при инсталляции Debugging Tools for Windows двумя предыдущими способами, у нас в запасе остается еще один, самый надежный и проверенный временем, выручавший, так сказать, не раз. Когда-то, до интеграции в Windows SDK, Debugging Tools for Windows были доступны в виде отдельного инсталлятора .msi, который и сейчас можно найти, однако уже в недрах дистрибутива Windows SDK. Поскольку у нас на руках имеется уже ISO-образ Windows SDK, то мы можем не монтировать его в систему, а просто открыть при помощи всем уже хорошо знакомого архиватора WinRAR, ну или любого другого продукта, работающего с содержимым ISO-дисков.

После открытия образа нам необходимо пройти в каталог "Setup", находящийся в корне и далее выбрать одну из директорий:

  • Для установки 64-битной версии: SetupWinSDKDebuggingTools_amd64 и распаковать из этого каталога файл dbg_amd64.msi .
  • Для установка 32-битной версии: SetupWinSDKDebuggingTools и распаковать из этого каталога файл dbg_x86.msi .

Далее, запускаем распакованный только что .msi файл и стартуем установку Debugging Tools for Windows.

По окончании инсталляции рабочие директории комплекта Debugging Tools for Windows будут следующими:

  • Для версии x86: C:Program Files (x86)Debugging Tools for Windows (x86)
  • Для версии x64: C:Program FilesDebugging Tools for Windows (x64)

На этом установку Debugging Tools for Windows можно считать выполненной.

Дополнительные сведения

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

  • C:Program Files (x86)Windows Kits10Debuggersx86
  • C:Program Files (x86)Windows Kits10Debuggersx64

* В вашем случае пути могут отличаться как по причине использования ОС другой разрядности, так и по причине использования SDK другой версии.

Утилиты пакета Debugging Tools for Windows могут работать в качестве переносных приложений, достаточно просто скопировать с рабочей системы каталог Microsoft Windows Performance Toolkit и использовать его в качестве портабельной версии на рабочем сервере. Но не забывайте учитывать разрядность системы!! Если Вы даже произвели полную инсталляцию пакета на критически-важную систему, то работать можно начинать прямо после инсталляции, перезагрузка не требуется.

Состав Debugging Tools for Windows

И теперь напоследок приведем состав Debugging Tools for Windows:

Некоторые устройства, которые мы разрабатываем, требуют написания драйвера устройства для ОС Windows или Linux. Написание драйвера устройства – это не совсем формат нашего сайта, но возможно эта статья будет кому-то полезна. Речь пойдет даже не о написании драйвера, а об отладке драйвера в ОС Windows. Я вот уже две недели как погрузился в отладку драйвера одного устройства.. Не очень простое дело..

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

Прежде всего нужно подготовить «среду» для отладки.
Понадобится 2 компьютера с ОС Windows: первый компьютер – это тот который будет подвержен отладке, второй компьютер – это тот, с помощью которого будет вестись отладка. В терминологии Microsoft первый компьютер называется Target, а второй – это Host.

Эти два компьютера нужно соединить между собой для передачи отладочной информации. Есть несколько способов:

  • использовать специальный майкрософтовский отладочный USB кабель. Не думаю, что вы его легко найдете.
  • использовать кабель FireWire. Это уже проще. Некоторые компьютеры имеют такой разъем, ну или можно найти PCI плату с разъемом FireWire. У меня сейчас в ПК есть такой разъем на материнской плате, а вот в ноутбуке – нет. Так что этот способ так же отпадает.
  • самый простой способ – последовательный порт. Не очень хорошо в смысле скорости передачи, зато просто организовать.

Вот мое рабочее место для отладки:

Слева – Target, инспектируемый компьютер.
Справа – Host, ноутбук отладчика.

В ноутбук подключен кабель USB и программатор MBFTDI. В этом случае мы его будем использовать просто как переходник USB2COM. То есть для ноутбука это как последовательный порт. Правда есть ньюанс – выходные уровни программатора MBFTDI не соответствуют стандартным в последовательном порту. Поэтому я еще подключил преобразователь уровней, на микросхеме MAX232 (нашел его среди старых железок, у нас для них целый ящик в офисе).

Теперь нужно настроить Target. У меня здесь Windows 7 64х битная.
Запускаем окно командной строки CMD от имени администратора и в нем выполняем команды:

>bcdedit /debug on
>bcdedit /dbgsettings serial debugport:n baudrate:rate

У меня debugport:COM1 и baudrate:115200
Это в общем и есть вся настройка инспектируемого компьютера.
Теперь на нем нужно просто выполнить перезагрузку.

Далее настроим хост – у меня это ноутбук.
Здесь нужно установить программу отладчика WinDbg.
Программа отладчика есть в составе Windows Driver Kit (WDK) или в составе Microsoft Software Developer Kit. Все это можно взять с сайта Microsoft https://msdn.microsoft.com/en-us/windows/hardware/hh852365 вполне легально и бесплатно.

Читайте также:  Как поменять местоположение в мамбе

У меня на ноутбуке так же Windows 7 x64. Я установил WDK и там в составе есть нужный мне отладчик.

Запускаю WindDbg. Выбираем пункт меню File -> Kernel Debug и появляется окошко:

Выбираю скорость передачи 115200 и имя последовательного порта. В принципе все готово.

На ноутбуке Host в программе WinDbg есть командная консоль, достапная через меню View -> Command . Появляется командная строка отладчика.

Любая высокая технология для наблюдателя со стороны мало отличима от магии..

На хосте в программе WinDbg нажимаю Ctrl+Break и компьютер Target останавливается! То есть полностью стоят все процессы и потоки Windows. Можно попить чайку.

В консоли отладчика можно выполнять различные команды. Команд много, у них много параметров, конечно я не смогу их все описать. В конце концов для этого есть вполне вменяемая инструкция-help самой программы WinDbg.

Самые простые команды:

>u – показать дизассемблированный код в месте, где произошла остановка процессора. Ну или “u ” – посмотреть код по адресу.

>d – показать дамп памяти по адресу или по регистру.

>r — показать содержимое регистра процессора.

>t – выполнить одну инструкцию процессора.

>p – выполнить инструкцию процессора или целую процедуру, если инструкция call.

Более того, в отладчике конечно можно установить точки останова различного типа.

Самый простой пример:

>bp — остановка ядра, когда процессор достигнет указанного адреса.

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

Отмена всех точек останова – команда « bc * »

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

Например, мы написали драйвер для ОС Windows. Скомпилировали его debug версию. Вместе с файлом драйвера mydrv.sys компилятор генерирует еще файл с соответствующей символьной информацией mydrv.pdb .

Зайдем в меню отладчика File -> Symbol File Path.. и в диалоговом окне добавим путь к нашему файлу PDB.

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

>bp mydrv!DriverEntry – остановить ядро, когда произойдет вызов функции DriverEntry нашего драйвера mydrv .

Кроме этого, очень полезно подключить к отладчику еще и символьную информацию самого ядра Windows. Конечно, версий виндовсов много, есть разные сборки и где найти символьную информацию именно соответствующую вашей Target ОС Windows?

Проще всего, в командной строке отладчика выполнить команду

При этом, нужные файлы отладки (именно нужной версии) будут выкачаны через интернет к вам на диск в папку c:localsymbols прямо с сервера Microsoft.

Теперь, можно уже более осмысленно дебажить и само ядро.

Хотите посмотреть, как выглядит, например, функция USBPORTSVC_CompleteIsoTransfer драйвера usbport.sys ? Нет проблем:

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

Например, очень многие системные структуры данных в ядре Windows снабжаются «сигнатурой» — специальной строкой, обычно из 4 символов. Таким образом, функции ядра имеют возможность легко проверить переданные им указатели на структуры являются верными или нет. Вот в коде на картике выше есть вызов функции USBPORT_AssertSig . Уже по названию функции становится примерно понятно, что она делает – проверяет указатель, действительно ли он указывает на структуру с нужной сигнатурой.

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

Отладка собственного драйвера может быть еще проще, так как имеются исходные тексты самого драйвера. Укажите к ним путь в диалоговом окне отладчика Source Search Path и можно будет выполнять по шагам не отдельные команды процессора, а целые строки программы C/C++. Так же становятся доступны для просмотра локальные переменные функций и прочая отладочная информация.

Вообще отладчик WinDbg дает широкие возможности для отладки своих драйверов, а так же возможность для изучения вообще ядра ОС Windows.

Как уже говорилось (см. ВВЕДЕНИЕ), программа Debug входит в состав Windows. Запустить программу Debug можно из командной строки или непосредственно из папки, в которой она находится. Чтобы запустить программу из командной строки, выберите команду из меню ПУСК – ВЫПОЛНИТЬ или нажмите комбинацию клавиш WIN + R (если вы не знаете, что такое комбинация клавиш, см. книгу Компьютер для чайников). В открывшемся окне (рис. 1.5) напечатайте слово debug и нажмите клавишу ENTER или щёлкните кнопку ОК.

После этого откроется окно с пустым экраном и чёрточкой в левом верхнем углу, которая приглашает вас ввести какую-либо команду. Например, чтобы выйти из программы Debug, напечатайте букву q и нажмите ENTER.

Написать программу, используя Debug, можно не единственным способом, но мы пока рассмотрим тот, который больше похож на написание программы для Emu8086.

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

Введем букву «а» (напоминаю в последний раз — все команды вводятся на английском языке) и нажмем ENTER.

Затем введем программу, нажимая ENTER в конце каждой строки: Результат будет примерно таким, как показано на рис. 1.6.

ПРИМЕЧАНИЕ 1
Обратите внимание, что все числовые значения пишутся без буковки h в конце. Это потому, что Debug работает только с шестнадцатеричными числами, и ему не надо объяснять, в какой системе исчисления вводятся данные.

ПРИМЕЧАНИЕ 2
После ввода команды -а, появляются символы: 0B72: 0100. В вашем случае первые четыре символа могут быть другими, но нас они пока не интересуют. А как вы думаете, что означает число 0100? Помните директиву ORG 100h (см. раздел Emu8086)? Вот-вот – это адрес, с которого начинается выполнение программы. То есть в память с этим адресом заносится первая команда программы (для файлов СОМ). Каждая команда занимает 2 байта, поэтому следующий адрес будет 0102 и т.д.

Читайте также:  Spin tires как вернуться в гараж

Сами команды мы уже знаем (см. раздел Emu8086), поэтому описывать их здесь не будем.

Программа написана – нужно проверить ее работу. Нажмём ENTER ещё раз, чтобы на экране появилась чёрточка, которая говорит о том, что можно вводить команду для Debug. Затем введем команду g (от английского «GO») и нажмем клавишу ENTER. На экране увидим следующее: Здесь A – та самая буква, которая выводится на экран в результате работы программы. Затем идёт сообщение о нормальном завершении программы (оно может отличаться в зависимости от версии Debug).

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

Введем команду t и нажмем клавишу ENTER. Увидим нечто вроде этого: Это есть ни что иное, как состояние регистров процессора после выполнения первой строки программы. Как вы можете видеть, в регистр АН записалось число 02. В нижней строке находится адрес команды и сама команда, которая будет выполняться следующей.

Снова введем команду t и нажмем клавишу ENTER. Увидим следующее: Команда MOV DL, 41, как ей и полагается, записала в регистр DL число 41.

Снова введем команду t и нажмем клавишу ENTER. Увидим следующее: Команды CMP AH,4B нет в нашей программе. Наша программа завершила свою работу. Мы можем долго еще вводить команду t – нам будут выдаваться состояния регистров. Почему это происходит, нам пока не интересно. Лучше введем команду g и нажмем клавишу ENTER, таким образом окончательно выполним нашу программу, и увидим то, что мы уже видели.

Программа написана и проверена. Но как сделать ее самостоятельной, то есть как создать файл СОМ? Ведь то, что мы сделали, работает только с помощью Debug. Чтобы создать исполняемый файл, нужно ответить на несколько вопросов:

  1. Какого размера будет наш файл? Выполнение программы начинается с адреса 0100h, а последняя строка в программе содержит адрес 0108h. Это значит, что размер файла будет 8 байт (108h – 100h = 8).
  2. Как мы назовем наш файл? А хоть как. Однако, рекомендуется давать файлам английские имена, в которых содержится не более 8 символов (DOSу так приятнее работать). Назовем, например, debug_1.com

А теперь выполним следующие действия:

  1. Снова напишем нашу программу (тренируйтесь, тренируйтесь. ).
  2. Запишем в регистр СХ размер файла. Для этого введем команду r cx и нажмем ENTER. Затем введем размер файла (8 байт) и нажмем ENTER.
  3. Введем команду n, затем один пробел и имя файла. Нажмем ENTER.
  4. И, наконец, введем команду w и нажмем ENTER.

В результате всех этих действий на экране появится следующая информация (см. также рис. 1.7): Если вы работаете в режиме эмуляции DOS из под WINDOWS, то файл debug_1.com сохранится на рабочий стол, либо в папку текущего пользователя. Это зависит от версии и/или настроек WINDOWS. Теперь его можно запустить как обычную программу. Если в указанных папках вы не нашли этот файл, то найдите его через поиск файлов. Ну а если вы не знаете, как это сделать, см. книгу Компьютер для чайников.

Чувствую, что мы уже устали. Выход из Debug осуществляется командой q.

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

Итак, программа Debug у нас закрыта. Набираем в командной строке: (где debug_1.com – это имя файла, который мы хотим дизассемблировать) и нажимаем ENTER.

ПРИМЕЧАНИЕ
Если программа не запустилась, значит нужно указать полный путь к ней, например Если же программа запустилась, но выдала ошибку (например: Ошибка 1282 или «Файл не найден»), то нужно указать полный путь к файлу, например: Если и это не помогло, то, возможно, вы всё-таки где-то допустили ошибку в пути или путь не соответствует требованиям DOS. В таком случае лучше поместить программу в корень диска С, откуда она гарантированно загрузится по пути «C:debug_1.com».

Если Debug запустилась без сообщений об ошибках, то вводим команду u и нажимаем ENTER. Вот что мы увидим (примерно, см. также рис 1.8): Посмотрите на первые четыре строки. Узнаете? Это наша программа. Остальные строки нас не интересуют (это инструкции, оставшиеся от программ или данных, отработавших до запуска Debug). Ну а если мы рассматриваем незнакомый файл, как узнать, где кончается программа и начинается «мусор»? Ориентировочно это можно сделать по размеру файла (для очень маленьких программ). Размер можно посмотреть в свойствах файла. Только следует учитывать, что в свойствах файла размер дан в десятичной форме, а Debug нам выдает шестнадцатеричные адреса. Поэтому придется перевести десятичное число в шестнадцатеричное.

Есть еще вариант (который тоже не всегда приемлем) – найти в полученном списке строку, содержащую команду выхода из программы (INT 20).

Если программа большая, то список ее команд не поместится на экран. Тогда снова вводим команду u и нажимаем ENTER. И так до конца программы.

Возможно, вы не увидите на экране свою программу. Это может быть либо из-за того, что программа почему-то не загрузилась, либо по причине несоответствия адресов. Будьте внимательны: обращайте внимание на адреса памяти, которые указаны в левой колонке. Наша программа начинается с адреса 0100. Если адрес другой, то это, соответственно, не наша программа.

Ссылка на основную публикацию
Как выйти из знакомства майл ру
Привет! Сегодня я покажу вам как удалить свою анкету с сайта знакомств Майл. Вы можете раз и навсегда удалить свою...
Как включить gprs на айфоне
Здесь описано, как включить или выключить службы геолокации и GPS для отдельных программ. Предоставление разрешения на использование данных о вашей...
Как включить ssd в биосе asus
Хотя SSD в разы быстрее обычных жестких дисков, это не значит, что твердотельные устройства не подлежат оптимизации – напротив. Конечно,...
Как выключить микрофон в fl studio 12
При записи вокала очень важно подобрать не только правильное оборудование, но и выбрать для этого хорошую программу, где можно осуществить...
Adblock detector