I've been trying to find some info on what components
(regsvr32 type stuff) might be involved, but I'm having
no luck in a search engine. I don't know how to reset
the sound system part that connects to the driver.
As far as I know, your Pavilion 700 uses an Asus OEM motherboard
A7M266-M. It is not similar to A7M266 Retail motherboard (for which
the Asus site has driver support). The motherboard is Bermuda/BoraBora,
implying perhaps more than one model of the same thing. It uses an
AMD761 Northbridge and a VIA 686B Southbridge (split-brand chipset).
Since sound is off the Southbridge, we pretend it's a "VIA Chipset".
(23 page pseudo-manual for your motherboard - more than Asus would
normally prepare for end-user consumption, but still inadequate)
http://www.elhvb.com/mboards/OEM/HP/manual/bermuda_manual.pdf
The way AC'97 works, is a driver combines support for the AC'97
Codec details (3 or 6 jack config, PNP 12 bit number for CODEC
declaration), as well as for the Southbridge end. So something
on the Southbridge end is also custom, and the driver sets it up.
<---- driver ---->
Southbridge ---- RealTek --- 3 jacks, to amplified speakers
AC'97
I downloaded this file (since you suggested it, and I couldn't
find it in the Pavilion 700 driver section), and it does use
a naming convention consistent with multiple Southbridge support.
So it probably has VIA support for the Southbridge end of the link.
ftp://ftp.compaq.com/pub/softpaq/sp35001-35500/sp35461.exe
First, I stumbled on a 64 bit INF file, for a later OS.
[SourceDisksFiles]
ALCWDM64.SYS=222
SOUNDMAN.EXE=222
ALSNDMGR.CPL=222
ALSNDMGR.WAV=222
RTLCPL.EXE=222
RtlCPAPI.dll=222
CPLUtl64.exe=222
Alcrmv64.exe=222
[DestinationDirs]
AC97AUD.CopyList=10, system32\drivers
[Realtek.NTamd64]
%ALCVIA.Desc%=AC97VIA, PCI\VEN_1106&DEV_3058&CC_0401
As far as I can figure out, VEN 1106 is VIA, and
DEV 3058 is a common device identifier for VIA Sound
in old Southbridges. Since there is a match in the file,
it does appear that the INF is intended for this class
of hardware.
But I can't offer any other insights as to what is
supposed to happen. As I can't find any info on what
OS sound files connect to these things, and might benefit
from some sort of repair.
I do know from personal experience, all it takes is installing
a second sound card, a card with a bad driver design, to
shoot the sound in the first device in the foot. I had a driver
that abused a registry entry (by removing it), which prevented
the other device from working. And even if that bad driver was
removed, the registry entry wasn't coming back. And the first
driver did not have the common sense to create a new registry
entry. I think the registry entry was created by the OS. After
I made a registry entry for it manually, it started working
again. So I do know of that one example.
And a "driver cleaner" wouldn't have helped in a case like that.
A "Hail Mary" approach to fixing it, would be "sfc /scannow",
which is supposed to check and replace system files. But since
that never seems to get mentioned in a resolution to this problem,
I'm guessing it doesn't help.
I tried an ident on ALCWDM64.SYS, and it says it is for a
64 bit OS, and is a .NET assembly. So that tells me the
first INF file I tried, is for a 64 bit OS. Pretty strange
to offer such a driver package, for your vintage of computer.
There's probably one guy out there in the world, using
that combination of hardware and OS
The install folder is chock full of .inf files, and another
one of interest might be alcxau.inf
[SourceDisksFiles]
ALCXWDM.SYS=222
SOUNDMAN.EXE=222
ALSNDMGR.CPL=222
ALSNDMGR.WAV=222
RTLCPL.EXE=222
RtlCPAPI.dll=222
Alcrmv.exe=222
[DestinationDirs]
AC97AUD.CopyList=10,system32\drivers
So maybe that's what it would copy on your 32 bit system.
When I check ALCXWDM.SYS, it says it is for a 32 bit OS and is
not a .NET assembly. It's a plain executable. And that's more
consistent with older OSes. As is the accompanying ALCXWDM.cat
file with the security information.
You can look in the setupapi.log file, to see an entry around
the time the sound driver was installed.
When an INF file is used for installation, a copy is
put in the INF folder in the system folder. But, the idiots
rename the file to "OEM23.INF", as a means of preventing
name collisions (OEMxx). If the INF file contains a reference to
its own name, you can then see if the INF made it to the
INF folder. It's just an indicator that the driver installation
attempt got part way along. Of course, in the Device Manager,
you can also use the tab that shows the driver files, to
get some idea whether they got installed or not.
I don't have any concrete advice to go on now - I would
be "picking over the scraps" to try to figure it out
Paul