Search options (Page 11 of 14)

v3.1.1 is out and fixes the sysprep to be only scsiadapter, hdc. Also the hardware/os filter is corrected.

Just pm me your AIM im

I see... so there's not real rhyme or reason except through trial and error. You guys haven't found any links of why this happens??

Well the reason I asked was because I created my tool to not only work with Driverpacks but any set of drivers. The driverpacks were my inspiration, most definitely. I can create a separate tool or function to parse the mass storage ini and input that data instead of an inf file scan type that would normally have to be done for regular no driverpacks drivers.

So in it's most basic form it will do an INIReadSectionNames to an array and for each array it'll read the ms_count and then read each ms_X_hwids as X is the count number.  The string will be stringsplit by comma. It'll grab the from rootdir together with the section name for the folder location. A dash will signify a subfolder, which a stringreplace can be used. However, I don't know how you choose the inf name. Is that from ms_1_tag with just an .inf added on? I'd probably throw a if fileexists to check if the person actually has that file for no errors.

Also, why do you split W2k3 and XP? From what I've found the drivers make no delineation between XP and 2003. However they do between 2000 and XP/2003 and Vista/2008. 2000 is only NT.5.0. XP can be either NT.5.1 (release), NT.5.2 (sp1 and later) and 2003 can be NT.5.2 only. No extension tells it that it can be used on all machines 98 and later. The architecture split is .nt for all 2000 and later machines. .ntx86 for all x86 machines 2000 and later. .ntamd64 for x64 machines XP/2003 and later and .ntia64 for Itanium machines XP/2003 and later. NT.6.0 is for Vista/2008 drivers, they are hal independent.

However, exclude from select can also exclude certain things from certain OS versions and processor arch types, too. So it might be wise to look into that as well.

v3.1 out with change log on first post.

Just curious of anyones thoughts on using System class for sysprep.inf imports. Currently FindHWIDS imports SCSIAdapter, HDC and System just the same as sysprep -bmsd does for machine.inf, mshdc.inf, scsi.inf, and pnpscsi.inf (inf's that I know of). But I'm curious if I should just use SCSIAdapter and HDC for the additions and leave off the System class.

My system currently pulls this (with filtering for hardware on) for the latest/nightlies - So I'd get rid of every one of them except PCI\VEN_8086&DEV_266F

PCI\VEN_8086&DEV_2580="C:\D\C\I1\915.inf" ; System - Intel(R) 915G/P/GV/GL/PL/910GE/GL Processor to I/O Controller - 2580
PCI\VEN_8086&DEV_244E="C:\D\C\I1\ich4core.inf" ; System - Intel(R) 82801DB PCI Bridge - 244E
PCI\VEN_8086&DEV_2640="C:\D\C\I1\ich6core.inf" ; System - Intel(R) 82801FB LPC Interface Controller - 2640
PCI\VEN_8086&DEV_2660="C:\D\C\I1\ich6core.inf" ; System - Intel(R) 82801FB/FBM PCI Express Root Port - 2660
PCI\VEN_8086&DEV_2662="C:\D\C\I1\ich6core.inf" ; System - Intel(R) 82801FB/FBM PCI Express Root Port - 2662
PCI\VEN_8086&DEV_266F="C:\D\C\I1\ich6ide.inf" ; hdc - Intel(R) 82801FB/FBM Ultra ATA Storage Controllers - 266F

Btw, I could always add functionality to the program to NOT add certain hwids and/or classes.

v3.0.9 is out! A little different, more back end stuff that changed... Check first post for change log.

From what I can tell, yes there is a 4096 char limit for the sysprep.inf line OemPNPDriversPath. However it doesn't seem that the registry has this limitation. That's why for all my images I import the driver paths into the registry instead of using OemPNPDriversPath.

I'm working on v3.0.8 now... some nice new features and fixes.

Ahh I'll have to figure out a way to make it so that doesn't happen... thanks for testing!

v3.0.5 is out! Have fun!

For what I am certain about is that my program parses every HWID that's available in all INFs that are usable by windows. I'm fairly positive it doesn't miss a single one (although I was wrong before about that).

The exports via excel and csv will show every HWID and accompanying information (which I could expand upon if you want the ClassGUID or split the version and date, etc) even duplicates that occur from different INF files with the same HWID in them. I see what you mean though. It'd be nice if the program could tell you if the duplicate HWIDs are newer than the ones you imported earlier in the scan. And you could "zoom" in to see what other HWIDs are in the same file and compare the HWID that exist in the files that duplicate. It might trim the packs down a bit.

The sysprep export is fool proof because it'll only update the HWID from the last scanned INF, meaning no duplicates. It has to be that way in order to not screw up the sysprep processes (which I found out the hard way with the first versions of FindHWIDS).

I can add those extra filters in too, if need be. That way you can hone in on any specific driver. I forgot to mention in the new version not only can you input a PNP ID type but you can type a whole or partial PNP ID (HWID) string and it will try and find that PNP ID string, starting from left to right.

<--- lol, I turned into a Driverpacks Wizard!

The INF files will only show three types of "OS" which in my code is setup as shown below.

Select
Case $aINFRead_Signature = "$Windows NT$"
	$aINFRead_Signature = "NT Based OS"
											
Case $aINFRead_Signature = "$Windows 95$"
	$aINFRead_Signature = "Windows 9x/ME"
											
Case $aINFRead_Signature = "$Chicago$"
	$aINFRead_Signature = "All Windows OS"

EndSelect

Wow, so glad you've done your homework on that. I forgot that the Driverpacks Base does this already, lol! Maybe I should just give up in that respects.

Jaak, thanks for the compliments! I've gained so much help and insight from using Driverpacks that I feel it's my duty and privilege to give back to the community and team. I really do hope this tool can help you guys with tracking down HWIDS and keeping drivers from blowing things up.

I think I might add the ability to export to txtsetup.sif (gathering information from the txtsetup.oem). But I'll have to find out how to do that first. Shouldn't be too hard though, right?

ed. this may help http://support.microsoft.com/?kbid=288344 and this http://www.osronline.com/ddkx/install/txtsetup_1wmq.htm

The next additions should be adding filters for OS types and Architecture types. Then I'll be adding an INI file for settings, for stuff like auto running, etc.

Sweet! You rock Helmi, well the whole team rocks