Search options (Page 119 of 159)

by name and by nature.

Ask and you shall receive

Yep, that HWID is covered by DriverPack Graphics A\A1\mobility.inf and if you were using one of the 903n nightlies you might have run into the bug SamLab reported a few days ago.  I fixed it in DriverPack Graphics A 903n3 posted yesterday.
If you could try that nightly here I'd appreciate the extra test to verify I fixed the problem.
Thanks, and welcome to DriverPacks!

Yeah, that would work too.  Thanks!

Welcome to DriverPacks.
Please read this post before you post again: http://forum.driverpacks.net/viewtopic.php?pid=4#p4
You didn't tell us anything we need to know to help you.

LOL, Yeah, I spotted that after I ran it again.  It is faster.  Sorry...
THANK YOU!!!
This tool is awesome!  I can't imagine working with these DriverPacks without it.

OK, it's always possible that there is nothing wrong with Vista-tool or the vista DriverPacks themselves...the drivers themselves maybe at fault here.
@Fragbert, which folder exactly are you deleting to make these work?
Has anyone used kickarse's HWID tool to scan these DriverPacks yet?  Something is triggering this control panel install from within Vista.  It's a shame we don't have proper log files to investigate.
I'd prefer to eliminate any possible alternatives before resorting to finger-pointing (which never solves anything anyway)

*Edit
so far I found duplicates between:
Dell SAS * Controller
\Masstorage_x64_903.2\10\5\lsi_sas.inf
\Masstorage_x64_903.2\11\1\lsi_sas.inf

LSI Logic MegaRAID SAS PCI Express ROMB
\Masstorage_x64_903.2\10\3\oemsetup.inf
\Masstorage_x64_903.2\10\4\oemsetup.inf

ATI 436E Serial ATA Controller
\Masstorage_x64_903.2\5\2\1\SI3112.inf
\Masstorage_x64_903.2\5\2\3\1\SI3112r.inf

Silicon Image's Pseudo Processor Device  (prime suspect)
\Masstorage_x64_903.2\5\4\2\sippd.inf  (9/20/2006) Delete .inf
\Masstorage_x64_903.2\5\5\2\sippd.inf  (9/17/2008) Keep
\Masstorage_x64_903.2\5\6\1\sippd.inf  (11/13/2007) Delete .inf

I'm not overly concerned with HWID dupes from two .infs from the the same OEM folder (like \Masstorage_x64_903.2\2\2\...massive overlap!), but in the case of overlapping HWIDs from different vendors, we cannot prune the .infs because that would break driver signing. 
Maybe deleting the offending .inf or folder is the best way forward until we can disable driver signing issues.
I'd rather have stable drivers than more drivers.

Note to all.
We DriverPacks builders are few.  But we cannot bugtest on all hardware.
We NEED testers.  It's a symbiotic relationship.

Damn Muiz, you beat me to it again!  I need to quit working so I can devote more time to DriverPacks!

Or drinking...but that's my vice...

Well, I also removed the move...'to'.

If it helps, here's the batch code I wrote to determine the source files installation directory for my oemscan addon.  It should work for disc-based or RIS-based installs.
The below code will find the drive letter/path to the source and declare it as the string %dospath%.

:PATH
setLocal EnableDelayedExpansion

for /f "tokens=* delims= " %%a in (%systemroot%\system32\$WINNT$.INF) do (
echo %%a | find "dospath=" > nul
if not errorlevel 1 set str=%%a
)
for /f "tokens=2 delims==" %%a in ('echo !str!') do (
SET dospath=%%a
echo dospath=!dospath!
)

You could leave the OEM folder in your RIS image and just point presetup.cmd to %dospath%\OEM
Just a thought...