DriverForge v5.0! - An Automatic Driver Installer

[kickarse]

Release, DriverForge v3.3!

[ideas]

Is it possible to add an attached working file with a folder that consist all the contents in their correct directory?

for example:

contents:

DriverForge v3.2.exe

Drivers uncompressed [folders & sub folders only]

AND

contents:

DriverForge v3.2.exe

Drivers compressed [dummy 7zip files]

then by downloading any of these all we (end users) have to do is to place the compressed or uncompressed drivers where they should be and everything would just work, hands off.....

[kickarse]

Is it possible to add an attached working file with a folder that consist all the contents in their correct directory?

for example:

contents:

DriverForge v3.2.exe

Drivers uncompressed [folders & sub folders only]

AND

contents:

DriverForge v3.2.exe

Drivers compressed [dummy 7zip files]

then by downloading any of these all we (end users) have to do is to place the compressed or uncompressed drivers where they should be and everything would just work, hands off.....

I'll think about it

Oh and v3.5 is out!

Edited January 30, 2008 by kickarse

[kickarse]

v4.0 released!

[ty628659]

it worked very will, I would like to make a suggestion for both "DriveForge", "Post-Install". in many time people have big collection of drivers, it take long time copy, decompress and then install. we can easly knowing from Windows drvices manager what is the missing drivers types，so in your program UI give user option to select those missing drivers folder only, then run the proucess. it realy help to speed-up the total installration time. if people have USB or network Drive with decompress folders UI even can just click and map those missing drivers folder in Registry only. (Saving time to copy, decompress)

I am not good for writting so i drow a little UI in attachment. I hope it can help you

Dear kickarse,

I found out if select "Delete uncompressed drivers" option, it only delete \Drivers folder, but the registry DevicePath remain same even the \Drivers folder no longer in. I thanks it should reset back to windows default driverPath=c:\windows\inf only.

Edited February 22, 2008 by ty628659

[redia]

it worked very will, I would like to make a suggestion for both "DriveForge", "Post-Install". in many time people have big collection of drivers, it take long time copy, decompress and then install. we can easly knowing from Windows drvices manager what is the missing drivers types，so in your program UI give user option to select those missing drivers folder only, then run the proucess. it realy help to speed-up the total installration time. if people have USB or network Drive with decompress folders UI even can just click and map those missing drivers folder in Registry only. (Saving time to copy, decompress)

this is an interesting idea.

the only thing is that it might be difficult for Kickarse to know what each file stands for.

most of us are using driverpacks file.. but I also use my own pack..

and the driverpacks are updated so the filename might end up changing.

Dear kickarse,

I found out if select "Delete uncompressed drivers" option, it only delete \Drivers folder, but the registry DevicePath remain same even the \Drivers folder no longer in. I thanks it should reset back to windows default driverPath=c:\windows\inf only.

about this point you are right.

I am sure Kickarse will modify that.

on my test the devicepath is "c:\windows\inf;c:\drivers\3\mo\a;c:\drivers\3\mo\b...................."

but to be on the safe side the devicepath should not be set to "c:\windows\inf", but %systemroot%\inf (to cover the installation in a different folder), or even better, restore the previous value..

R.

[kickarse]

it worked very will, I would like to make a suggestion for both "DriveForge", "Post-Install". in many time people have big collection of drivers, it take long time copy, decompress and then install. we can easly knowing from Windows drvices manager what is the missing drivers types，so in your program UI give user option to select those missing drivers folder only, then run the proucess. it realy help to speed-up the total installration time. if people have USB or network Drive with decompress folders UI even can just click and map those missing drivers folder in Registry only. (Saving time to copy, decompress)

this is an interesting idea.

the only thing is that it might be difficult for Kickarse to know what each file stands for.

most of us are using driverpacks file.. but I also use my own pack..

and the driverpacks are updated so the filename might end up changing.

Dear kickarse,

I found out if select "Delete uncompressed drivers" option, it only delete \Drivers folder, but the registry DevicePath remain same even the \Drivers folder no longer in. I thanks it should reset back to windows default driverPath=c:\windows\inf only.

about this point you are right.

I am sure Kickarse will modify that.

on my test the devicepath is "c:\windows\inf;c:\drivers\3\mo\a;c:\drivers\3\mo\b...................."

but to be on the safe side the devicepath should not be set to "c:\windows\inf", but %systemroot%\inf (to cover the installation in a different folder), or even better, restore the previous value..

R.

Oh that's a good point about resetting the path. It should grab what the value is initially and then after it's finished it should reset it back. I'll add that.

Ultimately it'd be nice to add the option to scan a directory for compressed files. Show a listing all compressed files. Add an option to select all, de-select all, or select individual packs (like it was at one time but not as flexible as I wanted). But that's a bit in the future, it was planned, but I wanted to get the initial stuff working.

Edited February 22, 2008 by kickarse

[Kingskawn]

I have a sysprep image with drivers integrated but for some pcs it won't install some drivers. I thought I could use this for a post-installation of missing drivers but how can I integrate this in my script? Can it be done like this?

So in my script I put the link for the .exe with a UNC path to the folder where all the drivers are?

[tslug]

This has happened to me on multiple computers when trying Driverforge. It will recognize 2 monitors, and not install drivers for either of them. Then it will also recognize anywhere from 2 to 10 unknown devices. When you plug in a USB thumb drive, it won't be able to find drivers for it. I figured out how to fix this last problem by pointing it to C:\WINDOWS\inf, thanks to previous post. But any idea why these other problems happen? This is on multiple brands, laptop and desktop, about 30% of the time. Right now I'm looking at a laptop where the device manager lists 3 (Three) LGPhilips DVD burners with yellow question marks, plus 2 unknown devices underneath. There's only one drive, of course. Fixing these driver errors takes much more time than just downloading the correct drivers from the OEM site in the first place, but this program has so much potential to make my life wonderful!

Thanks for your work so far! I definitely second replacing the driver location to %SYSTEMROOT%/inf so that future devices can plug and play.

[redia]

I have a sysprep image with drivers integrated but for some pcs it won't install some drivers. I thought I could use this for a post-installation of missing drivers but how can I integrate this in my script? Can it be done like this?

So in my script I put the link for the .exe with a UNC path to the folder where all the drivers are?

This has happened to me on multiple computers when trying Driverforge. It will recognize 2 monitors, and not install drivers for either of them. Then it will also recognize anywhere from 2 to 10 unknown devices. When you plug in a USB thumb drive, it won't be able to find drivers for it. I figured out how to fix this last problem by pointing it to C:\WINDOWS\inf, thanks to previous post. But any idea why these other problems happen? This is on multiple brands, laptop and desktop, about 30% of the time. Right now I'm looking at a laptop where the device manager lists 3 (Three) LGPhilips DVD burners with yellow question marks, plus 2 unknown devices underneath. There's only one drive, of course. Fixing these driver errors takes much more time than just downloading the correct drivers from the OEM site in the first place, but this program has so much potential to make my life wonderful!

Thanks for your work so far! I definitely second replacing the driver location to %SYSTEMROOT%/inf so that future devices can plug and play.

Tslug,

are you using sysprep ? or are you deleting the drivers folders ?

Kingskawn,

are you deleting the drivers, or are they accessed through the network before sysprepping ?

the issue here is very "simple" or at least straightforward

when running the sysprep all the drivers are "cleaned" and when restarting the computer it goes through a discovery phase.

most of the drivers would work, but unfortunately due to the way the driver inf are built sometimes some leftover are included in the registry pointing to the "uncompressed" driver files.

I have face this type of issue. and it has nothing to do with driverforge.

my way of dealing with that is as follow :

after driverforge running (and I do not delete the drivers in the program) I run a script that I did build:

- it simply check (using devcon) for the existence of specific hardware that I have tested to create this problem,

- copy the drivers in a local directory

- modify the registry accordingly to make sure next time it will look for the correct location

- delete the uncompressed driver folders.

this way I minimize the amount of drivers kept locally on the computer, and through this I minimize the size of the image.

how do I find the problematic drivers ? well simply by testing. so the first computer of a type that I create brings up the errors...

afterword it is easy to deal with.

how hard does it go.. well it ends up being pretty fast, and you will notice that very often it is the same drivers that are creating problems, in my case solving 1 network driver solved the issue for 4 different type of computer.

I am looking into a more systemic solution that we could use in coordination with driverforge :

a pre-script that would delete all the unneeded folder, thus by simply choosing not to delete the drivers after running driverforge we should not face the problem again.

but I have to really dig into that as it really depends on the way the drivers are structured.

if I end up finding any constructive way to do it I will share my findings with kickarse so we could see whether he want to include it in his soft or prefers to keep it outside. do not expect any update in a short period of time as I have a ton of things to do first.

anyway if anyone need help on how to manually do it, or want a copy of my script let me know, it is a first step...

Cheers,

R.

[tslug]

Tslug,

are you using sysprep ? or are you deleting the drivers folders ?

Not using sysprep, using Driveforge, not deleting the drivers folder, either. Source is USB or CD, destination is folder at root of local system drive. Today I found that by modifying the registry back to the %systemroot%\INF folder, then restarting, then rediscovering hardware after removing the yellow exclamation points, it discovered them correctly. I don't know why, it seems like DriveForge maybe installed drivers for the monitor that didn't work correctly, then the default INF just made it a plug and play monitor, maybe, and that was better or something. Also, IDK why driverforge leaving the default driver folder to the uncompressed drivers means that it can't recognize things as simple as a USB key w/o changing it back to the INF folder.

Anyway, I can't really give the computer back to a client w/o switching the registry back to the INF folder, so that'll be cool when that tweak is done, IMO.

[redia]

Tslug,

are you using sysprep ? or are you deleting the drivers folders ?

Not using sysprep, using Driveforge, not deleting the drivers folder, either. Source is USB or CD, destination is folder at root of local system drive. Today I found that by modifying the registry back to the %systemroot%\INF folder, then restarting, then rediscovering hardware after removing the yellow exclamation points, it discovered them correctly. I don't know why, it seems like DriveForge maybe installed drivers for the monitor that didn't work correctly, then the default INF just made it a plug and play monitor, maybe, and that was better or something. Also, IDK why driverforge leaving the default driver folder to the uncompressed drivers means that it can't recognize things as simple as a USB key w/o changing it back to the INF folder.

Anyway, I can't really give the computer back to a client w/o switching the registry back to the INF folder, so that'll be cool when that tweak is done, IMO.

tslug,

which version of driverforge are you using ?

kickarse is already working on solving the devicepath issue, so he will probably release it very soon. but if I am not mistaken he is also adding a couple of new improvement which could explain that the version has not been released yet.

until then you can simply script the modification in the registry

i.e.

save devicepath status

run driverforge

restore devicepath

I advise you to save/restore because in most of the cases you will have %systemroot%\inf but in some rare cases the device path might already contain different values.. so save/restore covers all cases

Cheers,

R.

[kickarse]

Tslug,

are you using sysprep ? or are you deleting the drivers folders ?

Not using sysprep, using Driveforge, not deleting the drivers folder, either. Source is USB or CD, destination is folder at root of local system drive. Today I found that by modifying the registry back to the %systemroot%\INF folder, then restarting, then rediscovering hardware after removing the yellow exclamation points, it discovered them correctly. I don't know why, it seems like DriveForge maybe installed drivers for the monitor that didn't work correctly, then the default INF just made it a plug and play monitor, maybe, and that was better or something. Also, IDK why driverforge leaving the default driver folder to the uncompressed drivers means that it can't recognize things as simple as a USB key w/o changing it back to the INF folder.

Anyway, I can't really give the computer back to a client w/o switching the registry back to the INF folder, so that'll be cool when that tweak is done, IMO.

tslug,

which version of driverforge are you using ?

kickarse is already working on solving the devicepath issue, so he will probably release it very soon. but if I am not mistaken he is also adding a couple of new improvement which could explain that the version has not been released yet.

until then you can simply script the modification in the registry

i.e.

save devicepath status

run driverforge

restore devicepath

I advise you to save/restore because in most of the cases you will have %systemroot%\inf but in some rare cases the device path might already contain different values.. so save/restore covers all cases

Cheers,

R.

I'm definitely almost finished. I've been on hiatus, bought a house, so I've been and am quite busy at the moment. But it'll be out soon

[Kingskawn]

Hi

I've got an unattented installation sysprepped machine. The thing I want to do is at the end of the installation procedure call the .inf that will do a last hardware installation. This have to be automatic without any user interaction.

I already made an .inf. I don't know if it's correct but I looked on the 'manual'. Can you tell me if I'm correct?

I will work with the Driverpacks that are in 7z format and it must delete drivers when it finishes.

[AutoInstall]
UnAttended=Y
AutoCheck7zLoc=N
DeleteUncompressedDrivers=Y
RestartMachine=N
ShowDevMgr=N
VerySilent=Y
Sleep_at_Start=1

[Driver]
7zRoot=N
7zRootLoc=C:\temp\compressed <--- folder where the 7z's from Driverpacks are
DriverRoot=N  <--- doesn't really understand the meaning of this
DriverRootLoc=C:\Windows\Drv <--- Folder that already exists and where I've put several drivers
DriverExtract=C:\Windows\driverforge <--- Location where driverpacks will be uncompressed
7zLoc=C:\temp\compressed <--- folder where the 7z's from Driverpacks are
Use_System_Root_INF=N

[Misc]
CheckForWizardTitle=Found New Hardware Wizard <--- can add some more, things that are new
Delete_Existing_Driver_Log=N

Will that autorun.inf executes at the end of a script or do I need an .exe?

Edited March 11, 2008 by Kingskawn

[Kingskawn]

Kickarse or anybody?