Search options (Page 105 of 159)

No.
in DriverPack Graphics A\N1\nv4_go.inf move all of the listed hwids from [NVIDIA_Devices.NT.6.0] header to the main listing under [NVIDIA_Devices] header.
I have it fixed here in the final.

*Edit
Ah, crap.  nv4_go.inf has a bigger typo than I first thought.  It needs a rewrite to work with the new drivers.
I'll have it spotless for 9.12 final.

I'm trying to figure out what you're doing with the above code.  If you're building an .inf, then you're syntax is all wrong I think.
You're using the following directory strings in [SourceDisksFiles] but not declared in [WinntDirectories]: 2, 4, 20, 21.  'a' is declared, but improperly I think.
Any time you have [SourceDisksFiles] it must be matched with both [SourceDisksNames] and [DestinationDirs].

The syntax you're using implies a .sif file but even txtsetup.sif uses a different layout.
Each comma position defines an exact location.  An example:
[SourceDisksFiles]
_default.pif = 1,,,,,,,1,2,0

Also, I don't think [WinntDirectories] ever contains commas.  Dir\subdir are always contained in quotes.

If you could just do a straight integration with DriverPacks BASE to a standard XP build we can determine if the driver itself is working or not or if your ubcd4win config is screwed.

Right.
But it's the DriverPacks Finisher that installs all of them.  Not SAD. Although SAD does run a second instance of DriverPacks Finisher.
If you have the runtime Third Party DriverPack present in the %cdrom%\oem\ folder then it will be extracted along with the other DriverPacks and the installers will be made available to the DriverPacks Finisher.
Otherwise, you'd be better off removing the runtimes Third Party DriverPack and integrating .net and vc using either T-13 or ROE.

OK, I understand your frustration.  But I have zero experience with ubcd4win so I really cannot help you there.
What I was hoping was that you would do a standard integration (no ubcd4win) so we could determine if it was a DriverPacks fail or ubcd4win fail.
I'll have to remove those beta .inf files while I process the graphics DriverPacks for final status.  We'll work on this problem in the nightlies where all the cutting-edge stuff happens.

Our mantra is "Stability before currency".  And the graphics DriverPacks are more stable now than they've ever been!

OK, I've never used UBCD4Win or BartPE but your log tells me that something got screwed along the way.  Why would DriverPacks BASE take the time to .cab compress the packs (wrong DriverPack Graphics C too) then set the install method to 2?
DPsMethod    = "2"
:?
Try again with a fresh source (with updates, addons, etc.), then use DriverPacks BASE to integrate using no graphics DriverPacks except the rc I linked above.
Then if it fails again, I'll need to see the following.
DPs_BASE.log
DPsFnshr.log (from %windir%)
setup***.log (from %windir%)

All I did with the test pack above was add the .infs from the beta you linked to DriverPack Graphics C\N3 (175.16).  It should work, but I need to see the logs to see why it doesn't.
Thanks for testing.

Welcome to DriverPacks!

What makes you think you can't request drivers?
If you don't ask, you don't get!

The link you provided is for older beta drivers.  The latest WHQL (our favorite) nvidia notebook drivers are 186.81 and are listed here.
But you're absolutely correct.  over 99% of the HWIDs listed in those notebook drivers are not included in our DriverPacks.  I take responsibility for that.  I'm sorry to have left those out.
But in order to add these, I will have to break driver-signing for these notebook drivers.  This is because Nvidia intentionally introduced a fault to prevent driver integration (you saw this firsthand.)
Without modifying the .inf, you'll get a filecopy error around T-34 for NvCplSetup***.exe.

I can add these and they won't interfere with the current drivers.
I'll be providing a link for you to test.  You feel up to the challenge?

See, that wasn't so bad was it?  We don't bite (very often).

LOL, I had made is so easy for you too!  Just look under my avatar/IP address.

For the .infs, I'll have a look and let you know.  I'm not at home at the moment.

The arch filtering doesn't always work.  Selecting x86 will let some AMD64 items through.  But the .inf writers don't make it easy do they?

You're right!
I just did a test in VM and forced the CCC install with the switches used and had an error popup just before it restarted the system.
It did only partially install, then failed.  Maybe switching to the DriverPack Graphics A (newer) CCC will work.
I have a laptop that uses this folder.
Investigating...

Glad to be of service Sir!
Let us all know how it goes.

If you take the runtime Third Party DriverPack apart, you'll see in the DriverPacks Finisher .ini that I used %SystemRoot%\system32\atidemgx.dll as a trigger file (tagfile).  This means that the runtimes will NOT install unless a compatible ATI card is present.  Because these runtimes are only required by CCC, there's no point for DriverPacks Finisher to install them when they're not needed.
If you want to make the .NET/VC installers default, then delete the atidemgx.dll line and adjust the .ini tagfile count as necessary.

Welcome to DriverPacks.
Take a look at the tutorial linked in my signature.  It's old, but will point you in the right direction.