I had to edit my reply because my english is sorta always turning out like Flemish.
I blame it on my Flemishness.
What kills signing?
There are many factors, and the code aware/driver aware geeks (regulars) at DriverPacks know a good many few of those and have helped work around the pitiful situation hardware vendor driver writers have put all of YOU in.
Driver writer teams apparently take an existing "model" (based on an still older guideline.) and most often just ADD their HWID to the INF, while the core system level driver is also changed.
They rewrite core system of driver because the chip combo they want to support has another mask..
Also when it was proprietary re-manufactored to their company needs.
I know there are system file differences written for the purpose of adding cross-checks in system file, so that a new HWID added SOMETIMES means nothing more than that the HWID was added -embedded-checked- IN the system file.
ALSO NOTE; in CPU fabrication one knows stepping. A stepping is done by re-etching part of the mask, but a new "stepping" of a CPU does not require rewrite of system level driver (an internal optimisation, as it were).
A proprietary build is not a stepping, it is truly a different chip when the code has to allow other interoperability function for the new HWID this mask gets.
(Hence, the often VERY diffuse line between driver upgrade/new driver.)
The new driver for the new chip was often written with a lot of the old info.. and they left old INFo in the INF.

The default HWID is then not "truly" supported.
Often times, the old default "hwid" no longer works with THEIR new SYS file.
MSFT claims Vista has over 2.5 million drivers.
XP, well, I don't know.
OUR problem is that a HWID does not make a driver, but a driver can break a HWID supported by an older driver.
take an example.
a driver supplied by gigabyte motherboard.
157 HWID on a type of controller. (that's mass, chipset)
The controller chip vendor, default HWID for that type, have 23.
DriverPack MassStorage, if only lists 23, gets numerous requests to add non supported, and if (IF..) when we are lucky we find that the HWIDS were all supported by same core system file.
Great, we take the driver with 157, and do not have to break signing.
Dream on.
Same motherboard vendor has at least 18 versions of drivers on the CD.
Some have overlap, some have poison overlap.
Poison overlap happens when a newer driver portends (pretends?) to support a HWID left in from the 'boilerplate" txt the driver writer worked on while writing the new driver.
The sad fact was/is that because the manufactors have a driver tested against THAT motherboard, it works.
OK, maybe it was good enough for that mobo..
BUT, the damn thing bluescreens on its contemporary siblings, and on its 'fore-fathers'.
And, sometimes that driver Bluescreens on its new mask, or in a new combo (combo of reliable chip with another chip.)
hah, 2.5 million drivers.
a gazzillion HWIDs
NO true database on masks, on core incompatibilities, on cross-chip conflicts a new mask had to fix.
You know, If I were not with my heart for DriverPacks, I'd given up a long time.
Last edited by Jaak (2008-12-07 16:24:51)
The answer was 42?
Kind regards, Jaak.