Drivers Instalation in Post-Install stage (New Method)

[MadBoy]

This must be disabled check sertificied drivers

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

0 - enable WFP/SFC

1 - disable WFP/SFC to next reebot, ask to enable

2 - disable WFP/SFC to next reebot

4 - disable WFP/SFC, off all massage

FFFFFF9D - full disable WFP/SFC.

Well i am not sure this will work. From my WFP and SFC are diffrentthings then unsigned drivers.

And im fink need one correct program.

Programm registred to many not needed inf files (if yousing diriver pack 20-100)

But installing 1-10 device. (im fink need filter to device ID for install only needed inf files)

Well why are you using Method SetupCopyOemInf then? That's what it does. It implements every inf it finds into Windows drivers dir. Of course this could be changed by either preparing packs for each computer by hand. Otherwise it's a lot of work for program to do it. If you want drivers just for devices you have installed use RegistryDevicePath method which will only put drivers that need to be put and will skip the rest. Those are 2 diffrent methods and you should be the one to choose which one suits you the best.

[kickarse]

The WFP fix also doesn't work with SP2 anymore...

[bingothepyro]

Hi,

This is a great utility if you are able to run from a drive letter, but not if you want to run from a UNC path.

I have tried using

Drivers_drive=RELATIVE

Drivers_dir=\D

where \D is the drivers folder, but get this error:

Path specified in config file doesn't exist (\:\D). Terminating!

Also, If I have the following structure C:\Temp\hardware.exe and C:\Temp\D and run hardware with any Drivers_Drive option, I get the following error:

Path specified in config file doesn't exist (C:\D). Terminating!

This would show that this neat app is coded ONLY for drive letters, and that the RELATIVE option is not actually relative to the location of the exe file, but simply picks up the current drive letter.

Please can this be changed so it will work from unc paths and the RELATIVE option actually is relative(to where the exe is run from), and does not just pick up the current drive letter?

Many Thanks

Tim

[MadBoy]

Drivers_drive - possible options are CDROM or REMOVABLE or RELATIVE or simple drive letter. When CDROM is used program will try to detect drive letters for them and with Drivers_dir it will make sure the dir exists. Same thing happens when REMOVABLE variable is used. By removable i mean all devices that are plugged in to computer and are easy removable, for example USB sticks and things like that. Best for testing purposes or fast access. At least in my case. Recently added option in 0.6.8 - RELATIVE means the program will use the drive letter from where the program was started. This way you don't have to set HardDrive letter permamently in .ini file. Remember thou that Drivers_Dir still is required to be set correctly, as the program only takes drive letter and ignores the full path to hardware.exe.

As mentioned on first post this is normal behaviour for it. Just set Drivers_dir=\TEMP\D and everythign will be fine. I did it this way because CDROM or REMOVABLE always reports driveletter only, same when you use drive letter manually. To make it work diffrent for Relative i would have to do a lot of code workarounds and change stuff in many many places. That's why it's done this way. Also it might give ppl some confusion if once it will be only drive letter and the other time relative path. Besides as it's states Drivers_drive is Drivers Drive

As for the UNCPATH's i'll see what i can do

[Guest Ashanti00]

Hi,

i think this is a very useful tool!

But i still have a question about the methods:

Method - possible options are RegistryDevicePath and SetupCopyOemInf. First one sets path in registry. Second one uses DLLCALL that is suggested by Microsoft as solution to include drivers. It does DLLCALL for each .inf it finds. That file is copied to C:\Windows\System32\Drivers dir and the path where the driver is located is modified for each .inf. Windows then knows where to look for that specific driver. This method can be very usefull especially for ppl that want to include only few drivers (as the more drivers you have, longer it takes to include them), or that are having problems with RegistryDevicePath. Also the SetupCopyOemInf method is kinda permament. So if you choose to integrate all .inf's, the path stays there so Windows always look for drivers in that dir. It can be usefull with option Copy_drivers to leave it on your harddrive for later use. By the way - RegistryDevicePath has 4096 char length max so watch out. Should be enough for most ppl. The question which method to choose is up to you.

You wrote that the second method "SetupCopyOemInf" copies the files to C:\Windows\System32\Drivers dir.

Will there be copied all drivers to "System32\Drivers", which i have in the drivers direction (Drivers_dir) or only the "removed unknown devices" which were found?

Because i want to make a DVD with all the driverpacks (unpacked) from Bashrat (driverpacks.net).

I only want to install the driver for the "removed unknown devices". Nothing else (no integration)

But when i use the "RegistryDevicePath"-Method, the following failure is shown:

- Setting path into registry using RegistryDevicePath method.

- Device Path in registry currently has 8999. Maximum path is 4096 characters.

- It is suggested, that if Device Path is longer then 4000 characters you should use SetupCopyOemInf method.

- If you don't want to do so you can cut some dirnames so those will be shorter, cutting down the number of characters overall.

I'm from Germany, so sorry for my bad English.

Thanks a lot for help.

[geo411m]

excellent tool. i used this tool Here with BTS driver packs and your tool on a single cd and it worked fine but driver detection took a long time (15mins). is there anything we can do to speed it up or is compressing the drivers too much for it?

[MadBoy]

@Ashanti00

- as for the SetupCopyOemInf method unfortunetly it copies all the .inf files into directory so it's very painfull. I have a PLAN for every method to support only those nessecary but that requires going thru .inf files. So i was thinking about some little tool to create pre-db so that kind of information can be cached instead of looking at it at instalation time.

- anyways i wouldn't worry about the 4000 chars limit too much. On your place i would test it if it works without problems first on RegistryPath method as i think it just ignores the limit realy. I've put it there just in case but i have tested it several times and it seems to just work fine. Especially that the number of chars in actual registry path is READ from registry so it is there Test that method and you should be okey.

@geo411m

- well it depends if you have used the packed drivers with .7zip or you unpacked them first. If you used packed drivers then it's normal for 7zip to take longer time to unpack those as they are heavily packed. If you have unpacked them before and the process is still taking long time then you should keep in mind that what actually windows does is going thru all .inf files and comparing them to device that's missing the drivers, and you have like 3GB of drivers! That is supposed to take time. You can do 2 things:

1. Limit the number of drivers in it (like keep one dir per few PC/Notebook models)

2. Use all drivers option only for realy bad cases when you are unsure what drivers are missing and it would take you longer to do it manually then doing it with my little proggy.

Actually the solution for both of you is the pre-db of drivers .inf files and corresponding HW-ID to them. That would heavily speed up the process if i would create program that creates little db (simple file would do i guess) and that program should be run after you prepare your cd/flashdrive or drivers directory. Then my program wouldn't have to go thru all directories and add them to registry or copy using the other method but would actually just use the file to compare what Windows realy wants and put only 'right' stuff. It would save a lot of time i guess.

That's in my PLAN for future addition to my proggy. Just i am preety much busy at work latly as i got too many things on my head. Right now i am in UK on delegation trying to takeover builds work from UK team so we can do it cheaper in Poland That's why the late answer aswell!

Also my motivation on developing this proggy further running preety low

@bingothepyro

I was thinking a bit more about your request for UNCPATHS and i am not sure registrydevicemethod supports those. I haven't tested it but i see quite few problems. Especially when you are missing network card drivers Anyway temp solution for you is to write simple .bat script that would map unc path to some drive and then start my proggy using that drive and use that. This should be preety simple and fast solution. Maybe not that cute as built in feature of my proggy but it will do the job. If you won't be able to fix the .bat file yourself i can write the .bat file for you i guess.

[geo411m]

thanks Madboy. i use BTS drivers uncompressed and i run the driver compress tool which compresses in cab from 1.4gigs to around 500+MBs. i've been using your tool on a usb drive with fantastic results. i use all the drivers from BTS cause it's useful during computer repair, not having to go online for drivers.

thanks again...

[MadBoy]

thanks Madboy. i use BTS drivers uncompressed and i run the driver compress tool which compresses in cab from 1.4gigs to around 500+MBs. i've been using your tool on a usb drive with fantastic results. i use all the drivers from BTS cause it's useful during computer repair, not having to go online for drivers.

thanks again...

Have you tried to use them without compresing them? Could you compare both methods? Compressed vs Uncompressed? And what's the time of each.

[geo411m]

thanks Madboy. i use BTS drivers uncompressed and i run the driver compress tool which compresses in cab from 1.4gigs to around 500+MBs. i've been using your tool on a usb drive with fantastic results. i use all the drivers from BTS cause it's useful during computer repair, not having to go online for drivers.

thanks again...

Have you tried to use them without compresing them? Could you compare both methods? Compressed vs Uncompressed? And what's the time of each.

uncompressed takes like 2 mins compressed like 10-15 maybe more.

[MadBoy]

uncompressed takes like 2 mins compressed like 10-15 maybe more.

Hey, as you noticed yourself the diffrence is huge and mostly depends on speed of computer and how the drivers are packed and not realy on my program. Solution to that is to get bigger Usb stick to keep drivers unpacked

Anyway having them 'cached' in my program would speed it up even more

Edited April 27, 2007 by MadBoy

[geo411m]

Hey, as you noticed yourself the diffrence is huge and mostly depends on speed of computer and how the drivers are packed and not realy on my program. Solution to that is to get bigger Usb stick to keep drivers unpacked

Anyway having them 'cached' in my program would speed it up even more

thats what i been doing and it works well. thanks...

[oldo]

Any chance of a logfilepath setting?

Lovely program, appreciate the hard work!!

[MadBoy]

Any chance of a logfilepath setting?

Lovely program, appreciate the hard work!!

Currently program tries to write file to same folder as the program starts from. If it can't do that (like on CD) it writes it to C:\

I can prolly implement it but what options would you like to see? As in where would you like to put the log file? Gimme some justification please ?

[oldo]

Thanks for the quick response

My unattended setup connects to the network at runoncex and runs the rest of the setup from there (so i can modify the vast majority of the setup process centrally). Currently all of my apps are installed from packages located on the server, and i would like to do the same with drivers All logging is sent to %systemdrive%\maint\log\ on the client machine, but at present this is not possible with your app - i could only log to either the root of C:\, or to the network directory in which the program is running.. i'd like to keep things consistant and output to the same directory as my other log files. Being able to customize the name of the logfile would also be nice!

Again, thanks for the great amount of work you've obviously put into this!

Chris

Edited May 17, 2007 by oldo