Drivers added with WinToolKit marked in blue and other another question?

[oguz]

Hi Legolash2o,

I have two questions:

1- Win8, Server and Vista driver folders in the driverpacks on driverpacks.net site are deleted and "Win7 and ALL" drivers are left (x86 and x64 are taken into consideration).

When these drivers are added with Wintoolkit, some drivers (many of them) are marked in blue area!

A- What do these drivers in the blue area mean? Why does Wintoolkit mark many drivers with blue?

B- When adding drivers with wintoolkit, does it recognize drivers that are the same and choose one automatically?

2- Assume that VC Redlist Installer 1.5.0 in McRip was installed previously. Then, if a software with an older version Visual C++ files (such as "Asus ATKacpi driver and hot key utilities") are installed, does Windows change these older version VC files with the newer ones?

Or does it keep newer VC++ files and does not recognize the older ones?

Edited February 10, 2013 by oguz

[Mr_Smartepants]

1A: Drivers marked in blue are duplicates.

Please post a list of duplicated drivers over at DriverPacks.net so you can help us clean them up.

[oguz]

1A: Drivers marked in blue are duplicates.

Please post a list of duplicated drivers over at DriverPacks.net so you can help us clean them up.

Ok, I'll do it. Thanks for the reply.

I have a question: is it correct to add drivers in both "Win7 and ALL" folders while adding a driver to Win7?

I have this question because many of the drivers in ALL folder that is mentioned to be compatible with Win 6.1 unfortunately do not exist in Win7 folder. There are very few drivers in Win7 folder. This is why it needs to add both ALL+ Win7 folders.

In short, could it be because both folders are added that so many duplicate drivers warning (blue area) are given?

Edited February 10, 2013 by oguz

[Mr_Smartepants]

Well, in short, the drivers in the Win7 folder are there because they support ONLY Win7, or Win7/Server2008r2. 

Drivers only go in the "All" folder if they support all the OS variants (Vista/Win7/Win8/Server).  If a driver supports 1 or 2 but not all, then we duplicate the drivers in the folders that they support.

 

Yes, it's good practice to keep the "All" folder and the OS-specific folder and delete the others.

But DISM is smart about driver injection and it will skip drivers if it detects that they are already duplicated in the image.

 

Incidentally, the folder reorganization was a result of this rant by RicaNeaga.

http://www.wincert.net/forum/topic/9267-video-driver-not-instaled/#entry80564

Edited February 10, 2013 by Mr_Smartepants

[compstuff]

I don't know how I never saw that post when it was out there :-)

. 

Incidentally, the folder reorganization was a result of this rant by RicaNeaga.

http://www.wincert.net/forum/topic/9267-video-driver-not-instaled/#entry80564

[oguz]

Well, in short, the drivers in the Win7 folder are there because they support ONLY Win7, or Win7/Server2008r2.

Drivers only go in the "All" folder if they support all the OS variants (Vista/Win7/Win8/Server). If a driver supports 1 or 2 but not all, then we duplicate the drivers in the folders that they support.

Yes, it's good practice to keep the "All" folder and the OS-specific folder and delete the others.

But DISM is smart about driver injection and it will skip drivers if it detects that they are already duplicated in the image.

Incidentally, the folder reorganization was a result of this rant by RicaNeaga.

http://www.wincert.net/forum/topic/9267-video-driver-not-instaled/#entry80564

Thank you for the detailed explanation. This is the answer I expected.

When you say "deleting", do you mean deleting duplicate drivers in the blue area manually in WinToolKit? (When both ALL and Win7 folders are added at the same time)

Edited February 10, 2013 by oguz

[Mr_Smartepants]

Well you could do that.  I meant delete the other folders "Vista" "Server", etc.

Duplicated drivers will not cause problems.

[Legolash2o]

Hi Legolash2o,

I have two questions:

1- Win8, Server and Vista driver folders in the driverpacks on driverpacks.net site are deleted and "Win7 and ALL" drivers are left (x86 and x64 are taken into consideration).

When these drivers are added with Wintoolkit, some drivers (many of them) are marked in blue area!

A- What do these drivers in the blue area mean? Why does Wintoolkit mark many drivers with blue?

B- When adding drivers with wintoolkit, does it recognize drivers that are the same and choose one automatically?

2- Assume that VC Redlist Installer 1.5.0 in McRip was installed previously. Then, if a software with an older version Visual C++ files (such as "Asus ATKacpi driver and hot key utilities") are installed, does Windows change these older version VC files with the newer ones?

Or does it keep newer VC++ files and does not recognize the older ones?

 

1. Blue means the inf file has the same MD5 hash as a previously added item.

 

A- Explained above.

 

B- Nope

 

2. No idea, never tried. Is it an addon or what? Mostly likely keeps the newer ones.

[oguz]

1. Blue means the inf file has the same MD5 hash as a previously added item.

A- Explained above.

B- Nope

2. No idea, never tried. Is it an addon or what? Mostly likely keeps the newer ones.

Ok.

Does deleting drivers in the blue area with WinToolkit one by one manually cause reduction in the number of integrated total drivers?

Does this deleting process cause any problem? (I got an answer to the question, but I wanted to have confirmation from the program developer)

Edited February 11, 2013 by oguz

[Legolash2o]

Naturally there is less in the less so yes it will cause reduction in total drivers.

 

Nope, no reason it should.

[oguz]

Naturally there is less in the less so yes it will cause reduction in total drivers.

 

Nope, no reason it should.

Ok. Here is my last question:

Do you suggest to leave the drivers marked in blue and integrate them? Or do you recommend to delete all drivers in blue area and then integrate?

Which one is better and which one does not cause reduction in the number of drivers?

[yogurt]

When I integrate driverpacks into a Win 7 SP1 (7601) x64 I delete the Win 7 Folders When an All folder is present in the pack. I also delete all non-relevant OS folders.

 

The All folders contains drivers for all nt6.x Operating Systems so I tend to integrate those and delete the Vista, Win7, Win8 and server folders. The effect is that I end up with NO duplicates and a relatively minimal set of drivers with no unnecessary clutter.  The only time I might consider a driver from another folder is when It has a newer version number than the duplicate found in the All folder -- This, however is seldom the case.

[oguz]

When I integrate driverpacks into a Win 7 SP1 (7601) x64 I delete the Win 7 Folders When an All folder is present in the pack. I also delete all non-relevant OS folders.

 

The All folders contains drivers for all nt6.x Operating Systems so I tend to integrate those and delete the Vista, Win7, Win8 and server folders. The effect is that I end up with NO duplicates and a relatively minimal set of drivers with no unnecessary clutter.  The only time I might consider a driver from another folder is when It has a newer version number than the duplicate found in the All folder -- This, however is seldom the case.

It is logical.

However, the problem is that there are newer drivers that are in Win7 folder but not in ALL folder. Because of this, the use of ALL and Win7 folders together provides both up to date and the highest number of drivers.

But, I think the biggest problem at this point is duplicate drivers. I think there is no solution to this problem?

[yogurt]

Do you suggest to leave the drivers marked in blue and integrate them? Or do you recommend to delete all drivers in blue area and then integrate?

Which one is better and which one does not cause reduction in the number of drivers?

 

I personally don't integrate drivers that have the same MD5 Hash (Drivers Marked in Blue). The reason I don't integrate them, is because they are duplicates. Also If my memory serves, I believe DISM will ignore them. I takes me about 2 minutes to clean up a driver pack of it's duplicates and recompile a Custom Driver Pack with no duplicates. Just my 2 cents on the subject.

Edited February 12, 2013 by dotfusion

[oguz]

I personally don't integrate drivers that have the same MD5 Hash (Drivers Marked in Blue). The reason I don't integrate them, is because they are duplicates. Also If my memory serves, I believe DISM will ignore them. I takes me about 2 minutes to clean up a driver pack of it's duplicates and recompile a Custom Driver Pack with no duplicates. Just my 2 cents on the subject.

Is there a program you use when cleaning the duplicate Files from the packages.

As you know, there are many sub folders in packages. How can you find duplicate files in them in 2 minutes? I think you do not delete all duplicate files. You leave one of them in the folder (for installing the driver to the system) Am I correct?

Finally, is not deleting all drivers in the blue area the same with the your method? Deleting all drivers under WintoolKit seems to be easier,  practical and SAFER method. 

What do you think?

Edited February 12, 2013 by oguz

[compstuff]

I am holding off commenting too much on this because I am about to re-visit my driver integration method but I also use WIN7 and ALL in the driverpacks and delete duplicates and recompile. I would also like to know your method of doing this DotFusion to see if we are similar.

[yogurt]

For the process of cleaning up my DriiverPacks I use two file utilities. Both of which are portable, lightweight and require no installation

 

1. Duplicate File Finder (to find and delete duplicate driver files)

2. Remove Empty Directories (RED) (to delete any empty folders resulting from step 1)

 

Example Scenario -- For this example I'll use 'DP_Chipset_wnt6-x64_1212' from DriverPacks. It's a good example because it contains quite a few duplicates. 164 duplicates are found in this pack to be exact.

 

The first thing I do is unpack the driver package somewhere on my hard drive maintaining the original folder structure.

 

The second thing I do is run 'Duplicate File Finder' to find duplicates on the folder where I unpacked the DriverPack.

 

As you can see from the screen shots Duplicate File Finder found 164 files that have a duplicate (Size 14mb) all with the same MD5 Hash.

 

The next step is to simply tell Duplicate File Finder to Select all duplicates and delete them. Optionally with the file utility you can choose to copy the dups or move them elsewhere. I choose to delete. Done! No more duplicates.

 

[sCREEN SHOT REMOVED] -- I need the online space for other stuff. Sorry

 

The last step is to run 'Remove Empty Directories' as shown is the screen shot below. As you can see 'RED' found 45 empty folders in the DriverPack.

 

Now hit the Delete Folders Button and your done. As you can see WinToolkit shows no duplicates and anything left in the Win7 and vista folders are drivers that were not found in the ALL folder. This process shouldn't take an avid user no more than two minutes.

 

[sCREEN SHOT REMOVED] -- I need the online space for other stuff. Sorry

 

Update: I just want to bring something to your attention that I've only just realized before you try my method. Mr_Smartepants and mooms have pointed out to me that It may be wise to remove non-releavant OS folders first, prior to scanning for duplicates. You will also have to check for Incomplete folders as well. The reasons can be clearly seen in posts #20, #22, and #23.

Edited February 17, 2013 by dotfusion

[compstuff]

DotFusion... love the tools our logic and methodology was the same but yours seems really slick... I am trying it with my next set thanks

[yogurt]

@compstuff

 

Let me know how you make out.

[Mr_Smartepants]

@DotFusion, it looks like when you did your scan you didn't remove the other OS folders before the scan.  We duplicate some drivers between the OS folders in the packs intentionally.

When I get some time (maybe) this weekend I'll try your method on each OS folder on its own (not the whole pack).

[bphlpt]

As you know, there are many sub folders in packages. How can you find duplicate files in them in 2 minutes? I think you do not delete all duplicate files. You leave one of them in the folder (for installing the driver to the system) Am I correct?

 

Yes, all duplicate file finder programs normal operation is to only delete the extra copies of the file, and will leave one copy in place.

 

Cheers and Regards

[yogurt]

@DotFusion, it looks like when you did your scan you didn't remove the other OS folders before the scan.  We duplicate some drivers between the OS folders in the packs intentionally.

When I get some time (maybe) this weekend I'll try your method on each OS folder on its own (not the whole pack).

 

You make an excellent point. Any duplicates found in the other OS folders that are deleted will most likely break that folders specific driver in the sense that they will not install properly because of the now missing driver file. Further as mooms has pointed out that the same applies for other drivers found in 01, 02, 03, etc...Thanks Mr. Smartepants for pointing this out.

Edited February 13, 2013 by dotfusion

[mooms]

I think it is dangerous to delete duplicate files, because sometimes they are (or seems at least) necessary.

I have tested DFF in DP_LAN_wnt6-x64_1208 after deleting others OS folders (left Win7 and All): it found some duplicated files in some folders, but the others files in the same folders are not duplicates ! (they are indeed same files but belongs to another "sets" of drivers)

So if we delete one each of the files, we are left with "incompletes" folders and I think the drivers can't be installed.

 

I don't know if it's clear, rather see the image to understand what I'm saying:

 

 

[yogurt]

Thanks for pointing this out. I'll be revising my method to remove non-relevant folders prior to scanning for duplicates with Duplicate File Finder. I think the left over incomplete folders could also be deleted because the one remaining would satisfy the now defunct incomplete. 

Edited February 13, 2013 by dotfusion

[yogurt]

DotFusion... love the tools our logic and methodology was the same but yours seems really slick... I am trying it with my next set thanks

 

I just want to bring something to your attention that I've only just realized before you try my method. Mr_Smartepants and mooms have pointed out to me that It may be wise to remove non-releavant OS folders first, prior to scanning for duplicates. You will also have to check for Incomplete folders as well. The reasons can be clearly seen in posts #20, #22, and #23.

Edited February 13, 2013 by dotfusion