Rob van der Woude's Scripting Pages
BE CAREFUL: This machine has no brain, use your own

(Ab)using DEBUG

Notes: 1 This page shows some uses of the DEBUG command.
It is not about debugging.
If you are looking for my page on debugging batch files, follow this link.
For info on debugging VBScript, follow this link.
2 Click a file name to expand and view its source code; click the file name again, or the expanded source code, to hide the source code again.
To view the source code on its own, right-click the file name and choose Open or Open in separate tab or window.
3 Click 💾 to download all DEBUG sources for this page.


A note on DEBUG and Windows XP

Back in the MS-DOS era, DEBUG used to be able to read and write directly to memory.
In Windows 2000 and XP (and most likely in NT 4 as well, though I didn't verify this assumption) however, DEBUG doesn't really have access to the physical memory, as it runs in an emulated 16-bits environment. So even when DEBUG seems to access memory and CPU registers directly, it only accesses an emulated copy. This means that in these 32-bit environments, DEBUG can no longer be used to change/write to memory, but you can still use it to read from memory.
That's why KeyLocks.bat does work and CAPS_OFF does not.


A note on DEBUG and 64-bits Windows versions

As stated in the note on DEBUG and Windows XP, DEBUG runs in an emulated 16-bits environment in 32-bits environments.
64-bits Windows versions no longer support 16-bits emulations, only 32-bits emulations, so DEBUG no longer works in 64-bits environments.
As a matter of fact, neither does any *.COM "executable".

The only workaround I know is using a 32-bits virtual machine.
Though useful for development or testing, it is not practical for everyday use.


Reboot DOS

Note: Using this command usually results in a "warm restart" of the computer, like pressing Ctrl-Alt-Del.
You might even use it in Windows (3), where it will bring up the process list; again, like pressing Ctrl-Alt-Del.
Sometimes, however, it will result in a "cold restart", like pressing the reset button. In Windows, this could lead to loss of data and even to corruption of the file system.
You should let your batch files check for the operating system if you use tricks like these.
Use with extreme care and at your own risk!

See the Shutdown and Reboot page for related commands for Windows 3.*, 95/98, NT and for OS/2.

Back to the top of this page...


CMOS Real Time Clock

With help from The Starman's DEBUG Tutorial and PLASMA Online's CMOS Register Reference I found I could use the following DEBUG commands to read the CMOS Real Time Clock:

-o 70 0E
-i 71
09               (if greater than 7F, clock was not set after loss of battery power)
-o 70 32
-i 71
20               (century)
-o 70 09
-i 71
24               (year)
-o 70 08
-i 71
07               (month)
-o 70 07
-i 71
18               (day)
-o 70 06
-i 71
05               (day of the week)
-o 70 04
-i 71
11               (hours)
-o 70 02
-i 71
10               (minutes)
-o 70 00
-i 71
01               (seconds)
Note: Except for the first number (the check if the clock was set) all numbers are in BCD.

I have used this technique in the following batch files:

Closely related to the CMOS RTC is the CMOS DST (Daylight Savings Time):

💾   Download all DEBUG sources

Back to the top of this page...


CMOS battery status

CapsLock, NumLock and ScrollLock keys' status

Related utilities:

💾   Download all DEBUG sources

Back to the top of this page...



This script is based on the simple DEBUG command D C000:0040, which I found at Computer Hope.
The resulting screen output looks like this, depending of course on your video card:

C000:0040  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
C000:0050  E9 19 71 00 43 10 31 40-E9 3C 10 E9 43 10 50 4D   ..q.C.1@.<..C.PM
C000:0060  49 44 58 00 5B 00 00 00-00 A0 00 B0 00 B8 00 C0   IDX.[...........
C000:0070  00 5B FF 7F 4E 56 00 05-14 C5 BD E0 24 01 11 03   .[..NV......$...
C000:0080  00 00 00 00 CE AA 59 AC-EF 01 D0 A4 08 A4 7C A4   ......Y.......|.
C000:0090  08 01 50 00 8C 74 71 28-13 66 6D 66 FB 6A B0 6A   ..P..tq(.fmf.j.j
C000:00A0  C4 6A 99 01 BC 01 C4 B1-00 01 01 00 3F 3E 37 36   .j..........?>76
C000:00B0  00 7E 66 10 67 20 A1 07-00 90 D0 03 00 32 AA 82   .~f.g .......2..

Using FOR's /F switch in NT 4 I filtered out the hexadecimal stuff, and I added 8 more lines of output with a second DEBUG line:

Now the screen output may look like this:

.~f.g .......2..
d.......ASUS V71


I'm afraid version 3 is much harder to read, and much much harder to explain. However, I like this one because it does not use any temporary files at all and its output is more readable (one single line, multiple dots are replaced by single dots and unprintable characters are removed).

This is what version 3's output looks like:

Video adapter ROM manufacturer info:

.q.C.1@.C.PMIDX.[.[.NV.$.Y.P.tq(.fmf.j.j.j.?76.~f.g .2.g.g.g.g.PCIR.d.ASUS V7100


If you thought version 3 was hard to read, you'd better skip version 4.
However, I like this one best because it not only doesn't use temporary files, but most of all because it displays a really "clean" output.

This is what version 4's output looks like:

Video adapter ROM manufacturer info:



And here is the MS-DOS version of the batch file, which isn't easy reading either ... of course.
The DOS version doesn't handle < and > characters in the string very well, which may result in stray files or unexpected error messages.
You may want to execute this batch file in your TEMP directory only, because it could produce lots of stray files.


Perl and Rexx are much better suited for parsing strings, that's why I combined this DEBUG trick with Perl and Rexx string parsing to create and VideoROM.rex.
Both scripts filter and display the relevant output perfectly:


I also created KiXtart and VBScript versions that use WMI instead of DEBUG to retrieve the information from Windows:

Video summary for MYOWNPC:

	Name:                    NVIDIA GeForce2 MX/MX 400
	Description:             NVIDIA GeForce2 MX/MX 400
	Video Processor:         GeForce2 MX//MX 400
	Adapter RAM:             32 MB
	Video Mode Description:  1600 x 1200 x 65536 colors

For Windows XP Professional and later, you can use WMIC.EXE:

WMIC Path Win32_VideoController Get AdapterRAM,Description,Name,VideoModeDescription,VideoProcessor /format:list

which returns something like:

Description=ATI Radeon HD 5700 Series
Name=ATI Radeon HD 5700 Series
VideoModeDescription=1440 x 900 x 4294967296 colors
VideoProcessor=ATI display adapter (0x68BE)

💾   Download all DEBUG sources

Back to the top of this page...



I created this batch file after reading a tip by Alfred Poor in PC Magazine.
GetPorts displays the hexadecimal I/O addresses for COM1 through COM4 and LPT1 through LPT3.
It has been tested in Windows 98 (Dutch), OS/2 Warp 4 (English and Dutch) and Windows NT 4 (English, though by using completely different commands this should be really language independent in NT). It should prove not too hard to add other languages.

Perl and Rexx both are very good at handling redirected standard input and output, so I combined this DEBUG trick with Perl's and Rexx's standard output handling to create and GetPorts.rex.

For Windows XP Professional and later, you could use WMIC.EXE of course, but it won't return I/O addresses. But then again, most XP systems don't even have parallel or serial ports anymore!

WMIC Path Win32_ParallelPort Get /format:list
WMIC Path Win32_SeriallPort Get /format:list

💾   Download all DEBUG sources

Back to the top of this page...



CHKDRV by Richard D. Benton and Robert L. Hummel was published in PC Tutor, February 28, 1989 (Volume 8 Number 4).
It is a small utility that lets a batch file test a floppy drive specification for various errors.
The ZIPped documentation with source, example batch file and the 48 byte program itself are available for download.

💾   Download all DEBUG sources

Back to the top of this page...



This script by Charles Dye returns the drive letter of the CD-ROM drive.
See the Solutions found on alt.msdos.batch page for more details.

💾   Download all DEBUG sources

Back to the top of this page...



I'm not sure where this script came from, most likely from PC magazine.
Typing the command LPTSTAT will display a message like this one, stating if your parallel printer ports are ready to accept print jobs:

LPT1: printer not busy, no ack, paper, selected, no error.
LPT2: printer not busy, no ack, paper, selected, no error.
LPT3: printer not busy, no ack, paper, selected, no error.

💾   Download all DEBUG sources

Back to the top of this page...


How to use the following DEBUG scripts

To create any of the following utilities, first create the script using any text editor. You may type the scripts manually, but it is safer to copy and paste the scripts from this web page to your text editor.
Don't skip the blank lines, they are absolutely necessary.
Next, execute the following command:
Substitute the appropriate file name for MYSCRIPT.SCR and make sure the script is in the current directory (or precede it with its full path).

A great way to use DEBUG scripts in batch files could once be found at McAfee's website.

In their SAVEMBR batch files the following trick is used:

debug < %0.BAT
goto around

a 300
mov ax,201



(Do not skip the empty lines, they are vital)

The trick is that the first two lines and the last line will be ignored by DEBUG since they do not contain valid DEBUG commands.
This way the batch file can also serve as a DEBUG script, so you don't need two separate files.
This trick can be used for any DEBUG script.
It has been used in many of my own batch files.

And while at the subject of saving MBRs: Roger Layton's MBRWizard can do just that and restore it as well, plus more.

💾   Download all DEBUG sources

Back to the top of this page...


Ask for user input

This script came from Microsoft Knowledge Base article Q77457: Accepting Keyboard Input in Batch Files.
It will create a 14 byte executable file named REPLY.COM which can be used to retrieve single key user input in batch files.

Though the Microsoft article states that the information applies to MS-DOS versions 3.1 through 6.22, the REPLY.COM utility works fine in Windows 2000's COMMAND.COM sessions too. Just use COMMAND /E:8192 /C to call the batch files that use REPLY.COM.

MS-DOS 6.* and Windows 9x don't need this utility, of course, since these DOS versions come with the CHOICE command.

💾   Download all DEBUG sources

Back to the top of this page...


Return a character's ASCII value

This script returns the ASCII value for any given character, like the Asc( ) function found in several scripting languages.
The batch file combines the 2 previous tricks and uses redirection to send a character to the utility created by DEBUG.

💾   Download all DEBUG sources

Back to the top of this page...


Display Grayscales

The next DEBUG script creates two tiny programs, GSON.COM and GSOFF.COM. GSON will set Gray Scale display ON, GSOFF will return to color display again. I have used these scripts many times to check if fancy color combinations would produce acceptable contrast on monochrome monitors.

💾   Download all DEBUG sources

Back to the top of this page...



A reboot tool that works in any DOS environment, even Quarterdeck's QEMM or Desqview.
Create RESET.COM by copying the following script, RESET.SCR, and executing the command:
Make sure that RESET.SCR is in the current directory, or precede it with its full path.

💾   Download all DEBUG sources

Back to the top of this page...



These scripts read 1 byte from the CMOS, and the batch files extract the floppy drives configuration from that byte.
Both batch files are self-contained, i.e. the DEBUG script is embedded.

Sorry, it looks like readability wasn't a top priority when writing these scripts...

💾   Download all DEBUG sources

Back to the top of this page...


Back to the top of this page...


page last modified: 2022-10-26; loaded in 0.4002 seconds