Being an audio enthusiast, I'm an avid user of sound cards. For the past couple of years, I've had an ongoing battle in getting a sound card to work with Windows XP SP2. Although I haven't been able to determine the root cause of the problem, I recently came up with an effective workaround that uses DevCon, a utility that lets you manage devices from the command line. Although I'm using DevCon to manage sound card hardware, you can use it to manage other types of finicky hardware as well.
The problem began after I applied SP2 to my XP workstation two years ago. The PC locked up immediately after I typed in my credentials and pressed Enter during the XP logon. With the assistance of a Microsoft support technician, I discovered that the Windows Driver Model (WDM) driver (i.e., the Windows sound driver) for my Creative Labs' Sound Blaster Live! card was the culprit.
The debugging effort turned out to be one of those ordeals in which Microsoft said it was a hardware problem, and the hardware vendor said it was a Microsoft problem. As a workaround, the Microsoft support technician found that if I disabled the Creative SB Live! (WDM) driver in XP's Device Manager (devmgmt.msc), I could at least boot to the Windows desktop so that I could work (without sound, though).
I later found that I could enable the card's WDM driver once the desktop was fully loaded. I then had a fully functional sound card and a stable PC. The downside was that if I forgot to disable the card's WDM driver before I shut down the PC, it would lock up the next time I logged on. I then had to use the PC's reset button, get into Windows via Safe Mode, disable the driver, and reboot.
Over the course of the next two years, I occasionally experimented with various ways to try to fix the problem. I tried the usual procedures, such as:
- Moving the Sound Blaster Live! card to different PCI slots in an attempt to change the IRQ that the card was using.
- Using the card's old DOS setup utility to manually set a specific IRQ, then setting the PC's BIOS to use only that IRQ on a specific PCI slot and forcing Windows to use that IRQ as well.
- Attempting to delay the startup of the sound service by implementing the solution presented in the Microsoft article "How to delay loading of specific services".
None of these solutions worked, so I replaced the Sound Blaster Live! card with a new Plug and Play (PnP) sound card. The new card had a different chipset (i.e., C-Media Electronics' C-Media) and different WDM driver. Surprisingly, I experienced the same problem with the new card. Since I preferred the Sound Blaster Live! card's MIDI wavetable samples and What U Hear feature, I reinstalled it and donated the new sound card to a relative.
At this point, I decided to automate the tasks of enabling the Creative SB Live! (WDM) driver after the desktop loaded and disabling it before shutdown. I decided to use DevCon because it lets you enable and disable devices from the command line. To use DevCon, though, I had to get the WDM driver's hardware ID.
To determine the hardware ID for the WDM driver, I opened up Device Manager, double-clicked Sound, video and game controllers, right-clicked the Creative SB Live! (WDM) entry, and selected Properties.
In the WDM driver's properties page, I clicked the Details tab. The first item in the Property drop-down list was Device Instance ID. The box directly underneath the drop-down list showed that ID, which was PCI\VEN_1102&DEV_0002\SUBSYS_00211102&REV_03…. (I truncated it to save space.) The first part of the device instance ID provided the hardware ID. It specified that the driver had a physical PCI bus interface, the vendor was 1102 (i.e., Creative Labs), and the vendor's ID for the device was 0002. The balance of the device instance ID (anything to the right of 0002) wasn't needed to use DevCon to enable and disable the driver. If you're unfamiliar with hardware IDs and device instance IDs, check out Table 1. More detailed information can also be found in the Microsoft articles "Device Identification Strings" and "Device Management and Installation Step-by-Step Guide: Controlling Device Driver Installation and Usage with Group Policy".
| Identifier | Description | Example |
|---|---|---|
| Device ID | Vendor-defined identifier that is the most specific, identifying a device's make, model, and revision. A device has only one device ID. The first ID in a list of hardware IDs is referred to as the device ID. | PCI\VEN_1102&DEV_0002&SUBSYS_00211102&REV_03 |
| Hardware ID | Vendor-defined identifier that is less specific than the device ID. For example, it might identify a device's make and model but not its revision. | PCI\VEN_1102&DEV_0002 |
| Instance ID | System-assigned identifier that distinguishes a device from other devices of the same type on a machine. | \3&61AAA01&0&50 |
| Device Instance ID | System-assigned unique identifier for a device. It consists of a device ID followed by an instance ID. | PCI\VEN_1102&DEV_0002&SUBSYS_00211102&REV_03\3&61AAA01&0&50 |
Next, I used Notepad to create a .cmd script named BAB's-SoundBlasterLiveOn.cmd, which contained the code
@echo off devcon enable "PCI\VEN_1102&DEV_0002"
I put this script in the C:\Windows folder.
For my first test, I decided to try to add BAB's-SoundBlasterLiveOn.cmd to the Local Computer Group Policy Object (GPO) as a startup script. After opening the Group Policy Object Editor (gpedit.msc), I navigated to Local Computer Policy, Computer Configuration, Windows Settings, Scripts (Startup/Shutdown). I highlighted Scripts (Startup/Shutdown) in the navigation tree, selected Startup in the right pane, then clicked the Properties link. In the Startup Properties dialog box, I added BAB's-SoundBlasterLiveOn.cmd.
After rebooting and logging on, I found that my first test didn't work. The PC locked up. Apparently, the WDM driver was still getting enabled too soon.
For my second test, I added BAB's-SoundBlasterLiveOn.cmd to the OS's All Users Startup folder. (I wanted this script to run for all users on the PC.) In XP, this folder is typically found at C:\Documents and Settings\All Users\Start Menu\Programs\Startup. I rebooted the PC and logged on. In about 15 seconds, I saw a command window pop up, the WDM driver load, and the command window close. Voila—the sound card was successfully enabled!
Now that the sound card was enabled, I needed a way to automatically disable the card upon shutdown. Using Notepad, I created a .cmd script named BAB's-SoundBlasterLiveOff.cmd, which contained the code
@echo off devcon disable "PCI\VEN_1102&DEV_0002"
Once again, I put this script in the C:\Windows folder.
In this case, the timing of the disablement wasn't as crucial, so I decided to try using the Local Computer GPO again. I added BAB's-SoundBlasterLiveOff.cmd to the Local Computer GPO, but this time I added it to the Shutdown Properties dialog box. (Highlight Scripts (Startup/Shutdown) in the navigation tree, select Shutdown in the right pane, then click the Properties link.) The GPO-invoked script successfully disabled the WDM driver.
DevCon isn't installed by default in Windows OSs. You can download it from the Microsoft article "The DevCon command-line utility functions as an alternative to Device Manager" (support.microsoft.com/kb/311272). The file that you download will contain devcon.exe for both 32-bit and 64-bit Windows OSs. You need to copy the appropriate version to your %systemroot%\system32 directory. After DevCon is installed, you can view the command-line syntax by running the command
devcon /?
in a command shell window.
With DevCon, you can use the asterisk (*) wildcard. For example, the command
devcon find PCI\*
will return the instance IDs and device names of the PCI devices currently present on the local computer. A similar command is
devcon findall pci*
This command lists all the PCI devices, even PCI devices that currently aren't present (e.g., they've been removed, they're software-enumerated devices that don't get installed until needed).
If you want to learn the status of each PCI device on the local machine (e.g., running, disabled), you can run the command
devcon status @PCI\*
Perhaps you aren't concerned with PCI devices but instead hard drives attached to IDE or SCSI interfaces. The easiest way I found to list the variety of device types present on a machine is
devcon status * | more
You can then use the command
devcon status @ide\*
to get the status of the IDE interfaces or
devcon status @scsi\*
to get the status of the SCSI interfaces.
These are only a few of the many operations you can perform with DevCon. It's a versatile tool you can use on local and remote computers. If you work with devices often and you're not familiar with this tool, you might want to give it a try.
