There is a problem with the KB888111 update in the 2.0.4 update pack. It doesn't install properly with my installation cd and I have to manually go to update driver and then choose the hdaudbus.sys file. My guess is it can't find it during device driver installation phase in setup.

Can you make sure that editing the INF won't result in a broken file signature? If the driver becomes unsigned, then it opens up another can of worms.

And my experience with the HDA driver on my laptop is that it worked fine as it is...? I'm willing to make the change, but only on the condition that XP doesn't pitch a fit. The way to find out is to leave "DriverSigningPolicy" out of winnt.sif and do an XP install. Do your sound drivers get installed OK? Furthermore, if you run sigverif.exe, does it complain about any unsigned files?

EDIT: Well I checked and you are correct. It's really odd that textmode doesn't seem to care. All I can surmise is that the original checksum on the file is set to 0, and maybe that's a flag to textmode setup to allow it. Anyway, I've gone ahead and modifype'd it on my end for the next release

I agree with your guess, Ryan.
If textmode setup complain about that, MS can not leave their several update with invalid checksum.
I could not see noticeable problem to install KB888111, neither.
Anyway, thanks for ModifyPE action on next pack.

Windows reported it as not digitally signed before I made the changes as well. This may have to do with the checksum being 0.

Actually, if you like at the inf files, they don't reference a cat signature so they were never signed to begin with.

Installation never worked for me. I would get an unknown device under System devices with a yellow !. I would have to update driver and it would find the UAA Bus Driver for HDA but it would then prompt me for the "installation disk" for hdaudbus.sys which was already in the system32 directory.

Another way to do it would be to throw the sys files in the root outside of I386 and just have the inf's in there Setup seems to copy them from the installation cd during device detection.

I wouldn't mind getting more confirmation from other users that they also experience the same problem. Like I said, the only thing I know is that I don't on the one system I have access to with HD audio onboard.

I should also say the reason I'm so skeptical is that the files are copied during textmode setup, as you can see by examining entries.ini. They aren't copied from the CD when the drivers are installed. That's why I think something else is at play in your situation. I've had KB888111 integrated for a very long time now (coming up on a year) and you're the first person to report issues with it. That tends to at the very least make me skeptical .

Yeah they are copied during textmode as the hdaudbus.sys does end up under system32. However, during device setup it seems to look for the file with the source disk as the setup cd, and not the windows system32 directory. All I know is that adding "I386" allows it to install without any problems.

it can be seen that the file hdaudbus.sys has already been copied there during textmode and thats why it needs to copy via temporary file and set to overwite on reboot. However, during device setup apparently my cd/setup doesn't look in c:\windows\system32\drivers as a potential source for files. It only looks in H:\ (CD Root) and C:\Windows\NLDRV which is the nLite integrated drivers.

Can anybody else who uses HD Audio please comment and/or post the relevant portions from their setupapi.log (preferably with an integrator-only install so as to make sure factors like nLite aren't in play)?

For quite some time now I've had various computers at work with RealTek HDA adapters install just fine. This is using a Method 2 BTS integration, however I don't use BTS's slipstreamer. I just use my own M2 addon through the Integrator and drop the DriverPacks to the system drive.

It's not a very diverse hardware sampling. Intel and Gigabyte motherboards, and I'm pretty sure every HDA adapter is RealTek (much to my dismay). But it has been working for me since V2.0.1 if I remember correct.

Interesting that mine complains about the driver not being signed etc, but there is no such complaint in Ryan's log. It also complains about the lack of a signature which is true because the inf I have doesn't reference a cat file. Or maybe that has to do with having SFC disabled.

I should try an install with just the pack integrated and nothing else nlited.

I did so with an Intel D945PVS Motherboard (contains Sigmatel HDA) with plain XPSP2, newest RVM Update Pack and my own driver collection (works similar to BTS's driver pack M1, but does only append to OemPnPDriversPath), and it works fine:

But I also tried "kb888111.exe /integrate:..." with the intresting result that there are tree new subdirectories created under \I386
- svcpack
- CommonFiles
- WinXPSP2
where svcpack contains the KB888111WXPSP2.exe and KB888111WXPSP2.cat, CommonFiles contains all hda*.* files and WinXPSP2 contains portcls.sys.

They only edited scvpack.inf and dosnet.inf but txtsetup.sif was unchanged.

Later I will try an unattended setup with this constellation of files but by removing KB888111WXPSP2.exe. If this works, it maybe
a better solution.

Thanks for the additinal info. It seems that in your installation "hdaudbus.sys" was not copied during device installation as well. Weird that only in my installation does it actually try to copy the file.

But I also tried "kb888111.exe /integrate:..." with the intresting result that there are tree new subdirectories created under \I386
- svcpack
- CommonFiles
- WinXPSP2
where svcpack contains the KB888111WXPSP2.exe and KB888111WXPSP2.cat, CommonFiles contains all hda*.* files and WinXPSP2 contains portcls.sys.

They only edited scvpack.inf and dosnet.inf but txtsetup.sif was unchanged.

Later I will try an unattended setup with this constellation of files but by removing KB888111WXPSP2.exe. If this works, it maybe
a better solution.

I tried a unattended setup after that integration and must confirm, that it won't work this way, at least it does not work with winnt.exe. (I could have seen this also without trying it out, since Commonfiles is longer than 8 Chars)

Yes, and I renamed the entries in dosnet.inf accordingly. But regardless of this these entries are not correct, so not even the CopyMode will work.

I did this test to see if there is a alternate to Ryan's way to integrate KB888111, but this alternate does not work at least when using with winnt.exe, so we can forget it. If I would change things the /integrate switch of the patch did to make them work, I will end up with Ryan's solution, so I will end this try at this point.

I happened to be updating my cd and ran into this problem again. Now I have some answers to some of the questions that Ryan had.

Textmode setup does not complain because it does not parse the inf file. It merely copies the inf and sys files to their appropriate places:
%systemroot%\inf
%systemroot%\system32\drivers

During device driver installation, hdaudbus.inf matches and attempts to copy the files from the current working directory, which happens to be the root of the installation cd. Updating the single source disk name defenition to

Apparently my reply yesterday got lost when my DB server went down. The issue reported in this thread is indeed fixed. However, the fix in this thread is what has caused the other issues some have run into (but not all, of course).

RyanVM wrote:Apparently my reply yesterday got lost when my DB server went down. The issue reported in this thread is indeed fixed. However, the fix in this thread is what has caused the other issues some have run into (but not all, of course).

So it is no longer necessary (or recommended) to use the fix in this thread?