Re: FindHWIDS v3.2s - The INF Searching, Hardware ID Exporter
Overflow where's that list? In the team section? Well, just let me know if you need anything.
You are not logged in. Please login or register.
Overflow where's that list? In the team section? Well, just let me know if you need anything.
UM no... Sorry LOL i thought you were more familiar with the layout
It's in the 'Feature Requests' forum and it is stickied to boot
Thanks...
v3.1.7 is out
v3.1.7 @ 2008-09-28 5:42pm EST - Adds scan time, files scanned and hwids found to excel and csv output. Moved scanning of certain parts of the INF to produce a faster scan. Changed during scan the FindHWIDs window now minimizes.
v3.1.6 @ 2008-09-28 4:41pm EST - Fixes CSV output to mimic Excel output. Now exports the INF Description (also still outputs the PNPID description)
I have a confirmed bug report for the finisher so give me a minute ...
i still think i can make this play useing the existing bartpe code without much hassle...
v3.2 is out!
v3.2 @ 2008-10-26 11:48pm EST - Created a function to scan for variables within the INF. Reducing bad data (hopefully eliminated). Scan speed is about the same.
v3.1.9.1 @ 2008-10-23 2:19pm EST - Scan time has also been reduced about 20%.
v3.1.9 @ 2008-10-23 11:49pm EST - Fixed flawed logic with strings. Hopefully rebuilding soon with a better way of handling strings. Though this version fixes some missed converting of strings into hwids.
v3.1.8 @ 2008-10-22 6:28pm EST - Adds install as an option (with DPinst.exe 32bit english only, copyright Microsoft), installing only hardware found on machine. Improves on scanning speed. Fixes some strings issue.
Awesome! Thank you.
Np! Those strings are a pain in ass. Found that a "For $element in $aArray" in was faster than counting the array size and using a "For $a =0 to Ubound($aArray)-1". I think this is because I had to first count it. Otherwise it would probably have been as fast.
Last edited by stamandster (2008-10-28 00:24:07)
I think I found a bug in v3.2.
See this post: http://forum.driverpacks.net/viewtopic. … 029#p27029
The HWIDs listed are getting skipped, but the VEN_x&DEV_x&SUBSYS_x strings are getting picked up correctly from what I can tell.
I used both options for CSV and Excel.
Search in Excel for "DEV_5B63" from DriverPack Graphics A and you only find lines with the SUBSYS, not the bare HWID.
I'll look into it. Is it in the latest Graphics pack? A, B?
Thanks!
I'll look into it. Is it in the latest Graphics pack? A, B?
Thanks!
Yes, confirmed with even the latest nightly & release DriverPacks.
If the .inf is structured with the following layout, the DEV_* generics get skipped:
VEN_XXXX&DEV_YYYY&SUBSYS_ZZZZZZZ
VEN_XXXX&DEV_YYYY
If the .inf is structured with the following layout, everything is fine:
VEN_XXXX&DEV_YYYY
VEN_XXXX&DEV_YYYY&SUBSYS_ZZZZZZZ
OverFlow found a possible cause of this bug.
http://forum.driverpacks.net/viewtopic. … 467#p29467
I am a hard core individual... (you may have felt some of that energy)
I would not in good concience slipstream a mass storage controler without first slipstreaming the chipset driver that is its foundation... Others may do this and have success with it... not good enough for me. Do it right or Don't do it... chipset must be included and precede mass "anything less would be uncivilized"
First:
I wondered about where we are with "slipstream a mass storage controler together with the chipset driver that is at its foundation".
Hi,
when 2008 started, our tester base seldom had coder insight explained to them.
There were people willing to share effort, and there were real talents doing their thing, and they all had insights and code we had not yet tapped.
I did not write a 2009 "news" post but, had I done that, it would have been about the major change in our fora users.
People writing about a problem were less frequently seen as "complainers" as they were (more than usual, compared to past) often giving insight about a detail we had to look into.
People doing great things decided to add their time, and served their insights and their solutions on a "silver" platter (aka, Ready to Rock.).
Other users stayed mainly just users, but I think they learned a great deal because a LOT more got in public.
I would like to thank many of them for the coding efforts on supported device screener.
(the driver aka INF reader is part of this effort to get ALL screened, so as to find the big buggers.)
I would still like to see a group effort to axepose (diliberate spelling) the driver writer we expise.
YOUR proof of conflict has not been collected for proof of conflict in any of our topics.
When I personally stuck out my neck at brussels MSFT I had my past work, but only mine.
(work in Excel, later excel 2007.. which, by the way, can be augmented by tools offered by Oksana Matveeva from http://mapilab.com/.)
I see home site of mapilabs does not link of the 'excel'lent tools.
the suite of add-ins is at http://www.office-excel.com/excel-addin … undle.html
FAIK, any sort of INF reader had blind spots.
We still need you to find them.
Thanks for the vote of confidence Jaak!
As it turns out, it seems, that the support code I wrote this application in doesn't support an array value of a certain size and thus crops it. I think that this is the only limitation thus far. Something that I will certainly look into and find a work around so that the blind spots are thus eliminated.
Other than that issue with path size being too big (and I'm assuming windows might not like it either) we've got a fairly good handle on INF's and how they are created/written. I learned how to develop an INF and the dynamics behind it. How to catch for variables and find the correct hardware id's every time no matter how they looked (even though some are truncated as it seems because of the flaws of autoit).
The complete path to the offending INF's would be greatly appreciated in order to sleuth out the issues present.
Last edited by stamandster (2009-02-24 14:11:29)
its not a flaw... it is a known limit lol
If you work for IBM they call that a feature ROFL
erm, in this topic kickarse said he'd take a hint at face value, and leave the 'System class OUT!'
In one of my ramblings I hinted there are dupe HWIDs across different GUI class.
For a datamining tool, I think we have to fully understand the way weighing works.
(I am sure a few of our members know how it works, so I would like to see their imput so I can catch up.)
a super generic in modem sound and sound and videograb cards and graphics (HDMI/sound/TV connector on many) comes to mind.
Where will the GUI class weigh more?
(modem and sound often caused conflict.. Then came along HDMI and this has caused some issues for DriverPack Graphics A/b and sound)
Server drivers for SAS seem to have systemfiles with built in checks. (main sys checks validity of other files.)
Server driver main SYS can apparently also check the legitimacy of a call it gets from a DLL by checking the status of the service key and a wrong status results in error (Lsi_Fc.sys wants "on demand")
I'll use some stuff from another forum.
quote 1
S3 Cd04nwlhsllf;Cd04nwlhsllf; C:\Windows\system32\drivers\lsi_fc.sys [2006-11-02 65640]
Vista Ultimate, which includes that driver, but this one is in use with that odd service name. I can see it is for LSI's Fibre Channel Scsi MiniPort storage of some sort, but why that name? ...quote 2
Set to Manual start, and when it was disabled the guy had a failed bootup, so something relies on it to be on demand.
Where do we want to go?
a fully automated filter and prune?
A helpful tool to assist us in that job?
The raw downloads do force us to compare each time we get a new file (updates aren't, they are sometimes fixes. Fixes drop older. Older and newer drivers may have built-in security checks. They CAN conflict with OEM's proprietary nightmares, and the OEM-nighmare can be newer than the more generic.)
Automated weighing by tool or by human, I think neither can be perfect.
What do you think we do? What is the best thing to do?
erm, in this topic kickarse said he'd take a hint at face value, and leave the 'System class OUT!'
In one of my ramblings I hinted there are dupe HWIDs across different GUI class.
For a datamining tool, I think we have to fully understand the way weighing works.
(I am sure a few of our members know how it works, so I would like to see their imput so I can catch up.)a super generic in modem sound and sound and videograb cards and graphics (HDMI/sound/TV connector on many) comes to mind.
Where will the GUI class weigh more?
(modem and sound often caused conflict.. Then came along HDMI and this has caused some issues for DriverPack Graphics A/b and sound)
...Automated weighing by tool or by human, I think neither can be perfect.
What do you think we do? What is the best thing to do?
As Jeff and I discussed in IM we definitely see the human aspect to never go away with this. Mainly because there are so many variables. However, I do think that giving weight to a driver is a good idea. Something that gives certain drivers precedence and scale. So something to the affect of "driver a is top priority to install, but only if the system is hp coded, else use this driver here". Something like that. However, that's a TON of work.
Or do we only rely on specific manufacturers releases for hardware? Not relying on OEM releases, but the manufacturer release if we can help it? Like Broadcom drivers being released by Broadcom or HP, choose broadcom. That way it's a broader scale. Same thing we do for the likes of intel, nvidia, ati, adaptec.
For driver installation, if my research is correct, I believe the only thing that Windows DLL install method and the Microsoft Driver Installer Framework only work off of version release number, I don't think they even look at the date. So if the version is greater than the driver will be updated. But with the MS driver installer framework you can force a lower version driver to be applied.
Also, do we want to apply more weight (ie. install first) to more generic drivers. Like a hwid for PCI\VEN_XXX instead ahead of PCI\VEN_XXX_DEV_XXX ?
And I said I'd leave System out of the mass storage drivers scan
Last edited by stamandster (2009-02-25 08:16:45)
I just tested (posted this elsewhere) with the latest Graphics A, path D\G\N5\nv4_disp.inf. I didn't miss one HWID in the inf.
Try testing with just the folder or inf file directly to scan instead of a whole the root D.
Also, do you think it'd be a good idea to move this thread to Software?
Last edited by stamandster (2009-02-25 13:08:19)
Try testing with just the folder or inf file directly to scan instead of a whole the root D.
Try scanning the folder d\g\a1 and export to .xls.
Search in Excel for "DEV_5B63" from DriverPack Graphics A and you only find lines with the SUBSYS, not the bare HWID.
This bug still exists when the .inf is structured as so (like ATI):
ven_aaaa&dev_bbbb&subsys_cccccccc
ven_aaaa&dev_bbbb
The resulting .xls will pick up the 18 listings of VEN_1002&DEV_5B63&subsys_cccccccc in CX_75974.inf but will be missing:
"Radeon X300/X550/X1050 Series" = ati2mtag_RV370, PCI\VEN_1002&DEV_5B63
This is just an example, there are loads of dropped HWIDs from the .xls.
testing with my latest now
thanks for the specific bug to look for
brb...
lol DriverPack Graphics A 8.12.1 does not have a CX_75974.inf file... !
After some testing I see what's happening. I think it's the INIReadSection that's doing it.
It's not so much that after PCI\VEN_XXX_DEV_XXX_SUBSYS_XXX that it won't pick up but it stops after a certain amount of read data! It is just a coincidence that it stopped there...
And I quote "Only the first 32767 chars are taken in account in an section due to Win9x compatibility." I can't wait till it's bye bye 9x compatibility!
I'll see what I can find in regards to expanding it so I can get the rest of the data!
...
I found a UDF that will allow reading of all the values. I'll be testing tonight!
Last edited by stamandster (2009-02-26 02:18:19)
After trialing the UDF I am finding that it's capturing all the HWID's. This is great news!!
I specifically tested D\G\A1\CX_72271.inf and it pulled 1006 HWID's, exactly the amount I manually copied and pasted from the INF file. Previously it only pulled 392. An improvement indeed!
I'll be creating a new version of FindHWIDS for testing purposes and try and post it tonight or tomorrow.
Last edited by stamandster (2009-02-26 02:42:26)
Oh thank GOD! I'm looking forward to testing the new tool, even if it means more work for me.
lol DriverPack Graphics A 8.12.1 does not have a CX_75974.inf file... !
LOL, sorry, it's in the nightly.
Always happy to oblige more work for you oh master of thy graphics!
Same here... got it to pull all the hwids for the installer tool too...
I had no idea that this side progect would fix so many issues for everyone!
Sweet!
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.032 seconds, 10 queries executed ]