An MS-DEBUG Tutorial
Sponsoring website:
I hope you enjoy the Assembly coding examples used on this page. If
you have any questions about them, .
( Opens in a new window. )
A Guide to DEBUG
(Page Two)
A DEBUG Tutorial
Copyright& by Daniel B. Sedory
may be freely copied for PERSONAL use ONLY !
( It may NOT be used for ANY other purpose unless you have
and received permission
from the author! )
Help on DEBUG Commands
For a reminder of all the commands (and
most of the parameters) that are available while inside of DEBUG, simply enter
a question mark (?) at the DEBUG
when using DOS 5.0 or later. ( Note: Expanded Memory commands
are rarely if ever used and will not be discussed here.)
Quick Alphabetical Links
Click on a command here for all its details:
(Learn 2's Complement!)
. . . . . . . . . (Learn this first!)
H o w & t o
u s e & t h e
C O M M A N D S
P a r a m e t e r s
NOTE: & Parameters listed in brackets ( [ & ] ) are optional.
& Optional parameters usually
indicate there are a number of different ways
a command could be used.
I've listed the meanings of all the parameters here for you:
address - Memory location specified in hexadecimal. You can use either a
simple Offset all by itself (in which case, the present CS 'Code Segment'
will be assumed), or you can enter the full Segment:Offset location using
either all hex numbers or substituting the name of a segment register for a
number. Leading ze
thus 1F all by itself would be the
location 'CS:001F' ( CS meaning whatever the CS happened to be at the time
you entered this ). Examples:
For a detailed discussion, see: .
& & range - Two hexadecimal addresses separated by a single space.
They may be listed as either full Segment:Offset pairs or just an Offset
alone ( in which case, the Segment is assumed to be that of the present CS
or &Code Segment& ). NOTE: Some commands, such as , may require
the second address be given only as an
& & & & list -
A string of Hexadecimal bytes separated
by a space, or ASCII data enclosed within single or double quote marks. You
can list any number of bytes from a single one up whatever number fits on
the line before having to press the Enter key. A single byte, such as 00 is
most often used with the
command whereas an
command will most likely have a string of many
hex bytes or ASCII for example:
e 100 31 C0 B4 09 BA 50 02 CD 21 B8 4C 00 CD 21
e 250 'This is an ASCII data string.$'
&number - Remember
all numbers and values used in any DEBUG command are understood as being Hexadecimal only! That
includes the number of sectors in the LOAD or WRITE commands and even the number of instructions
you want DEBUG to step through in the TRACE or PROCEED commands. It's all HEX all the time when
using DEBUG!
DEBUG Tutorial
Details of each Command
NOTE: In the Examples below, commands which
are entered by a user are shown in bold data displayed in response
by DEBUG is in normal type. DEBUG (from MS-DOS 5.0 or later (which is
true for the DEBUG version used by Windows™ XP) will display the following
usage message, if you enter&debug
at a DOS prompt:
C:\WINDOWS>debug /?
Runs Debug, a program testing and editing tool.
DEBUG [[drive:][path]filename [testfile-parameters]]
[drive:][path]filename
Specifies the file you want to test.
testfile-parameters
Specifies command-line information required by
the file you want to test.
& & Immediately quits (exits) the Debug
program! No questions ever asked... should be the first command you remember
along with the &?& command.
& & A very simple (add and subtract
only) Hex calculator. Never forget that all numbers inside of DEBUG are always
Hexadecimal. Enter two Hex values (no more than four digits each) and DEBUG shows
first the SUM, then the DIFFERENCE of those values. Examples:
-h aaa 531
-h dbf ace
Differences are always the second value
subtracted from AAA
- 531 = 579.
There are no carries past four digits.
Two's Complement arithmetic is always used
in this calculator, so think of it as being limited to a maximum of plus
7FFFh (+ 32,767) or a minimum of minus 8000h (- 32,768). Positive
values are represented by exactly the same digits as their numbers for 0000h
through 7FFFh. A minus 7FFFh, however, is represented by the Hex digits
8001, and a minus
1h (-1) is represented by the Hex digits FFFF.
Thus, the output of DEBUG after entering &h 4 fffc& would be a zero
and an 8, because FFFC
represents a minus 4h (-4) and 4
- (-4) = 8.
&Examples:
-h 100 123
-h 7fff 8000
Note the difference between 100h and 123h;
FFDD represent? To find the numerical value of a Two's Complement number,
first invert every bit (or find its logical inverse); that would be 0022,
then add 1. So, this represents a negative 23h. Both
the sum and the difference of 7FFFh and 8000h are a negative
1 (or FFFF); which can be
arrived at using: 7FFFh + (- 8000h) = -1.
However, it's much easier to
think of the sums as having nothing to do with
C thus, 7FFFh + 8000h = FFFFh (32,767 + 32,768 = 65,535). This
will even hold true for the differences if the second value is less
than the first. But any
difference which produces a negative number,
must be represented in Two's Complement.
& & Displays the contents of a block
of memory. The Memory locations near the beginning of Segment C000
(even under Windows 2000/XP) should display information about the kind of video
card installed on your PC. The first example below shows what a Matrox video
card on our system displayed.
-d c000:0010
C000: FF FF 00 00 00 00-60 00 00 00 00 20 49 42
$.......`.... IB
C000: 43 4F 4D 50 41 54-49 42 4C 45 20 4D 41 54
M COMPATIBLE MAT
C000:F 58 2F 4D 47 41 2D-47 31 30 30 20 56 47 41
ROX/MGA-G100 VGA
C000: 42 45 20 42 49 4F-53 20 28 56 31 2E 32 20
/VBE BIOS (V1.2
C000: 87 DB 87 DB 87 DB-87 DB 87 DB 87 DB 87 DB
)...............
C000: 49 52 2B 10 01 10-00 00 18 00 00 00 00 03
PCIR+...........
C000: 12 10 00 80 00 00-38 37 34 2D 32 00 FF FF
@.......874-2...
C000: 56 8B D8 E8 C6 56-74 22 8C C8 3D 00 C0 74
.&V....Vt&..=..t
-d 100 130
xxxx:0100 EB 24 0D 0A 54 68 69 73-20 69 73 20 6D 79 20 66
.$..This is my f
xxxx: 73 74 20 44 45 42-55 47 20 70 72 6F 67 72
irst DEBUG progr
xxxx:D 21 0D 0A 24 B4 09-BA 02 01 CD 21 B4 00 CD
am!..$......!...
xxxx:0130 21
The last example above, is what you'd see after entering
the code under the
command. We could just as
easily have used the length option with
the command 'd 100 l31' (that's an 'L'
in front of the &31&) to produce the same results above. The following
example shows only the '$'-terminated display string, which has a length of 24h
bytes (remember numbers in DEBUG are always hexadecimal); so that's 36 in decimal:
-d 102 l24
0D 0A 54 68 69 73-20 69 73 20 6D 79 20 66
..This is my f
xxxx: 73 74 20 44 45 42-55 47 20 70 72 6F 67 72
irst DEBUG progr
xxxx:D 21 0D 0A 24
& & Searches within a range of addresses
for a pattern of one or more byte values given in a list. The list can be comprised
of numbers or character strings enclosed by matching single or double quote
marks. [ NOTE: In the examples below, if you do find the same data on your
computer, the locations could easily vary from ours! ]
-s fe00:0 ffff &BIOS&
FE00: 61 72 64 20 53 6F-66 74 77 61 72 65 49 42
Award SoftwareIB
FE00: 43 4F 4D 50 41 54-49 42 4C 45 20 34 38 36
M COMPATIBLE 486
FE00: 49 4F 53 20 43 4F-50 59 52 49 47 48 54 20
BIOS COPYRIGHT
FE00: 61 72 64 20 53 6F-66 74 77 61 72 65 20 49
Award Software I
FE00: 2E 6F 66 74 77 61-72 65 20 49 6E 63 2E 20
nc.oftware Inc.
FE00: 03 0C 04 01 01 6F-66 74 77 E9 12 14 20 43
Aw.....oftw... C
FE00: 77 61 72 64 20 4D-6F 64 75 6C 61 72 20 42
.Award Modular B
FE00:F 53 20 76 34 2E 35-31 50 47 00 DB 32 EC 33
IOS v4.51PG..2.3
-s 0:0 dff 'A20'
0D 0A 41 32 30 20 68 61-72 64 77 61 72 65 20 65
..A20 hardware e
72 72 6F 72 2E 20 20 43-6F 6E 74 61 63 74 20 74
65 63 68 6E 69 63 61 6C-20 73 75 70 70 6F 72 74
echnical support
20 74 6F 20 69 64 65 6E-74 69 66 79 20 74 68 65
to identify the
20 70 72 6F 62 6C 65 6D-2E 0D 0A 24 1A 00 BA F6
problem...$....
-s 0:0 dff 43 4f 4d
A 02 A6 02 43 4F 4D 31-20 20 20 20 8E 00 70 00
C0 A0 7A 02 91 02 4C 50-54 31 20 20 20 20 A0 00
..z...LPT1
00 C0 A0 7A 02 98 02-4C 50 54 32 20 20 20 20
p...z...LPT2
2D 01 70 00 C0 A0 7A 02-9F 02 4C 50 54 33 20 20
-.p...z...LPT3
20 20 11 EA 27 27 3F FD-CA 00 70 00 00 80 7A 02
..''?...p...z.
AC 02 43 4F 4D 32 20 20-20 20 DC 00 70 00 00 80
7A 02 B2 02 43 4F 4D 33-20 20 20 20 00 00 6B 03
00 80 7A 02 B8 02 43 4F-4D 34 20 20 20 20 E8 D2
..z...COM4
& & Compares two
blocks of memory. If there are no differences, then DEBUG simply displays another prompt (-). Here's an example of what happens when there are differences:
-c 140 148 340
The bytes at locations 140 through 148 are being compared
to those at 340 ( through 348, implied ); the bytes
are displayed side by side for those which are different (with their
exact locations, including the segment, on either side of them).
& & This command can also be used to clear
&a whole segment of Memory as well as filling smaller areas with a
continuously repeating phrase or single byte. Examples:
-f 100 12f 'BUFFER'
-d 100 12f
xxxx: 46 46 45 52 42 55-46 46 45 52 42 55 46 46 BUFFERBUFFERBUFF
xxxx: 42 55 46 46 45 52-42 55 46 46 45 52 42 55 ERBUFFERBUFFERBU
xxxx: 45 52 42 55 46 46-45 52 42 55 46 46 45 52 FFERBUFFERBUFFER
-f 100 ffff 0
This last example fills almost all of the
assigned Segment with zero bytes (which can also be thought of as clearing
&the Segment). You should use this command whenever you want to be sure
the bytes you'll be looking at in DEBUG's Segment are those you
entered or loaded, or
bytes DEBUG not
soem previously used bytes from memory! If you want to examine
a file from a disk in a 'clean' Segment, you'll first have to start DEBUG without
any filename, clear the Segment using: &f
100 ffff 0 &and then finally load the file using the
commands in that order.
Filling (clearing) any bytes in the area from 00h
through FFh of our Segment can someti especially when file I/O
is involved. DEBUG stores data for its own use in those locations, so we recommend
you never overwrit unless you have a reason for doing so!
Example: A student in an
Assembly class was told to enter a string of commands under DEBUG, the last
one being: JMP 0 which he was supposed to
to the next command and then execute it. He was told it would be an INT
20 instruction. Well in most cases this is true, because DEBUG always
sets the first two bytes of its working segment to &CD 20& for just
this purpose. Let's test this out. First, open a new instance of DEBUG, then
enter the following commands:
-f 100 ffff 0
[Zero-out 100 through FFFF]
-e 100 e9 fd fe
[Enters a 'JMP 0' at 100]
-u 100 102
[Check for correct entry]
xxxx:0100 E9FDFE
DI=0000DS=xxxx
NV UP EI PL NZ NA PO NCxxxx:0100 E9FDFE
xxxx:0000 CD20
you don't see &INT 20& after entering &u 0 1&, then restart
DEBUG and try again.
[The &T&(Trace) command]
NV UP EI PL NZ NA PO NC
xxxx:0000 CD20
[Always make sure you use a &P&(Proceed) command for Interrupts!]
Program terminated normally
Well, this never worked
for those students. Why? Because the teacher had mistakenly told them to Fill
the whole segment with zero bytes (f 0 ffff 0),
in essence telling them to delete the very instruction he'd wanted them to execute!
& & Used to
enter data or instructions (as machine code) directly into Memory
locations.
& & Example. First we'll change a single byte at location CS:FFCB
from whatever it was before to
-e ffcb d2
This next example shows that either single(') or double(&)
quote marks are acceptable for entering ASCII data. By allowing both forms, entry strings
can be created to include either type of quote mark as data:
-e 200 'An &ASCII-Z string& is always followed by '
-e 22a &a zero-byte ('00h').& 0
But in order to enter more than a single line of ASCII data, the
is more practical since it will calculate the
next offset for you! (See that command for a Memory dump of these bytes.) &
Now we'll examine a string of 11 hex bytes you can enter into Memory at locations
CS:0100 and following:
-e 100 B4 09 BA 0B 01 CD 21 B4 00 CD 21
This is actually machine code for a program that will display
whatever ASCII characters it finds at locations CS:010B and following, until it
encounters a byte value of 24h (a $ sign). If you want to run this
program, we'd recommend entering 24h at offset location
7EAh of the Segment so the program will
And you'll soon see: &Program
terminated normally& on the display screen. Why did we pick 7EAh? Because
many DOS screens are set to display only 25 lines of 80 (50h) characters, and this value
allows you to view
the maximum number of characters
possible on a single screen between the &Go,&
termination and prompt (&-&) lines.
Here's something a bit more interesting for you
to try out: It's essentially the same program, but the data includes all of
the byte values from 00h through FFh; except for 24h which
we placed at the end of the last line. The DEBUG prompt symbol, - , has been
purposely excluded from the lines below, so you can copy and paste the
whole block into a DEBUG DOS-box ( if needed):
e 100 B4 09 BA 0B 01 CD 21 B4 00 CD 21 0D 0A 0D 0A 00 01 02
e 112 03 04 05 06 07 08 09 20 0B 0C 20 0E 0F 10 11 12 13 14
e 124 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 20 25 26
e 136 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38
e 148 39 3A 3B 3C 3D 3E 3F 0D 0A 0D 0A 40 41 42 43 44 45 46
e 15a 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58
e 16c 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A
e 17e 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C
e 190 7D 7E 7F 0D 0A 0D 0A 80 81 82 83 84 85 86 87 88 89 8A
e 1a2 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C
e 1b4 9D 9E 9F a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aA aB aC aD aE
e 1c6 aF b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 bA bB bC bD bE bF 0D
e 1d8 0A 0D 0A c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 cA cB cC cD cE
e 1ea cF d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 dA dB dC dD dE dF e0
e 1fc e1 e2 e3 e4 e5 e6 e7 e8 e9 eA eB eC eD eE eF f0 f1 f2
e 20e f3 f4 f5 f6 f7 f8 f9 fA fB fC fD fE fF 0D 0A 0D 0A 24
The bytes 0Dh and 0Ah produce a Carriage
Return and Linefeed on the display, so we replaced them in the listing above by 20h;
SPACE byte. The 24h byte was moved to the end of the program with
another 20h
taking its place. The bytes shown above in blue (0D 0A 0D 0A)
form blank lines at the beginning of the output and after every 64 bytes for a nice formatted display.
Therefore, when the program is run, we should see
four separate lines of 64 characters each (a few of those being blank spaces
as mentioned above), right? Well, let's find out: Start DEBUG in a DOS-Window,
copy and paste the lines above into DEBUG at its prompt symbol, then
enter the following command:
( 'g' followed by a SPACE, then '=100')
This will immediately run (see )
the program, displaying the output lines followed by: &Program terminated normally& [ Do not
exit DEBUG, just leave the window open. We're going to show you how to 'patch' this code and save the results as a nice little console program ].
Were you surprised to find more than four spac starting with the very first byte? What about the fact we appear to have
missing characters at the end of that line? We'll briefly explain why the characters appeared this way on your screen, but in order to create programs
of your own, you'll need to study about control characters, Interrupts and what effect different BIOS and DOS video functions have on the way
ASCII characters are displayed. OK, here's what happened:
First, the Zero byte also displays as a blank space here. The
07 byte may make a beep or ding sound (but does not display
anything), 08 performs a BACKSPACE (erasing the 06 byte character) and
09 is a TAB -- which may jump up to eight columns to the right before
reaching the next 'Tab Stop.' But since it just happens to begin in column seven,
it only moves one column to the right where our program places the space
we substituted for 0Ah. Lastly, for some reason, when using Function
09 of INT 21h (&Display a string of characters until a '$' sign is encountered&),
the ESC character (1Bh; 27 decimal) doesn't display or do anything. So, after reaching
the end of the first line, it only appeared as if many of the characters we expected to see
were never displayed. In reality, the last three characters are there. It's because of the bytes
07h (displayed nothing), 08h (only backspaced over 06h), 09h
(displayed nothing, but moved cursor forward one byte) and 1Bh (displayed nothing) that
we saw what we did.
Enter the following two lines into DEBUG (which contain more blank-space
substitutions),
run the program again, and you'll see all
the displayable
characters output on the first line in their correct positions:
e 10F 00 01 02 03 04 05 06 20 20 20 20 0B 0C 20
e 11D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 20
All four rows will display evenly in size, including the last one. But the
last character, FFh (255 decimal), just like the first, also displays as a blank space here!
You can prove this by inserting another byte such as 2Eh (a period '.') after FFh.
We've created the following patch which effectively moves up the remainder of the program after the
FFh by one:
e 21b 2e 0d 0a 0d 0a 24
After patching and running it again, the program output should look like this:
If you want to, you can save this code as an executable program by first giving it a path and
filename (such as, C:\; see ) and writing the bytes (see
) to a file like this:
[ Program Length = 220h - 100h + 1 = 121h ]
If you check the file properties ,
its size should be 289 bytes.
[=address]
[addresses]
& & Go is used to run
a program and set breakpoints in the program's code.
As we saw in an Example for the ENTER command, the '=address' option is used
to tell DEBUG where to start executing code. If you use 'g' all by itself, execution
will begin at whatever location is pointed to by the CS:IP registers.
Breakpoints are used to HALT the execution of a program we're testing at some
point of interest before its termination. Up to 10, optional breakpoint addresses may be set by
simply listing them on the '-g' separated by spaces. DEBUG will halt execution just before any of
breakpoint addresses is about to be executed, and all of them will be 'cleared' at this time as well. (If you
should somehow attempt to set more than 10 breakpoints, DEBUG will respond with: &bp Error.
NOTE: Breakpoints can only be set at an address containing the first byte of a valid
opcode. So don't be surprised if picking some arbitrary address nev
especially if you're trying to DEBUG a program containing opcodes DEBUG can't understand (that's any instruction
which requires a CPU above an )!
Using &Go& after setting breakpoints at instructions
you're sure DEBUG understands is one way you can get more use for example, when debugging the
&real& code of a Master Boot Record written for an 80386 or above processor. DEBUG won't be able to
disassemble, nor step through, such code, but it can pass the code for those type of instructions to the
CPU for immediate execution, and still stop at the breakpoint(s) you've set for any instruction that it
does understand!
CAUTION: DEBUG replaces the original instructions of any listed breakpoint
addresses with CCh (an INT 3). The instructions at these locations are restored to their original bytes
ONLY if one of the breakpoints is encountered. If DEBUG does not halt on any of the set breakpoint(s), they
will remain enabled! So, don't ever save the code unless you're sure all breakpoints have been cleared! (Saving
your work to a backup copy before ever using a breakpoint is the best way to avoid corrupting the code.)
Technical Notes: The &User& stack pointer
must be valid and have 6 bytes available for this command to function correctly. An iret instruction is used to jump to the first breakpoint encountered. DEBUG sets the User
Stack Pointer and pushes the user Flags, the Code Segment register and the Instruction Pointer onto the User Stack.
So if the User Stack is not valid or is too small, the operation might crash.
Creates machine executable code in memory beginning
at CS:0100 (or the specified address) from the
(and 8087) Assembly Language
instructions which are entered. Although no Macro instructions nor labels are
recognized, you can use the pseudo-instructions 'DB' and 'DW' (so you can
use the DB opcode to enter ASCII data like this: &DB & 'This is a string',0D,0A
); spaces after the commas would make it clearer
but aren't necessary.
The 'A' command remembers the last location where any data
was assembled, so successive 'A' commands (when no address is specified) will always
begin at the next address in the chain of assembled instructions. This aspect of the
command is similar to the Dump command which remembers the location of its last dump
(if no new address is specified).
The assembly process will stop after you ENTER an empty line.
Using the character string from our
xxxx:0200 db 'An "ASCII-Z string" is always followed by '
xxxx:022A db "a zero-byte ('00h').", 0
-d 200 23e
xxxx:E 20 22 41 53 43 49-49 2D 5A 20 73 74 72 69
An "ASCII-Z stri
xxxx: 22 20 69 73 20 61-6C 77 61 79 73 20 66 6F
ng" is always fo
xxxx:C 6F 77 65 64 20 62-79 20 61 20 7A 65 72 6F
llowed by a zero
xxxx: 79 74 65 20 28 27-30 30 68 27 29 2E 00
-byte ('00h')..
ENTER the characters in bold blue type; you do not need to enter the comments after the semi-colon ( ; ) symbols:
xxxx:0100 jmp 126 Jump over data that follows:
xxxx:0102 db 0d,0a,"This is my first DEBUG program!"
xxxx:0123 db 0d,0a,"$"
xxxx:0126 mov ah,9 Function 09 of Int 21h:
xxxx:0128 mov dx,102 DS:DX -& $-terminated string.
xxxx:012B int 21 Write String to STD Output.
xxxx:012D mov ah,0 Function 00 of Int 21h:
xxxx:012F int 21 Terminate Program.
This is my first DEBUG program!
Program terminated normally
NOTE: You can pipe simple
Assembly Language
&scripts& into DEBUG (You can even include a semi-colon ';' followed by comments on most
of its lines. For some odd reason though, these comments do not appear to be allowed on DB/DW lines!). For
example, you can copy and paste the following into DEBUG (after entering an initial &a&
command) and obtain the same results as above:
jmp 126 Jump over data that follows:
0d,0a,"This is my first DEBUG program!"
; End of string marker above: "$"=24h
mov ah,9 Function 09 of Int 21h:
mov dx,102 DS:DX -> $-terminated string.
int 21 Write String to STD Output.
mov ah,0 Function 00 of Int 21h:
int 21 Terminate Program.
DEBUG uses the convention of enclosing operands which refer to
Memory locations in square brackets '[ ]' (as opposed to an immediate value
as an operand).
DEBUG may require you to explicitly tell it whether or not an operand
refers to a word or byte in Memory! In such cases, the data
type must be stated using the prefixes 'WORD PTR' or 'BYTE PTR'
For all 8087 Math Coprocessor opcodes, the WAIT or FWAIT prefix must be explicitly
specified.
Unassemble:
& Disassembles
machine instructions into 8086 Assembly code. Without the optional
[range], it uses Offset 100 as its starting point, disassembles
about 32 bytes and then remembers the next byte it should start with if the
command is used again. ( The word 'about' was used above, because it may
be necessary to finish with an odd-number of bytes greater than 32, depending
upon the last type of instruction DEBUG has to disassemble. )
& & &NOTE: The user must decide whether the bytes that DEBUG
disassembles are all 8086 instructions, just data or any
newer x86 instructions (those for the 8 on up to the lastest
CPU from I which are all beyond the ability of DEBUG to understand)!
-u 126 12F
xxxx:0128 BA0201
xxxx:012B CD21
xxxx:012D B400
xxxx:012F CD21
The use of I/O
commands while running Windows™9x/Me is just plain unreliable!
This is especially true when trying to directly
access hard disks! Under Win NT/2000/XP, the I/O
commands are only an emulation; so don't trust them. Though the
example below still works under Win2000/XP, it's most likely using some WinAPI
code to show what's in the W not directly from an RTC
Long ago (when DOS was the only OS for PCs), there
were dozens of BASIC programs that used I/O
commands for handling tasks through parallel and serial ports (e.g., to change
the font used by a printer or values in a modem's control registers). Under
real DOS, they can still be used for direct communications with keyboards or
a floppy drive's control chips along with many other hardware devices.
& & Here's an example of how to read the hours and minutes from a
computer's &real time clock& (RTC):
&-- Check the hours.
&----- 18 hours (or 6 p.m.)
&-- Check the minutes.
&----- 52 minutes
The first space isn't necessary under most versions
of DEBUG; so you can try to get away with just &o70& and &i71&
instead. Here's a page of more complex examples dealing with !
& & See comments under the
L [address] [drive] [firstsector] [number]&&&or program! (See the
for more on this)
& & This command will LOAD the selected
number of sectors from any disk's Logical Drive under the control of MS-DOS
or Windows into Memory. The address is the location in Memory the data
will be copied to (use only 4 hex digits to keep it within the memory allocated
to DEBUG), the drive number is mapped as: 0=A:, 1=B:, 2=C:, etc., firstsector
counts from ZERO to the largest sector in the volume and finally number
specifies in hexadecimal the total number of sectors
that will be copied into Memory (so a floppy disk with 0 through 2,879 sectors
would be: 0 through B3F
& & The terms 'Volume' or 'Logical Drive'
used in the definition above mean
you cannot use the 'L'
command to load or examine the MBR, or any other sectors outside
Primary Volumes or Logical Drive Letters assigned by DOS or Windows!&For
example (under Windows™ 9x/ME), if you enter the command: & L
100 2 0 1 & in DEBUG, instead of seeing the very first sector
on that hard disk (the MBR), you'll see the first sector of the Boot Record
for the Logical drive C: instead (the first partition that can accessed by a
compatible MS-DOS or Windows OS). This and the following comments about diskettes,
show that DEBUG has always been quite limited compared to a good disk editor
or the UNIX 'dd' program.
Load can still be useful in examining Floppy Disks
even under Windows™ 2000/XP, but (unfortunately), only if
the disk can be read by MS-DOS or Windows. Once again, this shows how
limited DEBUG is compared to any utility that can view the raw data on
either a hard drive or diskette. (For those of you who wish to examine the actual
contents of a hard disk under Windows™ XP, there are free , such as ,
which allow you to do so.)
Unlike hard disks, the very first sector on a floppy
disk is an OS Boot sector. Here's what you might see from a Logical disk sector
from a couple floppy disks.
-l 100 2 0 1
[ the C: drive. ]
-d 100 10f
EB 58 90 4D 53 57 49 4E-34 2E 31 00 02 08 20 00
.X.MSWIN4.1... .
-d 280 2ff
xxxx: 0D 0A 49 6E 76 61-6C 69 64 20 73 79 73 74
.'..Invalid syst
xxxx:D 20 64 69 73 6B FF-0D 0A 44 69 73 6B 20 49
em disk...Disk I
2F 4F 20 65 72 72 6F 72-FF 0D 0A 52 65 70 6C 61
/O error...Repla
63 65 20 74 68 65 20 64-69 73 6B 2C 20 61 6E 64
ce the disk, and
20 74 68 65 6E 20 70 72-65 73 73 20 61 6E 79 20
then press any
6B 65 79 0D 0A 00 00 00-49 4F 20 20 20 20 20 20
key.....IO
53 59 53 4D 53 44 4F 53-20 20 20 53 59 53 7E 01
00 57 49 4E 42 4F 4F 54-20 53 59 53 00 00 55 AA
.WINBOOT SYS..U.
-l 100 0 0 1
[ a floppy in the A: drive. ]
-d 100 13d
EB 3C 90 29 47 38 71 33-49 48 43 00 02 01 01 00
.<.)G8q3IHC.....
xxxx: 00 40 0B F0 09 00-12 00 02 00 00 00 00 00
...@............
xxxx: 00 00 00 00 29 40-16 D8 13 4E 4F 20 4E 41
......)@...NO NA
xxxx: 20 20 20 20 46 41-54 31 32 20 20 20
-l 100 0 0 1
[ a different floppy in the A: drive. ]
-d 100 13d
EB 3C 90 53 59 53 4C 49-4E 55 58 00 02 01 01 00
.<.SYSLINUX.....
xxxx: 00 40 0B F0 09 00-12 00 02 00 00 00 00 00
...@............
xxxx: 00 00 00 00 29 7E-CF 55 3C 20 20 20 20 20
......)~.U<
xxxx: 20 20 20 20 46 41-54 31 32 20 20 20
-d 2d0 2ff
42 3B 16 1A 7C 72 03 40-31 D2 29 F1 EB A7 42 6F
B;..|r.@1.)...Bo
6F 74 20 66 61 69 6C 65-64 0D 0A 00 00 00 00 4C
ot failed......L
44 4C 49 4E 55 58 20 53-59 53 F4 3C 82 3A 55 AA
DLINUX SYS.<.:U.
The Linux Boot disk above (note the word:
SYSLINUX) is the kind formatted as an MS-DOS diskette and not with a true Linux
file system (such as ext2 or ext3). If it had been formatted with
some other kind of file system, or had a faulty boot sector, then MS-DEBUG would
not be able to read it! Instead you'd see that old &General
failure reading drive A / Abort, Retry, Fail?& error message! And
when you had finally cleared away that error message, you'd be greeted by DEBUG's
&Disk error reading drive A& error message.
This makes DEBUG almost worthless as far as trying to fix an error in a floppy disk's
boot sector! However, if you keep a binary copy of a good floppy disk
Boot Sector somewhere, you could use DEBUG to overwrite whatever's on
a faulty floppy disk's first sector (see ). But
if you really need
to see what's in such a Boot sector (i.e., what is
keeping DEBUG from
recognizing it as valid), you'll need to use a
such as Symantec's Norton DiskEdit (in Physical disk Mode only).
NOTE: Just because a floppy disk can't be
read by DOS or opened in DEBUG does NOT necessarily mean it's defective. It
might simply have been formatted with a file system it cannot recognize (such
as Linux's ext2) and could easily boot-
good reason for labeling your disks! (CAUTION: Never try booting your system
with a disk you're not 100% unless you disconnect all hard disks and
don't have any flash BIOS, since it might contain a nasty boot virus!
& [ Many floppy disks have the letters & IHC
& in their OEM ID field. What kind of OEM Name is that? None. Someone at
Microsoft decided that this was where they'd place a new pseudo-random type
of identification to make sure that any information cached by 'Windows 9x'
from one disk wouldn't be mixed up with info from a different one if you swapped
disks. The whole string begins with five pseudo-random hex bytes,
and always ends with the characters IHC. All floppy diskettes
that are not write-protected will have any original OEM ID overwritten.
Once Windows has written this string, it will remain the same for any future
disk reads or writes. However, performing even a quick format under Windows,
will change the five hex bytes every time.
& & Some have concluded the characters 'IHC' are the first
three letters of the word &Chicago& in reverse order, since
Chicago was the 'code name' for Windows& 95 before it was
ever released (it would have appeared as ' OGACIHC' on the hypothetical
disk). Although certainly a possibility, I have no proof of that. Due to our interest in some very old Greek Manuscripts,
we still can't help but see the 3 characters 'IHC' as an Iota, Eta and old style Sigma
since this combination of letters was often used as an abbreviation for the Greek word
&IHSUS& (Jesus). Just another of many coincidences in our lives.
& & REMEMBER: If you really want to preserve all of the contents
of an important diskette, you can't even perform a simple Directory read under
a Windows OS, UNLESS it is 'write-protected' and you know the
drive's write-protect system is functioning correctly! ]
& & This command
COPY (not Move), since it only copies all
the bytes from within the specified range to a new address.
& & Examples:
-m 7c00 7dff 600
Copies all 512 (200h) of the bytes between Offsets 7C00 and
7DFF (inclusive) to Offset 0600 and following.
-m 100 2ff 200
This second
example shows
it's very easy to overwrite much of the
same source area you're copying from when using the Move command. However, DEBUG
must store all the source bytes in Memory otherwise, this
example would cause a problem when
overwriting an area
copied data from yet, if it were copying only one byte at a time from that source area! The example above copies all
512 bytes of offsets 100h through 2FFh
(inclusive) to Offsets 0200 overwriting the last 256 (2FF-200+1 hex) bytes of the source in the
process. This is also true under real 16-bit DOS.
Note: If your Move command produces a situation where offset
FFFFh has already been written to yet there's still more data to write, you may experience unexpected results! Remember, DEBUG is technically assigned
to only one 64 KiB Segment. So, the data
wrap around to the beginning of the Segment, possibly overwriting
of the source bytes you
told it to copy from! But other symptoms may occur as well, since the first area to be overwritten after wrapping around (00h through FFh) is sometimes used by DEBUG to keep track of itself.
So do the math
whenever copying bytes to a higher location in Memory, to be sure you don't run out of room at the end of the Segment.
bytes to a lower location in the Segment is
DEBUG could actually
copy just one byte at a time in that direction and never
overwrite a
source byte before it was already
[pathname]
& & This command can be used to load
files into DEBUG's Memory after you have started the program, but it's
main function is to create a new file under control of the Operating System
which DEBUG can
& & Normally, when you want to 'debug' a file, you'd start DEBUG with
a command like this: & C:\WINDOWS&debug
. & But it's also possible to load a file into DEBUG's
Memory from within DEBUG itself by using the 'N' command and then the
(with no parameters) like
& & -n c:\
which will load the
into DEBUG's Memory starting at location CS:0100
(you cannot specify any other location when using the L command like
& & The 'N' command makes it quite easy
to save data or an Assembly program created in DEBUG to a file on your hard
drive! For example, the following commands (shown in bold blue type)
will create a 68-byte file called
C:\TEMP even when running DEBUG in a DOS-window. The file names, however,
are still limited to DOS's eight characters plus three for the
extension (often called an 8.3 filename):
cs:0100 jmp 138
cs:0102 db 0d,0a,&It's OK to run this &
cs:0118 db &program under DOS or Windows!&
cs:0135 db 0d,0a,24
cs:0138 mov dx,102
cs:013B mov ah,9
cs:013D int 21
cs:013F mov ax,4c01
cs:0142 int 21
cs:0144 & [Press ENTER key.]
Writing 00044 bytes & [ 68 bytes in decimal ]
How did we arrive at the value of &44&
to put into the CX register for writing that many bytes to our new file? Well, if you assemble a program
in DEBUG using the
command just as we did above, you can subtract the location
that we started our programming on from the location DEBUG displays on the line you stopped the assembly
by pressing the ENTER key. This will save you a bit of thought by not having to remember when you subtract
the first byte location (of the first instruction) from the last byte location (of the last instruction),
both bytes being inclusive, that you must then add a 1 to the result to obtain the total number of bytes
in your program. Or, putting this in terms of the digits involved: &
(144h - 100h ) = (143h - 100h + 1) = 44 hex = 68 decimal.
NOTE: Unlike other programs listed on this page, this last one used
the Function 4Ch instead of Function 00 of Interrupt 21h to terminate its execution. This is the preferred
termination function for most DOS programs, because it can send a &Return Code& (an ERRORLEVEL
of whatever is in the AL register), and will also close all open files and free all memory
belonging to the process. However, when you use this function to terminate a program you run under DEBUG,
it has a tendency to terminate DEBUG thus the reason we rarely use it here!
Homework: Follow the steps above to
and save this program under DEBUG, then use DEBUG to debug it!
to step through most of the
instructions, since
this will keep you from accidentally stepping
into an INT(errupt) instruction! If you ever do use the T(race) command
on an INT, you'll end up inside nests of BIOS routines which often crashes
[register]
& & Entering ' r ' all by
itself will display all of the 8086 register's contents and
the next instruction which the IP register points to in both machine code
and an unassembled (Assembly Language) form. For example, if you start
DEBUG in a Windows 95B DOS-box with the command line: & &
&debug c:\windows\
and then enter an ' r ' at the first DEBUG prompt, DEBUG will
display someting similar to this:
NV UP EI PL NZ NA PO NC
For an explanation of the names of
the registers (AX, BX, CX, etc. and the Flag symbols: NV UP EI PL NZ
NA PO NC), see the Appendix ().
The last line shows
the next CPU instruction (actually the first
in this case) to be executed, begins at memory location 100 hex (the offset)
in Segment ED8 hex (0ED8:0100) and the Hex bytes E90E01 represent the
actual binary machine code of the CPU instruction (JMP 0211 in Assembly
language) that would be executed by DEBUG if you entered a
If you enter the ' r ' followed by the abbreviation for an
8086 register, such as: ' rcx ', then DEBUG will display only the contents
of that register followed by a line with a colon symbol (:) on which you can
enter a hex number to change the contents of that register. If you simply
press the ENTER key, the contents remain the same. For example:
& & CX 0100& & :273
& & -means the Register command was used to
change the contents of the CX register from 0100 to 0273. The command rcx could also be used again
to verify the change had indeed taken place.
NOTE: The register command only functions with 16- including
the Flags register, so entering an 8-bit or an invalid register name results in:
& br Error.
Typing the letter f (for Flags) after the r: rf, causes DEBUG to display all the FLAG register bits and
its 'prompt' on the same line. This prompt allows you to change all, or none, of the
individual flag bits. For example, here's how you would display the flags and change
only the Zero and Carry flag bits from being cleared (a 0 bit) to being
set (a 1 bit) and check them without making any further changes:
&NV UP EI PL NZ NA PO NC &-zr cy& &-rf& &NV UP EI PL ZR NA PO CY &-&
As you can see above the Zero and Carry flags were changed from NZ and NC (both cleared)
to ZR and CY (both set). See our Appendix:
for an explanation of all the Flag abbreviations.
Any order, with or without spaces, is acceptable after the 'prompt' (such as: -zrupcy).
Attempting to enter an incorrect abbreviation for a flag value (even with one or
more correct names) results in a: & bf
Error &and no flags are changed.
Attempting to enter abbreviations for both clearing and setting the same flag,
at the same prompt, will cause DEBUG to display the: &df Error.
[=address]
& & The T command is
used to trace (step through) CPU instructions one at a time. If you enter
the T command
by itself, it will normally step through only ONE instruction
beginning at the location specified by your CS:IP registers, halt program
execution and then display all the CPU registers plus an unassembled version
of the next instru this is the 'default' mode of the
TRACE command. Say, however, you wanted DEBUG to trace and execute seven
instructions beginning at address CS:0205; to do so, you would enter:
& & -t =205 7
Remember that the value for the number of instructions to execute must be
given in hexadecimal just as all other values used in DEUBG. (Since the T
command uses the &hardware trace mode& of the CPU, it's possible
to step through instructions in a ROM - Read Only Memory - or step into
BIOS code which has been
shadowed in read-only portions of Memory
for decades now.) NOTE: If you find yourself stuck inside a long LOOP or
REPeat string instruction, enter a
will complete the operation and move to the next instruction.
[=address]
& & Proceed
acts exactly the same as Debug's
with these notable exceptions: &Proceed will immediately execute all
instructions (rather than stepping through each one) inside any
subroutine CALL,
REPeat string instruction or any software
INTerrupt. You can still step into an INT or execute all the code contained in a subroutine if you need to, but
with the Proceed (P)
command you are
not required to do so.
& & This means Proceed
&will probably be the command of choice for most of
debugging tasks, with Trace
only being used to step through an unfamiliar
subroutine or
check the logic of the first few iterations of long REP string instructions or LOOPs. And it's a must use command when it comes to Interrupts!
W [address] [drive] [firstsector] [number]
W A R N I N G
Do NOT experiment with the W -
write command in DEBUG. It can be used effectively to create new files
on your hard drive, but only if you use it properly. Trying to write
directly to a sector on a hard disk would very RARELY be considered proper
use of this command!
Trying to write directly to a hard
disk using sector numbers will most likely result in loss of data or even
a non-booting system! (Although Windows XP and
later prevent direct Sector writes to a hard disk, they are
still allowed
to floppy drive media, i.e., drive letters A: or B:)
& & The WRITE (W) command is often used
to save a program to your hard disk from within DEBUG. But the only safe way to
do so, especially under Windows, is by allowing the OS to decide where to physically
create that file on the disk. This is done by first using the
to set up an optional path and filename for the
new file (or to overwrite one that already exists). DEBUG will automatically begin
saving program or data bytes from Offset 0100
of the 64 KiB Segment
the OS allocated for it. The only other requirement
is to set the size of the file you wish to write by placing the total number of
bytes in the combined BX
and CX registers
before executing the WRITE command. The
to change the value in the CX register in the following example from our
After creating and running a small program inside of DEBUG which copies the Master
Boot Record (MBR) to Offset 0000h through 01FFh, these DEBUG
commands save the MBR to a file on the hard disk:
-n mymbr.bin
Writing 00200 bytes
[ 512 bytes in decimal ]
The BX register had
already been set to zero by a previous instruction, so the CX register was simply
set to 200 and the WRITE command executed with an address of 0 (if no
address is used, the Write command starts saving bytes at Offset 100).
The WRITE command can, however, be used in a relatively safe manner
with Floppy disks. For example, you could use the :
& & l 7c00 0 0 1
to load the first sector of an MS-DOS or Windows floppy disk into DEBUG's memory
at location 7C00, change some of the code and/or messages (if you know how to
do so) and then use the 'W' command:
& & w 7c00 0 0 1
to write the changes back to the floppy disk's first sector.
___________________
the BX and CX registers are often referenced in books on Assembly as BX:CX
when they discuss this write command, note
that these registers are not being
used like Segment:Offset pairs in this case! They are a true combination of higher and lower bytes which
form a 'double word' for a theoretical total of about 4 GB (FFFF FFFFh
= 4,294,967,295 bytes) that could be written to a file! Whether or not this is true of all versions of
DEBUG, under DOS 7.1, we've been able to load image files of several hundred KiB and write the whole file
to a new location!
& & For example, if you load a 360 KiB
image file into DEBUG at a DOS prompt, then check the
registers, BX will equal 0005 and
CX will contain A000. The major problem here though is the fact DEBUG uses CONVENTIONAL MEMORY,
so trying to load a file greater than about 400 KiB is bound to elicit an
&Insufficient Memory& error!
You may have missed this page on: . And there are
more examples of many DEBUG commands on these x86
tutorial pages:
Updated: September 28, 2007. (28.09.2007)
Previous Update:
August 23, 2010. (23.08.2010)
Last Update: September 19, 2010. (19.09.2010)