Thanks,
dolivas

Sound_A_7115_prunefix

Oh, the semicolon is again out of the INF.

MD5 hash
05528d24affa832b17f7fe4aeec4449b  DP_Sound_A_wnt5_x86-32_7115_prunefix.7z
====
Sound B prunefix

updated
C\2 Cmedia open source from 10/01/2007,1.1.6 to 11/21/2007,1.1.7

NEW
C\5 Cmedia 108, 12/30/2004,5.12.01.0042.7 (62.2) (lucky2007)

Sound_B_7115_prunefix

MD5 hash
7225f3073c07457d0bdbf13a617eab85  DP_Sound_B_wnt5_x86-32_7115_prunefix.7z

Happy Thanksgiving everyone and enjoy the family today......

I can add your fix right now if i want... lets proceed slowly and with due caution.

Hope things are well I have a question about where we are at with the test packs. Moving forward do we plan on using these and if so what are we going to do when there are updated drivers like is the case right now with R/1 and R/2 in the new Sound A that muiz just released? R/1 has all kinds of HWIDS  that looks like you had removed there is also work that is going on with the Sound Blaster cards, I have ordered some of the different sound blaster cards so I can help test. It seems that we have all kinds of test packs being worked on by different people which is excellent but I was just wondering  do you all have a common goal if so what is it should I stop using the test pack with the HWIDS removed and start use the one that muiz, mr_smartepants and other are working on? Just looking for some direction also do we plan on implementing the fix for the SoundMAX control panel that I tested it works and fixes the error when running the directX diag sound test.

Thanks,
dolivas

I'll run the tool, and expect realtek to again claim it does SiS and Via, and Nvidia like it's their own, and I'll probably find same dupes.
(Oh, it added ONE new specific HWID, and corrected a subsys 00000000)

I am not a data mining expert.
(hehe, I am not an expert in anything..)
The raw output from the tool has to be looked at with argus eyes, because there are drivers what have 'dupes' in the inf. The tool is not ALWAYS able to gather Operating System info from the Inf, so I had to look at content to see why dupes was there.
That was like work.

I've seen a driver that had "suspicious" lines in it, and sure enough, the next update fixed it.
It also added wdm copies of the INF files that had not existed before..

I've seen drivers that had dupes in it that were real errors by the OEM.
(like in, they added their HWID, and it already existed. It did not call different settings/registry sections.)
It was NOT for some particular dual card. The excell shows wher I found one of those.. I marked it "B" so it would no longer hilite.. The tool's raw output does show duplicate lines caused by sections which are duplicated across drivers for registry entries. They are not HWID dupes.)

The worst are those that let generic HWIDs exist, where the only thing they really had to have is their specific ones because they have changed SYS files.
The generics fight a battle.
Windows can get information from an INF what can claim that a driver is newer, where the systemfile is actually older or same, or not suitable.
Nobody said it was easy. You guys at least try to help.

I totally agree with you the removals were necessary and need to stay. Yes some were removed that probably needed to stay but for the most part I would bet it did more good then bad. We need to continue to work together when there are problems we need people to post the log files so that fixes can be implemented and then tested and reported back to us. I know the work you have done has helped me and I would like to think the fixes that I have offered to others has helped them. The bottom line is nothing is going to be perfect but if everyone contributes information we can fix a majority of the problems.

Thanks again
Jaak, Overflow, Debugger and the others who have help me in the last month,
dolivas

Sorry guys, I must have appeared very scarce this week. I did get notifications of your replies in my email but had no time to follow up on your reports.
I hope I can work on the pack tomorrow, because I want to apply the fixes.
(The removal of a SiS HWID in a SiS driver must be undone, for instance.)

While software can help making lists, it was not software that made decisions when choices had to be made.
I hope I can fix this by undoing some wrong choices.

I read that there ought to be no removals.
Erm.. removing approx 2000 duplicated HWIDs may seem like an 'overkill' effort, but the pack did not work right when it was not done.
I'll reread your reports tomorrow, and will do what I can so as to have a new test pack available before Sunday.

we can certaily tell if it can decide correctly from the api log

api log can only tell you how they rank drivers (signautaure,date,hwid,capid)
but never beyond those, same hwid setupapi.dll can't detect.

I read some of setupapi.dll's code,they can't do more than hwid.

to:Debugger

In fact ,yesterday i google and no found detail motherboard database.

I think Everest detect that by motherboard id, for example, type in google: nf-ck804-6a61fg0ac-00 (that name shows my motherboard below screen when it detects ram, cpu and hard disks), and you will know what it is Gigabyte K8NF9. More example: 63-122-0000010-00101111-090806-intel-p4i6g122-y2kc means AsRock P4I65G.

To all - if we are could to create a program to detect motherboard id before fake setup, and to create the motherboard id database (or to find it somewhere), we are will to install all problem drivers ideally, each problem driver for each problem motherboard.

Errrrgh, I'm so tired to transform my thougths in English