Configuring a System for Debugging

Ordinarily, you will run Windows NT Workstation or Windows NT Server with the debug mode turned off, which is the default when Windows NT Setup installs the system. In that mode, an Executive STOP or STATUS message will not enable the debugger. To switch Windows NT into debug mode, you have to edit the Windows NT startup file, BOOT.INI, and include one of the two debug-mode switches: /crashdebug or /debug. If you include the /crashdebug switch in the BOOT.INI file, the debugger is loaded when you start but remains inactive unless a Kernel error occurs. This mode is useful if you are experiencing random, unpredictable Kernel errors. When you include the /debug switch, the debugger is loaded when you start and can be activated at any time by a debugger connected to the computer. This is the standard mode used when debugging problems that are regularly reproducible.

You can also change the default communications port and baud rate by editing the BOOT.INI file. Since the code that enables remote Kernel debugging resides in the hardware abstraction layer (HAL), the defaults for the communications port and baud rate may vary from one computer to another. On x86-based computers, if you have more than one communications port, the default debug port is set to COM2. However, if you have a serial mouse attached to COM2, the default debug port is set to COM1. If you do not set the baud rate, the default baud rate is 9600 if a modem is attached. If necessary, you can verify later what baud rate has been set. On RISC-based computers, the default debug port is set to COM1.

When you are finished debugging the computer, you should turn the debug mode off again. To do this, repeat the process of editing the BOOT.INI file or the OSLOADOPTIONS environmental variable, and delete any values you set to enable debugging. On a RISC-based computer, this may mean the OSLOADOPTIONS variable has no values, which is acceptable.

To specify settings, you can use the following procedure, which will prepare your computer for either remote or local Kernel debugging.

To prepare an x86-based target computer for remote or local debugging

  1. For remote debugging, connect a modem to the communications port, turn the power on, and set the modem to auto-answer. This could also be done on a second computer and then the modem could be moved to the target computer after a Kernel error occurs.

    For local debugging, connect the null-modem serial cable to any available communications port.

  2. Restart the computer under MS-DOS or Windows NT.

    If you can restart under Windows NT, double-click the Command Prompt icon in the Main group to access the command line.

  3. To turn off the system, hidden, and read-only attributes of the BOOT.INI file, type:

    attrib -s -h -r boot.ini

    The BOOT.INI file is usually located in the root directory of the partition from which the Windows NT NTLDR program was loaded, which is ordinarily C:\.

  4. To use MS-DOS Editor to change the BOOT.INI file, type:

    edit boot.ini

    The BOOT.INI file appears within the MS-DOS Editor window and normally looks something like the following example:

    [boot loader]

    timeout=30

    default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

    [operating systems]

    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" Version 3.5"

    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" Version 3.5 [VGA mode]" /BASEVIDEO

    C:\="MS-DOS"

    Each entry in the [operating systems] section should correspond to the options listed in the boot menu during a normal system startup.

  5. Select the startup option that you normally use and add either the /debug or /crashdebug switch at the end of the line.

    An alternative to using the /debug switch is to add switches at the end of the line that explicitly set the communications port and baud rate your computer will use to send debugging information.

  6. To specify the communications port, add the switch /debugport=comx, where x is the communications port that you want to use.
  7. To specify the baud rate, add the switch /baudrate=<baudrate>.

    Valid speeds for the baud rate range from 75 to 115,200 baud. The hardware will determine the speed chosen. 9600 baud is the normal rate for remote debugging over a modem. Local debugging over a serial cable can run as fast as 57,600 baud or higher if both computers can support the speed.

    The following is an example of a startup-option line specifying the communications port and baud rate:

    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" Version 3.5" /debugport=com1 /baudrate=9600

  8. Save the file and quit MS-DOS Editor.
  9. Restart the computer to run under Windows NT.

    You may now contact your technical support group or a trained technician and have them call the modem to establish a remote debugging session.

Preparing a RISC-based computer for remote or local Kernel debugging also involves editing one line in a startup file, but you access that file in a different manner.

To prepare a RISC-based target computer for remote or local debugging

  1. For remote debugging, connect a modem to the communications port, turn the power on, and set the modem to auto-answer. This could also be done on a second computer and then the modem could be moved to the target computer after a Kernel error occurs.

    For local debugging, connect the null-modem serial cable to any available communications port.

  2. Restart the computer.

    The ARC System screen appears, displaying the main menu from which you can select an action.

  3. On a MIPS RISC-based system, choose Run Setup to display the Setup menu and then choose Manage Startup to display a menu of the boot options.

    On a Digital Alpha AXP RISC-based system, choose Supplementary Menu, Set Up the System, and Manage Boot Selection Menu to display a menu of the boot options.

  4. Choose Change a Boot Selection to display a list of the operating systems that are installed on this computer.
  5. Choose the Windows NT operating system. If you have more than one version of Windows NT installed, select the one that you want to debug.

    A two-part screen appears for changing the current settings of the environment variables used to start the RISC-based computer. The environment variable that controls whether or not the RISC-based computer starts up in debug mode is the OSLOADOPTIONS variable.

  6. To edit the value for the OSLOADOPTIONS variable, use the arrow keys to select it from the list of variables.

    Once selected, it appears in the Name box at the top of the screen.

  7. Press enter to display the Value box.
  8. Type debug or crashdebug in the Value box and press enter to save it and turn the debug mode on.

    You may also add a value that explicitly sets the communications port, as in the following example:

    OSLOADOPTIONS debug debugport=com2

    If you do not specify the debug port, the default debug port is set to COM1. Since RISC-based computers allow only a default baud rate of 19200, you do not need to specify the baud rate.

  9. Press Esc to stop editing.
  10. On a MIPS RISC-based system, choose Return To Main Menu and then Exit to return to the ARC System screen.

    On a Digital Alpha AXP RISC-based system, choose Supplementary Menu, save your changes, and then choose Boot Menu to return to the ARC System screen.

    If this is the first time that you have debugged a Digital Alpha AXP RISC-based system, after connecting the local host computer, you now need to do the following:

    • Shut down both computers
    • Restart the host (debugger) computer
    • Run WinDbg in Kernel-debug mode
    • Restart the target (Digital Alpha AXP RISC-based) computer while WinDbg is running on the host computer to set up configuration information on the target computer and prepare it for either local or remote debugging.
  11. Restart the computer to run under Windows NT.

    You may now contact your technical support group or a trained technician and have them call the modem to establish a remote debugging session.