Debug
Debug — Программа-отладчик, которую используют для проверки и отладки выполняемых файлов. Использовалась при операционной системе MS-DOS. Под более поздние версии операционных систем работает через эмулятор MS-DOS и имеет ограниченные возможности.
Содержание
Назначение
Данная программа является консольным приложением и предназначена для создания или изменения кода файлов. С помощью неё можно создавать простые приложение под MS-DOS и отслеживать их работу. Данный отладчик находится на самом низком уровне компиляторов assembler. Но обладает неплохими возможностями такими как просмотр, изменение памяти и получение состояния регистров.
Команды
Запуск отладчика
Программа вызывается через командную строку:
Работа с файлами
| Команда | Описание | Пример |
|---|---|---|
| -N | -N Путь_Имя_Файла. С помощью этой команды можно загружать и сохранять файлы. Сокращённо от слова Name. | -N My.com [Нажать Enter] |
| -L | Загрузка файла. Сокращённо от слова Load. | -N My.com [Нажать Enter] -L [Нажать Enter] |
| -W | -W Путь_Имя_Файла. Сохранить файл. Сокращённо от слова Write. | -N My.com [Нажать Enter] -W [Нажать Enter] |
Отображение и изменение значений регистров
| Команда | Описание | Пример |
|---|---|---|
| -R | Выдаёт содержание всех регистров. | -R [Нажать Enter] |
| -R [регистр] | Просмотр регистра и запись нового значения в регистр. | -R AX [Нажать Enter] 666 [Нажать Enter] |
Дамп памяти
Дизассемблирование
| Команда | Описание | Пример |
|---|---|---|
| -U | Команда преобразования кода в инструкции ассемблера. Сокращённо от слова Unassemble. | -U [Нажать Enter] |
Ассемблирование
| Команда | Описание | Пример |
|---|---|---|
| -A | Преобразования инструкции ассемблера в машинный код. Сокращённо от слова Assemble. | -A [Нажать Enter] 1814:0100 MOV AX,0009 1814:0103 [Вводим_Дальше] [Нажать Enter] |
Компиляция
Трассировка
| Команда | Описание | Пример |
|---|---|---|
| -T | Команда имеет сходство с командой (-G) Go, но отличается тем что выводит значения регистров поле каждой инструкции. Сокращённо от слова Trace. | -T [Нажать Enter] |
| -T =[Адрес_Начала_Работы] [Количество_Иструкций] | Дополнительно указывает с какого адреса запускаться программе и количество исполняемых инструкций. | -T =100 5[Нажать Enter] |
См. также
Примечания
Ссылки
Список команд DOS • Список команд операционных систем Miscrosoft
Полезное
Смотреть что такое «Debug» в других словарях:
Debug — ([ˌdiːˈbʌg]) steht für: den Vorgang des Debuggens, siehe Debugger De:Bug, eine Zeitschrift, siehe DeBug DEBUG.EXE, der Microsoft DOS Debug Editor … Deutsch Wikipedia
debug — de‧bug [ˌdiːˈbʌg] verb debugged PTandPPX debugging PRESPARTX [transitive] COMPUTING to remove bug S (= faults ) from a computer program … Financial and business terms
debug — 1945, of machine systems, from DE (Cf. de ) + BUG (Cf. bug) glitch, defect in a machine. Meaning to remove a concealed microphone is from 1964 … Etymology dictionary
debug — [v] troubleshoot adjust, correct, fix, iron out, remedy, remove errors, repair, sort out, straighten out, unravel, unscramble, untangle, work the bugs out of; concepts 126,212 … New thesaurus
debug — ► VERB (debugged, debugging) ▪ remove errors from (computer hardware or software). DERIVATIVES debugger noun … English terms dictionary
debug — [dē bug′] vt. debugged, debugging [ DE + BUG1] 1. to remove insects from 2. to find and correct the defects, errors, malfunctioning parts, etc. in 3. Informal to find and remove hidden electronic listening devices from (a place) … English World dictionary
Debug — Débogueur Voir « débogueur » sur le Wiktionnaire … Wikipédia en Français
debug — UK [diːˈbʌɡ] / US [dɪˈbʌɡ] verb [transitive] Word forms debug : present tense I/you/we/they debug he/she/it debugs present participle debugging past tense debugged past participle debugged computing to look for and remove mistakes from a computer … English dictionary
debug — transitive verb Date: 1944 1. to remove insects from 2. to eliminate errors in or malfunctions of 3. to remove a concealed microphone or wiretapping device from • debugger noun … New Collegiate Dictionary
debug — [[t]di͟ːbʌ̱g[/t]] debugs, debugging, debugged VERB When someone debugs a computer program, they look for the faults in it and correct them so that it will run properly. [V n] The production lines ground to a halt for hours while technicians tried … English dictionary
Программа Debug
Как уже говорилось (см. ВВЕДЕНИЕ), программа Debug входит в состав Windows. Запустить программу Debug можно из командной строки или непосредственно из папки, в которой она находится. Чтобы запустить программу из командной строки, выберите команду из меню ПУСК – ВЫПОЛНИТЬ или нажмите комбинацию клавиш WIN + R (если вы не знаете, что такое комбинация клавиш, см. книгу Компьютер для чайников). В открывшемся окне (рис. 1.5) напечатайте слово debug и нажмите клавишу ENTER или щёлкните кнопку ОК.
После этого откроется окно с пустым экраном и чёрточкой в левом верхнем углу, которая приглашает вас ввести какую-либо команду. Например, чтобы выйти из программы Debug, напечатайте букву q и нажмите ENTER.
Написать программу, используя Debug, можно не единственным способом, но мы пока рассмотрим тот, который больше похож на написание программы для Emu8086.
Чтобы написать уже известную нам программу, используя Debug, сделаем следующее (подразумевается, что Debug вы уже запустили, и увидели черный экран с маленькой мигающей черточкой в левом верхнем углу).
Затем введем программу, нажимая ENTER в конце каждой строки: Результат будет примерно таким, как показано на рис. 1.6.
ПРИМЕЧАНИЕ 1
Обратите внимание, что все числовые значения пишутся без буковки h в конце. Это потому, что Debug работает только с шестнадцатеричными числами, и ему не надо объяснять, в какой системе исчисления вводятся данные.
Сами команды мы уже знаем (см. раздел 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 осуществляется командой 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. Если адрес другой, то это, соответственно, не наша программа.
Богдан Стефанюк
Из коробки в C# нам доступны 2 способа сборки проекта release и debug.
О компиляции C# кода
Исходный код C # проходит через 2 этапа компиляции, чтобы стать инструкциями CPU, которые могут быть выполнены.
Обычно первый этап происходит на вашем CI сервере, а второй шаг происходит позже, во время работы самого приложения. Когда же мы работаем локально в Visual Studio, то она все эти шаги выполняет перед запуском приложения из меню Debug.
Шаг первый. Компиляция приложения
Ваш код превращается в Common Intermediate Language (CIL), который уже может быть выполнен в любом окружении, которое поддерживает CIL. Обратите внимание, что собранная сборка не является читаемым текстом IL, а фактически метаданными и байтовым кодом в виде двоичных данных.
На данном шаге будет выполнена некоторая оптимизация кода (будет описано дальше).
Шаг второй. JIT компилятор
JIT компилятор конвертирует IL код в инструкции процессора, которые можно выполнить на вашей машине. Однако не вся компиляция происходит заранее — в нормальном режиме, код компилируется, только тогда когда его вызывают в первый раз, после чего он кэшируется.
Основная часть оптимизации кода будет проведена на этом шаге.
Что такое оптимизация кода в одном предложении?
Почему мы заинтересованы в оптимизации в этой статье?
На обоих этапах компиляции ваш код будет оптимизирован компиляторами. Одно из ключевых различий между конфигурациями сборки Debug и Release заключается в том, отключены ли оптимизации или нет, поэтому нам нужно понять последствия данных оптимизации.
Оптимизация компилятора C#
C# компилятор на самом деле делает очень мало оптимизаций. На самом деле большенство оптимизаций производит JIT компилятор во время генерирования машинного кода. Тем не менее это все равно ухудшит работу по отладке.
Инструкция nop в IL
Команда nop имеет ряд применений при программировании на низком уровне, например, для включения небольших предсказуемых задержек или инструкции по перезаписи, которые вы хотите удалить. В IL коде данные конструкции помогают при использовании точек останова (breakpoints) для того чтобы они вели себя предсказуемо.
Если мы посмотрим на IL код, который сгенерирован с отключенными оптимизациями:
Эта инструкция мапиться с фигурной скобкой, для того чтобы мы могли поставить на нее точку остановки:
Даная инструкция была бы удалена если у нас включены оптимизации, что повлияло бы на отладку приложения.
Более подробное обсуждение оптимизаций компилятора C# в статье Эрика Липперта: Что делает переключатель оптимизации?. Существует также хороший комментарий о IL до и после оптимизации здесь.
Оптимизация JIT компилятора
Несмотря на то, что он быстро выполняет свою работу во время выполнения, компилятор JIT также выполняет множество оптимизаций. О его внутренних деталях мало информации. Даже во время работы вашего приложения он производит профилирование и, возможно, перекомпилирование кода для повышения производительности.
Хорошие примеры оптимизации с помощью JIT компилятора можете посмотреть здесь.
Я рассмотрю один пример, чтобы проиллюстрировать влияние оптимизации на отладку.
Встраивание методов
Для реальной оптимизации, сделанной компилятором JIT, я буду показывать инструкции по сборке. Это всего лишь макет на C #, чтобы дать вам общую идею.
Предположим, что у меня есть:
Компилятор JIT, скорее всего, выполнит встроенное расширение. Он заменит вызов метода Add() телом данного метода:
Конфигурации сборки по умолчанию
Довольно просто — релиз полностью оптимизирован, отладка совсем отсутствует, что, как вы сейчас знаете, имеет фундаментальное значение для того, насколько легко отлаживать ваш код. Но это просто поверхностное представление о возможностях аргументов отладки и оптимизации.
Внутренности аргументов оптимизации и отладки
Я попытался продемонстрировать данные аргументы из кода Roslyn и mscorlib. Теперь мы имеем следующие классы:
Синие элементы обозначаю аргументы командной строки, а зеленые их представление в коде.
Перечисление OptimizationLevel
OptimizationLevel.Debug отключает все оптимизации для C# и JIT компилятора с помощью DebuggableAttribute.DebuggingModes, который с помощью ildasm, мы можем видеть:
OptimizationLevel.Release включает все оптимизации (DebuggableAttribute.DebuggingModes = ( 01 00 02 00 00 00 00 00 )) что в свою очередь соответсвует DebuggingModes.IgnoreSymbolStoreSequencePoints
При этом уровне оптимизации точки останова могут быть оптимизированы. Что приведет к тому что мы не сможем их поставить и остановиться.
Типы IL
Типы IL кода описаны в классе ILEmitStyle.
На диаграмме выше показано, что тип генерируемого IL кода C# компилятором зависит от OptimizationLevel.
Аргумент debug не меняет его, за исключение аргумента debug+ когда OptimizationLevel установлен в Release.
Следующий кусок кода продемонстрирует все это наглядно.
Комментарий в исходном файле Optimizer.cs гласит, что они не опускают никаких определенных пользователем локальных переменных (примеры на 28 строчке) и не переносят значения в стек между операторами.
Я рад, что прочитал это, так как я был немного разочарован своими собственными экспериментами в ildasm с debug +, поскольку все, что я видел, это сохранение локальных переменных.
Нет намеренной «деоптимизации», например, добавления команд nop.
Разница между debug, debug:full и debug:pdbonly.
На самом деле разницы никакой нету, что подтверждает официальная документация:
Результат остается одним и тем же — pdb файл создается.
Подгланув в CSharpCommandLineParser можем убедиться в этом. И для того чтобы проверить это, мне удалось отладить код с помощью WinDbg для обох аргументов (pdbonly и full).
Они не влияют на оптимизацию кода.
Как плюсом могу отметить что документация на Github более актуальна, но она не открывает свет на специфическое поведение для debug+
А что же такое этот ваш pdb файл?
Все очень просто, данный файл содержит всю необходимую информацию для отладки DLL и EXE. Что помогает сопоставить отладчику IL код с инструкциями в оригинальном C# коде.
Что на счет debug+?
debug+ это особенный аргумент, который не может быть заменен с помощью full и pdbonly. Как многие заметили, данный аргумент соответствует debug:full — это на самом деле не совсем правда. Если мы используем аргумент optimize-, поведение будет таким же, но для optimize+ будет свое собственное уникальное поведение (DebugFriendlyRelease).
debug- или без аргументов?
Значения по умолчанию, которые установлены в CSharpCommandLineParser.cs.
а значения для debug=:
Таким образом, мы можем с уверенностью сказать, что debug- и отсутствие аргументов отладки, приводет к одному и тому же эффекту — pdb файл не будет создан.
Запрет оптимизации JIT при загрузке модуля (Suppress JIT optimizations)
Флажок в разделе «Options->Debugging->General» это опция для отладчика в Visual Studio и не повлияет на сборки, которые вы создаете.
Вы должны теперь оценить, что компилятор JIT делает большую часть значительных оптимизаций и является большим препятствием для сопоставления исходного исходного кода для отладки. Если этот параметр включен, тогда он запросит DisableOptimizations.
Обычно этот параметр включаю для того чтобы отладить внешние библиотеки или пакеты NuGet.
Что такое Just My Code?
По умолчанию эта настройка уже включена (Options->Debugging→Enable Just My Code) и отладчик думает что оптимизированный код не является пользовательским. Поэтому отладчик никогда не зайдет в такой код.
Вы можете отключить данный флаг и это, теоретически, позволит вам поставить точку остановки. Но теперь вы отлаживаете код, оптимизированный как компиляторами C# так и JIT, который едва соответствуют исходному коду. В результате у вас будут такие артефакты отладки, как непредсказуемые переходы в коде и скорее все вам не получиться получить значения в локальных переменных.
Этот параметр стоит отключать в том случае, когда у вас есть pdb файл.
Взглянем ближе на DebuggableAttribute
Выше я упомянул использование ildasm для изучения манифеста сборок для изучения DebuggableAttribute. Я также написал небольшой PowerShell скрипт для получения более дружественного результата (ссылка на скачивание).
filecheck .ru
Вот так, вы сможете исправить ошибки, связанные с debug.exe
Информация о файле debug.exe
Процесс PE Explorer или System Service принадлежит программе PE Explorer от Microsoft (www.microsoft.com) или Heaventools Software (www.heaventools.com).
Важно: Некоторые вредоносные программы используют такое же имя файла debug.exe, например Trojan-Downloader.Win32.Suurch.cag или Trojan-Downloader.Win32.Suurch.adm (определяется антивирусом Kaspersky), и Downloader.Ertfor или Packed.Generic.234 (определяется антивирусом Symantec). Таким образом, вы должны проверить файл debug.exe на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.
Комментарий пользователя
debug сканер
Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.
Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.
SpeedUpMyPC бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.
debug.log: раздражающий файл, который Photoshop создает на рабочем столе
Photoshop это одна из программ, которая обычно не отсутствует ни на одном компьютере. Это программное обеспечение позволяет нам создавать, редактировать и ретушировать все виды фотографий. саманТипичная программа редактирования используется как пользователями-любителями, вступающими в мир редактирования, так и профессиональными дизайнерами и фотографами. И хотя Adobe обычно предлагает хорошее обслуживание этого программного обеспечения (за которое вы должны платить ежемесячную подписку), иногда в программе есть самые досадные ошибки, такие как ошибка, которая влияет на программу более месяца.
С момента выхода Photoshop версии 21.2.2.289 В августе прошлого года все пользователи начали сталкиваться с файлом debug.log на своем рабочем столе. Этот файл появляется каждый раз, когда пользователь открывает в программе файл JPEG, PNG, PSD или другой файл. Этот файл может не только отображаться на рабочем столе, но и в каталоге, из которого мы открыли изображение.
Какой файл debug.log создает Photoshop
Если вы используете Photoshop, вы наверняка сталкивались с этим файлом. Кроме того, собственные форумы поддержки компании уже заполняются пользователями, сообщающими об этой проблеме. Провал не оказывает негативного воздействия о работе программы или компьютера; все работает правильно. Однако никому не нравится иметь файлы журнала на рабочем столе, особенно тем, кто любит чистый и аккуратный рабочий стол.
Как избежать файла debug.log
Adobe на данный момент не заявляла об этой проблеме. И пока это не решено, поскольку эта проблема продолжает появляться даже в последней версии Photoshop, 21.2.3, выпущенной на этой неделе.
Файл заблокирован Photoshop, пока мы используем программу, но мы можем удалить его, закрыв. Однако, когда мы снова откроем его, файл снова появится. И так далее.