DriverGrabber 1.0 RC1 - One Click Driver Backup

[ProfessorCPU]

DriverGrabber 1.0 RC4 - One Click Driver Backup

DriverGrabber 1.0 RC4 - One Click Driver Backup

I have finally gotten around to updating one of my older programs. This version of DriverGrabber should be working on both x86 and x64 systems.

It grabs all of your drivers from your system and places them into a Drivers folder for you.

Please help test this. I want to make sure any bugs are ironed out before I release the final version.

DriverGrabber is 100% Free!

http://professorcpu.net/Data/DriverGrabber.zip
MD5 Hash: A60C385847E4E0484C154CDB8B6E1A14

If you find any bugs... or if you have any requests please post them here.

Thanks!
Professor CPU


Update:
1.0 RC4:
Fixed duplicate backups of some drivers.

1.0 RC3:
Fixed broken x86 Compatability.

1.0 RC2:
Updated - Better handling of main inf and cat files.
May have an issue with x86 compatability.... will look into fixing it quickly for RC3.

 

[jimbojambo]

Look forward to it. Let u know how it goes

 

[buzzcut]

Thanks! Will try it out for sure and let you know.

 

[crashtech]

Is there any documentation available? I can't get it to work yet.

 

[ProfessorCPU]

Is there any documentation available? I can't get it to work yet.

Not much of a manual needed for it. It's very simple. You just double click the exe and it will gather all of your (non microsoft) drivers into a Drivers folder right next to your DriverGrabber.exe

If it did not create a Drivers folder for you there may be some sort of bug I have missed. What version of windows are you running on your system?

Also... could you post the contents of your DriverGrabber.log file?

 

[crashtech]

It appears to run briefly, then terminates with no message. Here's the entire contents of the log, nothing much to see:

;- Log Started 05/27/2012 - 23:24:10
;- WIN_7 Service Pack 1 X86 System Found.
;- Computer name is: JON-PC
;- X86 Devcon being used.

[Logged Errors]

[Grabbed Drivers]

[Skipped Drivers]

 

[ProfessorCPU]

It appears to run briefly, then terminates with no message. Here's the entire contents of the log, nothing much to see:

;- Log Started 05/27/2012 - 23:24:10
;- WIN_7 Service Pack 1 X86 System Found.
;- Computer name is: JON-PC
;- X86 Devcon being used.

[Logged Errors]

[Grabbed Drivers]

[Skipped Drivers]

Hmmm... I wonder if I somehow broke x86 functionality?

I'll look into it. Thanks for reporting! I'll try to get ahold of an x86 machine tomorrow to test it on.

Thanks!!

 

[ProfessorCPU]

I just released 1.0 RC3... please re-download and test again. It should now work on both x86 and x64.

 

[neil]

Just run it on a Win 7 Professional 32bit system and it seems to have caught everything I would expect. Let me know if you'd like the log file.

Neil

 

[crashtech]

Works good on my old T60 now, though it did create five identical copies of the USB driver! Better too much than not enough I suppose!

 

[ProfessorCPU]

Works good on my old T60 now, though it did create five identical copies of the USB driver! Better too much than not enough I suppose!

Can you possibly zip up the 5 identical driver backups for me? As well as your drivergrabber.log ?

I knew this would happen... but I did not have this issue on any of my test systems. So maybe with your help I can narrow down a way to prevent multiple backups of the same driver.

Thanks!

 

[crashtech]

You have a PM.

Also, I ought to mention it works fine on all the other machines I have run it on, which all happen to be Win7 x64. The only problem has been with my old T60 Win7 x86 system.

 

[FoolishTech]

I'm interested in your project. I have a few suggestions and something to point out.

1. I noticed in your log file it mentions DEVCON ... if this is referring to the Microsoft command line utility devcon.exe, you are aware that this is not legal to distribute with your apps. I didn't it extract, but I didn't bother to check if you were extracting and running it from a temp dir or not.

2. If you are NOT using devcon.exe, nor are you using the Win32_PnPEntity WMI class, and are getting the info directly from the registry and then from the INF files, then I have a feature request that would be possible using your methods. Make it work on OFFLINE Windows partitions. I can provide help and we can collaborate on this if needed. It would be no thing for me to give you the ability to programmatically load and scan offline registry hives if you needed...

3. If you are willing to work on #2, then my next suggestion is to provide command line parameter support for pointing the offline driver backup to the appropriate Windows partition/dir.

Looking forward to your response.

 

[ProfessorCPU]

Yeah for now it is currently using devcon... I've been working on a method to do the same without devcon though. I have a few ideas... And the final idea for drivergrabber is exactly as you requested. I do wish to make it compatible with offline systems / PE disks. If you'd like to help I am definitely up for it.

Thanks for the interest!

I also have a backup utility I created years ago that I never released online. But I don't intend to release it until it has driver backup capabilities.

Commandline options would defiantly be useful for many reasons.

I'm interested in your project. I have a few suggestions and something to point out.

1. I noticed in your log file it mentions DEVCON ... if this is referring to the Microsoft command line utility devcon.exe, you are aware that this is not legal to distribute with your apps. I didn't it extract, but I didn't bother to check if you were extracting and running it from a temp dir or not.

2. If you are NOT using devcon.exe, nor are you using the Win32_PnPEntity WMI class, and are getting the info directly from the registry and then from the INF files, then I have a feature request that would be possible using your methods. Make it work on OFFLINE Windows partitions. I can provide help and we can collaborate on this if needed. It would be no thing for me to give you the ability to programmatically load and scan offline registry hives if you needed...

3. If you are willing to work on #2, then my next suggestion is to provide command line parameter support for pointing the offline driver backup to the appropriate Windows partition/dir.

Looking forward to your response.

 

[ProfessorCPU]

1.0 RC4 is uploaded.

It fixes an issue with duplicate backups being made for some drivers.

 

[Xander]

Does 1.0 RC4 no longer use Microsoft's devcon.exe? Otherwise, you're still illegally distributing it.

 

[crashtech]

From what I understand, it's legal to use the sources of devcon, tweak them and recompile them with a different name.

 

[FoolishTech]

If you'd like to help I am definitely up for it.

Well, it's a matter of getting your app to work off of the registry instead of devcon.

I actually set out to do this myself recently and got overwhelmed.

I was thinking to query HKLM\SYSTEM\CurrentControlSet\Enum subkeys for the Driver value, which would translate to a subkey of HKLM\SYSTEM\CurrentControlSet\Control\Class where I could query the InfPath value.

From there I have the INF, which I could query it for the [Version] \ CatalogFile= to get the .CAT file and the [SourceDisksFiles] section for the other files, and brute search/pull those files from either \system32 or \system32\drivers.

If you can get the registry method down, I can help you to load offline registry hives in order to query them instead of the live registry. We probably program in different languages (I only do VB6 and I'd be surprised if that is what you use) so it may be easiest for me to just compile and give you a tiny simple command line utility to load offline registry hives. I can give that to you and let your app run it, suppling the path to the hive. e.g. LoadRegHive.exe e:\windows\system32\config\system (e:\ being the offline partition) Then when you are done, you can call it again with the "unload" parameter to unload the hive: e.g. LoadRegHive.exe unload

This idea being to load the SYSTEM hive under HKLM\guest_SYSTEM so in effect to work with offline partitions you would only need to change your code to HKLM\guest_SYSTEM\CurrentControlSet\Enum and so on and so forth. In my own D7 code I set a variable dependent on whether I am working with an offline partition or not. So my queries go to HKLM\VARIABLE\CurrentControlSet\Enum where VARIABLE is either SYSTEM or guest_SYSTEM depending on whether I'm in offline mode or not. This way I don't have to write different code for my different functions.

In fact, it was easy enough to just do, so I've compiled and attached LoadRegHive.exe to this message for your use. Let me know if there is anything I can do to help further, (if by some chance you program in VB6 I can help with reading reg values, and such) and keep me updated with your progress regardless!

**Also note on systems with UAC enabled you must be running as administrator for LoadRegHive.exe to work. I noticed your app doesn't force a UAC prompt, but if you will be reading certain reg keys you may require admin access. I can also help with you forcing your app to spring the UAC prompt if you need help with that. It is a simple matter of embedding a manifest file inside the EXE, which I use Resource Hacker for. Let me know if you need the details and I'll be glad to help!

 

[ProfessorCPU]

Thanks FoolishTech. It sounds like you and I have done pretty much the same research! LOL! So it would seem we are both on the same track. It started out making DriverGrabber a few years ago with devcon... just because it was easier to put something together. But I soon realized that I could never use it in a pre-installation environment. So it makes DriverGrabber limited in what it's capabilities could be. I haven't had time to code much in the past couple of years.... so it's just sit on the shelf. To my suprise it was still a pretty popular download online. Getting a couple hundred downloads per month to this day. So this past weekend.... I had some time and decided to update it. I think I'll quickly finish v1.0 Final soon. So that I can work on v2.0 without devcon.

Thanks for the (much needed) inspiration to get back into coding. I was burned out for a while... but I've wanted to get back into coding once again. Back when XP was the main OS I was coding all kinds of helpful utilities... but when Vista and Windows 7 took over I kind of slowed down on the coding front.

 

[ProfessorCPU]

Good news! v2.0 is underway. I had time to work on it throughout the majority of the day today. DriverGrabber has undergone a complete re-write and now does not use Devcon. I haven't finished implementing offline os scanning for drivers yet... but it works in a live windows environment. Implementing the offline portion of the code will be the easy part. I also need to make a few more tests on some other systems before I post anything online for v2.0.