Added to 11.01r1
I22\ SigmaTel High Definition Audio (Gateway MX6454/m465-e) DriverVer=06/15/2006,5.10.5082.0

1,602

(1 replies, posted in DriverPack Sound)

Updated to newer version: X24\ Conexant "Pebble" High Definition Audio (Lenovo T410/T510/X201) DriverVer = 10/20/2010, 3.66.147.0

1,603

(7 replies, posted in DriverPack Sound)

Sorry I'm late to this party.
Added to DP_Sound_B_wnt5_x86-32_1101r1\D\S\S40\

1,604

(4 replies, posted in DriverPack Sound)

Added to the latest test build DriverPack Sound B\D\S\I22

1,605

(6 replies, posted in DriverPack Sound)

This should be fixed in the upcoming release of DriverPack Sound A.
Commented the HWID from \D\S\R1\Alcxau.inf

mrivenbark wrote:

#W025 A newer file "C:\WINDOWS\system32\drivers\smwdm.sys" was overwritten by an older (signed) file. Version of source file: 5.12.1.3555. Version of target file: 5.12.1.7000. The existing target file was not signed.

Your problem is caused by a file that is contained in DriverPack Sound B.  The version that is supposed to work is 5.12.01.7000 contained in DriverPack Sound B\D\S\S10\smwdmCH5.inf (also older 5.12.01.5246 in DriverPack Sound B\D\S\S21\smwdmCH5.inf) but it is not working on your hardware.
Can you delete the folder DriverPack Sound B\D\S\S10 and try again?  The older folder S21 should be replaced, but it was left behind for compatibility.  If S10 is broken, I'll remove the duplicated HWIDs from S10 to fix it.

1,607

(353 replies, posted in Software)

OK this is strange.  Now v3.2m is giving me an 'array size' error.  Doesn't matter which driver folder I select (large/small) or if I run the utility as admin or normal user.  Restarts don't help either.
http://i51.tinypic.com/2afd5xf.png

The resulting .csv file is 239kb in size and contains 623 lines.
The only difference is that I recently upgraded to Office 2010 (from 2007).  But that shouldn't matter because the .csv is created even if Office is not installed right?
Environment: Win7 x64 Pro.  8GB RAM

*Edit.
Download links are down in first post.

*Edit 2
Nevermind.  It's working now on a different pack.  I think there's a bug here somewhere because it's crashing on a Realtek .inf.  I'll report back with more info later
Yup.  This one .inf contains over 4360 HWID lines!  Removing that one .inf from the folder allows the scan to complete successfully.  Holy Crap!  >4000 HWIDs in a single .inf!  What were realtek thinking?!?
The file is HDALC.inf taken from the new R2.57 XP HDaudio drivers

Moved thread and renamed to show correct problem.

Confirmed.  The torrent file download links are not working.  Wim changed some of the site code to fix one other problem and now this crops up.
Thanks for reporting.

hunterpl wrote:

i just added AHCI Drivers for txtmode thats all that not mean driverpacks will be broken...

YES IT WILL!  You're not listening.  If you use Nlite for drivers then you cannot use DriverPacks.  You can't use both in the same disc.
Because you've added drivers with nlite, IF you want to help us test the nvidia mass storage drivers you must start over with a clean XP, slipstream SP3, integrate any updates THEN you can start testing.  The test source must have zero added drivers or the test build will be compromised.

OK, in my tests with the new DriverPack Graphics A build on my desktop, a normal integrated install works flawlessly.  When installed with an ATI card, then switching to an Nvidia card you get the familiar "found new hardware wizard".  SAD fails to install the nvidia drivers AT ALL.  Nothing, zippo, nada.  Even multiple attempts gain nothing.  The SAD command file runs OK, DPINST does it's thing (even installs drivers for hardware that was already installed) but my Nvidia card fails.  We've had this problem before, and I don't know why it does it.  Going through the device manager and updating drivers using the "have disk" method works perfectly fine (PhysX isn't loaded though).

So does this mean that you won't be helping us test nvidia drivers?
I was holding back the dpms release because I was hoping to fix one more nvidia bug with your help.  I guess not.
Nlite is years old and is no longer developed.  Although it makes the needed registry hive fixes during driver integration and works fine for adding a handful of specific drivers; but if you use nlite to add drivers and then use DriverPacks BASE to add DriverPacks, then your resulting build will be broken.

Helmi wrote:
OverFlow wrote:

wouldn't the client still seed even if the folder were redirected???

AFAIK, yes.
When I manually DL the DP torrents, I usually directly let them be placed into the respective sub-dir of the DP folder - disregarding the default save path that I have set in µtorrent.
It still gets seeded until I manually delete it out of the program's list.

Wow really?  So I've been doing it wrong this whole time? big_smile
I guess I'll have to change how I seed these things.  I don't mess with the default utorrent settings (other than port forwarding on the router)

Still an excellent idea!

zawakened wrote:

Is there some kind of news? Maybe it will be Graphics A 10.11.1 repack?

Well I'm already working on new graphics DriverPacks but not to address this issue.  It only affects SAD installs, not normal installs.  Maybe I'll toy with adding another DriverPacks Finisher exception to the .ini.  Similar to what's required now with PhysX.

Temp link to dpms v1101r1: http://www.mediafire.com/file/8dpksaggs … _1101r1.7z

That is a good idea Rick, but I still think that having the torrent client download to whatever default folder all the other torrents go to is beneficial because then the torrent could still be seeded to the rest of the world.  The user would only need to copy the completed packs to the DriverPacks BASE folders.

Good to know.  I'll keep an eye out for those.  Typically I just copy the new drivers over the top of the old drivers, let the files get replaced, then check for duplicate HWIDs.
Now I'll have to create a test folder with all the Intel drivers, add the new ones to their own folder, scan for HWIDs and see what got missed. neutral

1,617

(7 replies, posted in Site & Forum Issues And Feedback)

Probably not.  We don't update all the DriverPacks at the same time. 
We'll take your idea under advisement though.
Welcome to DriverPacks! smile

1,618

(48 replies, posted in DriverPack LAN)

If you can package up all the required files and upload to a site like mediafire, I might be able to add them to the pack.

Yeah, the problem you were having was not with the chipset drivers but with the mass storage drivers (AHCI or RAID).  Updating your BIOS also updated the motherboard RAID controller firmware (which helps). 
But we still need to know WHICH nvidia driver works best on each hardware ID.  Your sister's computer is a perfect candidate for these tests.
So, if you can, please configure your motherboard BIOS for either RAID *OR* AHCI, then test all the packs in the other post (18 tests) and report which packs work, and which fail. 
The results of your tests may help us fix the dpms currently in release candidate phase! smile
Thank you!

Yes, nvidia drivers are a real pain! smile
Would you be able to test the packs in this post and report back please?
We really need testers with nvidia hardware.

Yes, nvidia drivers are a real pain! smile
Would you be able to test the packs in this post and report back please?
We really need testers with nvidia hardware.

1,622

(3 replies, posted in Other)

Correct.  I can't download it either.  Our admin will need to fix that.

That's the wrong DPs_BASE.log.  That's the log file from when you created a SAD disc, no drivers were integrated into your XP disc on that run.
You'll have to look through the log files in \DPs_BASE\LogFiles\ and select the one that has the line:

2011-01-22 14:47:35 : <SEL>  Selected module: mod_slip_wxp_x86-32_disc_m2.

...and we're STILL waiting for you to post your HWIDs using the tool linked in my signature.

1,624

(19 replies, posted in DriverPack Graphics)

OK thanks.  I'll get to work on this.  Would you be able to test the result once I get it uploaded?

tstaddon wrote:

DNS resolves fine to the sites even if I don't auth to the proxy server or firewall. To actually browse the sites I need to client auth to the firewall or go through the proxy server. When I get the chance, I'll look into that further but based on your comment that might be a good place for me to start.

That's actually a valid point.  And something that I can test as well.
My site has nearly a 1000 users.  We also use an AD network (biometric Common Access Card-CAC logins) with GPO using Security Groups.  Anyone logging in with any elevated privileges other than "user" gets denied access to the proxy server.  So admins can have access to the shared network drives, but denied access to the outside world.  Pings and Traceroutes to common sites DO work (sometimes), but no traffic is allowed. 

I'll smuggle in a copy of DriverPacks BASE and test in both user and admin access on our network tomorrow and report back.
We're in the middle of upgrading all our Vista workstations to Win7 (finally!) so even if I blow it up, I'll just wipe it and install Win7 fresh. wink

tstaddon wrote:

And they have to maintain STRICT build standards. Since the apps are all QA'd to the Nth degree the main headache for them moving forward, is going to be the ever-changing availability of the exact same hardware to go with their standard build. Because every time they have to load a new set of drivers, THAT is a month of change control. What they really want is a universal install image, with a preset bundle of drivers that will DEFINITELY work, regardless of the hardware, that has a specfic set of Windows Updates, doesn't update automatically, has specific applications, and is then locked down so it cannot be modified except by explicit, authorized means.

That is the opportunity I'm talking about. If Driver packs can be validated ONCE then these industries and clients will save themselves THOUSANDS of hours of expensive change control. They would probably be willing to pay for it.

Ah, there's the problem.  I've had this argument with our administrators the the nth degree.  With DriverPacks, there are no absolutes.
It's greatest strength is also it's greatest weakness.
DriverPacks is a community project.  Yes, we have a small number of core developers and a larger group of testers BUT (and here's the kicker) we cannot guarantee 100% "chain of custody" of the drivers.
I can personally vouch for about 90% of the drivers that are directly sourced from the OEM vendors themselves, but lots of hands have been in these cookie jars.  It's these unknowns that scare away the organizations that require the utmost security.  That saddens me.

I built the LAN-RIS Third Party DriverPack myself and I can guarantee that ALL the drivers were directly sourced from the vendors BUT only roughly half of them are digitally signed.

I wrote:

System admins should always strive to use digitally signed drivers as a matter of course, but these are not always available.  You must utilize whatever information risk management processes your organization encourages.

And this is the main reason that my organization refuses to use DriverPacks.  They insist on gathering the drivers themselves.  Ah well.