DEBUG Basics
Home Up DEBUG Basics Trace: PUSH/POP Trace: CALL Trace: INT Trace: small prog Control Structure
2003-09-23 11:44


This course makes extensive use of the DOS DEBUG command.

DEBUG can be used to examine the contents of files, both plain and executable, and to examine the contents of disk sectors from your disk drives.

In all cases, knowing how to supply DEBUG with a prepared sequence of  instructions and then saving the output to a file for later printing is an essential skill.

This page contains the following sections:

Capturing output from DEBUG (under Windows and under DOS)
Writing DEBUG scripts (for examining programs or disk sectors)
Output Format for screens and dumps (Courier font only!)
Tracing COM file programs

For more detailed understanding of the power of DEBUG, here are some links to general descriptions of how to use the DOS DEBUG command:

Capturing output from DEBUG

Some of the course assignments require you to capture the output of DEBUG.  Sometimes, you can use the mouse to do this; sometimes, you have to save the output in a file for later printing and hand-in.

Cut-and-Paste under Windows 9x

If you're running DEBUG in a DOS Window under Windows 9x, you can always use the mouse to copy text from your DOS window and paste it into another application such as Wordpad, or Write.  (Do not save the entire bitmap window as a graphic using Print Screen - the resulting file is huge and unnecessary.  Save the text only, using cut-and-paste into another application such as Write or Wordpad and print the text from there.)

Saving output under DOS (pure DOS)

If you're running in pure-DOS mode, without Windows running, the Print Screen button won't work unless you have an attached text printer on your computer, and neither will the mouse function to cut-and-paste.

Study the examples below under the heading Writing DEBUG Scripts.  You can enter a few DOS DEBUG commands into a text file (using a program such as DOS EDIT), and have DEBUG read the file and execute the commands while you redirect the output into an output file.  (You can also type the commands blind into DEBUG with just the output redirected!)

Once you have your saved DEBUG output in a file, you can restart Windows on your computer and print the output files (using a Courier or Terminal fixed-width font).

Writing DEBUG scripts

One of the handy things you can do with DEBUG is prepare small text files of DEBUG commands (and even include assembler instructions) and run them through DEBUG using command line redirection to get a quick idea of how something works:

C:\> debug  <inputcommands  >outputfile

Writing Scripts for Program Debugging

See the script file debug_script.txt and its corresponding output file debug_script_out.txt.  I've edited the output file to add comments explaining what I was doing in the script file, and how to create the script file.

Writing Scripts for Disk Sector Debugging

If you're trying to dump disk sectors (as you do in Project 4 in this course), you may find these kinds of DEBUG scripts, used with command line redirection, necessary for saving your DEBUG output into files for later printing.  Here is an example of a script file that dumps the BOOT sector and first ROOT directory sector of a floppy disk (drive A:):

Input file for DEBUG: debug_dump.txt  
Output from DEBUG: debug_dump_out.txt

Output Format for screens and dumps

When you finally print some screen text, dump information, traces, or programs, you must use  a Courier or Terminal fixed-width font so that the text lines up.  Do not print with a variable-width font such as Times, Tahoma, or Arial!

Wordpad or Write let you choose a smaller font size for printing your screen dumps, so that the text doesn't overflow the right margin and wrap around the page. 

Do not use Notepad to print screen text - the output font is almost always too large, causing the lines to wrap.

Tracing COM file programs

DEBUG is able to load and let you single-step through ".COM" format executables.  The quickest way to get the executable loaded into DEBUG is to give the program you wish to debug as a command argument.  All .COM programs start at segment offset 0100h, so that's where you'll find your first instructions, ready to be traced:

C:> debug
-u 0100 
1454:0100 BE8100        MOV     SI,0081
1454:0103 803C0D        CMP     BYTE PTR [SI],0D
1454:0106 7421          JZ      0129
1454:0108 803C20        CMP     BYTE PTR [SI],20
1454:010B 7511          JNZ     011E
1454:010D BA2F01        MOV     DX,012F
1454:0110 B409          MOV     AH,09
1454:0112 CD21          INT     21
1454:0114 83C601        ADD     SI,+01
1454:0117 803C20        CMP     BYTE PTR [SI],20
1454:011A 74F8          JZ      0114
1454:011C EBE5          JMP     0103
1454:011E 8A14          MOV     DL,[SI]

With your program in memory, you are now ready to debug it by single-steping through it using the "Trace" or "Proceed" commands, watching the flow of control and the values of the registers.

If you want to supply command line arguments to a program being debugged, simply add them to your DOS command line when you call DEBUG:

C:> debug argument1 argument2 arg3 ...etc...

Using "Trace" vs. "Proceed" in DEBUG

Don't use "Trace" to trace an INT instruction; use "Proceed" instead.  If you trace the INT instruction, you will end up tracing the call to the interrupt service routine in DOS that actually performs the interrupt service, and that can be many hundreds or thousands of instructions!  The "Proceed" instruction will not trace the interrupt service routine; it will simply let it execute (without tracing each instruction) and it will pause when the service routine returns to your program.



Web Author: Ian! D. Allen      Updated: 2003-09-23 11:44

Internet Free Zone Level 1 logo Support free and non-commercial Internet.

Any Browser logo This site works best in Any Browser, a campaign for non-specific WWW.

Creative Commons License logo This work is licensed under a Creative Commons License.