Do not depend on using the DDK's DDKDEBUG.BAT batch file to copy debug binaries to their proper locations. Instead, copy debug binaries to the locations indicated in KB article Q163358.
The DDKDEBUG.BAT file was originally intended to, among other things, allow the customer to copy debug binaries from the DDK to the windows environment. The user was to type ddkdebug set to install the debug binaries, and ddkdebug restore to remove them.
However, there is a bug in the ddkdebug.bat file, described in the following paragraphs.
Note The KB Article, Q163358, "PRB: DDKDEBUG.BAT Copies Some Drivers to the Wrong Directory", describes a problem in the DDKDEBUG.BAT file. A summary of this KB article follows:
If you use the \ddk\debug\ddkdebug.bat file to set the debug environment, it does not work correctly.
CAUSE
=====
When you use the ddkdebug.bat file to set the debug environment, the batch file simply copies all the *.vxd files to the \windows\system\vmm32 directory. This directory is not the proper location for some of these drivers.
RESOLUTION
==========
Here are the correct target locations to copy the debug drivers. If debugging Golden Windows 95, the debug binaries are located in the \ddk\debug directory. If debugging Windows 95 version OSR2 ("version "B"), see the following for instructions on how to obtain the OSR2 debug binaries.
| Driver file name | Required target directory | Comments |
|---|---|---|
| bios.vxd
configmg.vxd ios.vxd vdd.vxd vdmad.vxd vflatd.vxd vkd.vxd vmcpd.vxd vmm.vxd vpicd.vxd vxdldr.vxd |
\windows\system\vmm32 | Replacements for components that were originally "bound" into vmm32.exe. |
| cdtsd.vxd
cdvsd.vxd disktsd.vxd diskvsd.vxd scsiport.pdr |
\windows\system\iosubsys | IOS layered hierarchy drivers |
| eisa.vxd
isapnp.vxd lptenum.vxd ndis.vxd pccard.vxd pci.vxd |
\windows\system | All other VxDs |
| debugcmd.tmp | \windows\system\debugcmd.vxd | Installed for additional debugger dot commands (see System Dot Commands, .P). Note that the file extension needs to be renamed from ".tmp" to ".vxd". |
Windows 95 Version OSR 2.1 (USB Support)
| Driver file name | Required target directory | Comments |
|---|---|---|
| VMM.VXD
VPICD.VXD VXDLDR.VXD NTKERN.VXD |
\windows\system\vmm32 | Replacements for components that were originally "bound" into vmm32.exe. |
| USBD.SYS
OPENHCI.SYS UHCD.SYS USBHUB.SYS |
\windows\system | WDM driver components |
WIN.COM starts VMM32.VxD (formerly DOS386.EXE). During setup, many standalone VxDs are bound into one large file named VMM32.VxD. The number of VxDs bound can vary from machine to machine. This is done for quicker loading. However, there is still a separate, smaller VxD called VMM32.VxD, whose job is to load static system VxDs. The "bigger" VMM32.VxD contains it. The loader VMM32.VxD will first search for and load standalone VxDs located in the path \windows\system\vmm32. These VxDs replace VxDs by the same name that were bound into VMM32.VxD at setup time. Therefore, debug binary vxds that are placed into \windows\system\vmm32 will replace their (retail build) counterparts located in the bound VMM32.VxD. Within the registry or in SYSTEM.INI, an asterisk preceding a driver name (e.g. *VPICD, *VDMAD) indicates the driver is a "child" VxD located within VMM32.VxD. The driver replacement rules, just described, also apply to these child device references.
The Windows 95 path \windows\system\iosubsys contains I/O Supervisor (IOS) drivers. IOS is a layered hierarchy of drivers, implementing protected-mode 32 bit disk I/O. The drivers in this path are loaded by *IOS during its DEVICE_INIT phase.
The Windows 95 path \windows\system contains all other VxDs.
If you manually copy debug binary drivers, we recommend that you back up or rename any VxD's that go by the same name in the target path, so you can restore the normal VxDs later.
The original debug binaries in the original Windows 95 DDK are intended for the use with the original (Golden) version of Windows 95. If debugging Windows 95 version b (OSR2), or version 2.1 (USB / WDM support) obtain the OSR2 or OSR21 debug binaries, located at the following Microsoft web site:
http://support.microsoft.com/support/ddk_hardware/winddk/tools/
Alternatively, go to the Microsoft Support site (http://support.microsoft.com/support) and search using the following keys:
My search is about: Device Drivers
I want to search for: osr2 debug binaries
You can also use DDKDEBUG.BAT to remove the system debug environment and restore the original system files, by typing ddkdebug restore. However, the same problem regarding the ddkdebug set issue still needs to be addressed.
The RUNWDEB.WRF file contains command-line options for the debugger. This file along with RUNWDEB.BAT is copied to the WINDOWS\SYSTEM directory (provided that files with these names are not already present in that directory).
Before you can use RUNWDEB.BAT, you may need to edit it to contain the correct debug settings. These settings are:
| /c: | Number that represents the COM port to which debug terminal is attached. For example: /c:1 |
| /r: | Baud rate at which debug terminal will be operating. For example: /r:19200 |
You can add any other desired command line options to this file.
You will likely need to edit the RUNWDEB.WRF to add /s: options for the symbol files of the components you intended to debug. Remember that the symbol file(s) installed must match the corresponding binary, both in (Windows 95) version and the distinction between retail or debug versions.
Once you have completed editing these files and verifying settings, you can start the debugger by running RUNWDEB.BAT (with one optional WDEB386 command line parameter) from the WINDOWS\SYSTEM directory.
All WDM debugging under Windows 95/98 should be done with a standard Windows 95 system debugger such as WDEB386 or SoftIce. Debug output from WDM drivers such as a USB driver will not be displayed in real-time, unlike other Windows 95 debug components such as VxDs. Instead all WDM debug output is written to a debug log. To view this log you must use the debug interface of NTKERN.VXD. This is accomplished by breaking into the debugger and then typing ".NTKERN". You then type "D" to dump the NTKERN debug log. Note that the log is dumped in reverse order, meaning the first debug message displayed in the log is the one most recently logged. No debug binaries are required to use the debug log in NTKERN.VXD.