Controlling Windows .NETs Boot Debugging Option

When Windows.NET crashes with a blue screen of death, often the only way to really get a feel for the true cause of the problem is to use the systems boot debugging mode. In Windows NT and Windows 2000, setting up boot debugging was a little on the complicated side. However, in Windows .NET, Microsoft has included a command line utility called BOOTCFG that among other things, allows you to gain direct control over debugging mode. As you may know, the main purpose of debugging mode is to transfer a memory dump to another PC where the information can be analyzed. While this may not initially sound like any big deal, you must remember that Windows only enters debugging mode when there has been a fatal system error. Therefore, the operating system isnt running and the network services are hence unavailable. This is where the BOOTCFG command comes in. BOOTCFG must be run from within a Command Prompt window prior to the crash. For example, if you know that the system crashes every time that you run a specific application, you could use BOOTCFG just prior to launching the application. There are lots of things that arent related to debugging that BOOTCFG can do. For example, BOOTCFG can modify the BOOT.INI file by adding, deleting, copying, or editing entries. You can access the debugging portion of the utility by entering the BOOTCFG command followed by the /DEBUG switch and the other necessary parameters. Here are the various switches available to you: Value- This must be either on, off, or edit /S the name of the remote system that the debugger should attach to /U the username (and domain name) that the debugger should use for logging into the remote system /P The password for the remote system /Port the COM port that will be used for transferring the debugging information to the other PC. The valid options are COM1, COM2, COM3, and COM4. /BAUD the speed that the communications session should flow a valid transfer rates are 9600, 19200, 38400, 57600, and 115200 /ID specifies which entry in the BOOT.INI table that the debugging parameters should be assigned to. The entry will be a number such as 1, 2, or 3. You can see the boot entries by number by entering the BOOTCFG /QUERY command. Now that youve seen the switches that go with the BOOTCFG /DEBUG command, lets take a look at some common uses of these switches. At its simplest, the command simply requires you to turn on debugging, specify a COM port, and specify a transfer speed followed by a BOOT.INI entry number. In such a case, the syntax might look something like this: BOOTCFG /DEBUG ON /PORT COM2 /BAUD 19200 /ID 2 Of course there are also situations in which youll be required to specify a machine name, user name, and a password. In such a situation, the command might look more like what you see below: BOOTCFG /DEBUG ON /S computer_name /U domain_name\user_name /P password /ID 2 As you can see, the BOOTCFG command makes the task of configuring debugging mode much easier than it was in previous versions of Windows.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.