Automatic cleaning of old drivers, or squeeze a bit of space from Windows 7
One fine (or sad, someone like) day I got tired of the place on my laptop periodically running out. Yes, I know that hard drives are cheap now, but this is not an option for me, because:
This topic, perhaps, is intended and can be useful to those people who care about the free space on the system drive, the usual cleaning tools have already been tried, and I want to squeeze out a little more (as in the old joke - the first link in the Google joke that tells bad - sorry).
In general, I sometimes clean the disk space. Standard procedures are cleaning% TEMP%, cleaning the disk (erasing all the error reports there, stuck on the system for every fireman, all kinds of memory dumps of fallen processes, etc.), removing more unnecessary programs.
However, as I found out, there are folders that no one cleans (from the word at all). Well, in the sense of the standard tools. And now I want to talk about the folder% WINDIR% \ System32 \ DriverStore.
If you have this folder occupies a lot, a lot of space, and reluctance to read the whole post - please come to the very end, there are links to github, where you can get the finished result of my research and try to squeeze (or squeeze) some space from Windows.
Introduction to the problem - what is this folder, why is it needed,
If you rummage through the Internet , you can find that this is the place where the system caches all the drivers that it has ever been on the way. Yes, and those that were installed for your video card three years ago also lie there, despite the fact that you updated them yourself many, many times.
')
I will result a little theory from that MSDN:
In my free translation, you get something like:
It looks scary for climbing with your dirty hands, isn't it? However, there is a small (and not very convenient) straw from Microsoft, it is called pnputil.exe and it can:
Moreover, during removal, it checks whether the driver being deleted is currently being used for any connected device, and without the / f option (ie / force - force it), it refuses to delete such drivers.
I used this utility.
I’m not to mention that I’m not the first one so smart who thought about this problem, there is a GUI application for the DriverStore Explorer on the codeplex, but it is actually only a graphical wrapper around pnputil and doesn’t analyze the driver in any way, giving complete freedom to its user.
First of all, I didn’t really want to find outdated versions of drivers manually, and secondly, I wanted to understand that I would gain by removing one or another driver (in the sense of disk space).So there was NIH syndrome in full growth.
So I picked up Pythonand it started .
With a close look, I found that in order to find the most recent version, there is enough data from pnputil, but not to determine the size, because pnputil about the driver says something like the following: who did, when, the version and the name of the INF file. Which of the heap of folders in the DriverStore refers to this driver - it does not say.
Looking more closely at the% WINDIR% \ Inf daddy, I found there those same .INF files (by name) that pnputil lists, and looking in the folders in the DriverStore, I found there ... the same .INF files, but with different names - each in a folder of its driver.
Surely there is a simpler way, but I went to the forehead - built a display on behalf of the .INF file in the pnputil output to a folder in the DriverStore, which has the same contents of the .INF file (with a different name). And I took the size of this folder for the size of the driver.
Now it was up to the small thing - to wrap all this in scripts for convenient execution.
On the way, however, lay a setup in the form of UAC - pnputil worked only with administrator rights, which means it was necessary to raise the privileges from Python. A quick googling gave a few recipes that said something like “you can do this, but the output (and even less input) will not be how you will be debugged - without a clue,” and it did not suit me, so I did a little bit examples
True, my implementation is not perfect at the moment - it will fall when I try to redirect stdout or stderr, because inside I use the Windows concept of the console, but for redirected threads this does not work ...
But for the time being, I have closed my eyes to this, because to fix this a little more complicated mechanism is needed than the FreeConsole / AttachConsole call, i.e. to redirect all threads manually.
And now, in fact, the most gusto - the results of all this footballer text. You can take, use at your own risk, you can try to do good and benefit the source code (MIT license, yes). You can even tell me thanks in the comments, if someone can help these scripts :)
Release on github'e
If you download the binary version (the interpreter is wired inside), take the one that corresponds to the bitness of the operating system (the 32-bit version on the 64-bit OS will not find pnputil and work, respectively, will not ... if you really need to - write, you can try to get around it).
If you take the scripted version - the same way, you need to run the interpreter with the bitness of the operating system.
I personally checked it on two computers with Windows 7, in theory it should work on Vista and 8. On WinXP it should be (sort of) useless.
The script will analyze the driver repository, try to find outdated versions of the drivers (i.e., those for which a newer version is in staging at the same time) and offer to remove them by issuing an estimate of the place occupied by the drivers (and the win estimate, of course, also).
Personally, I managed to squeeze out about 6 gigabytes (!), Mainly due to the removal of older versions of NVidia video cards.
On another laptop, everything turned out to be not so rosy, I managed to clear only 200 (in my opinion) megabytes, but there the system lived significantly less than mine and simply did not have time to accumulate a lot of drivers.
Both laptops have since lived a full life, in the sense of any problems from cleaning, I did not notice.
It was expected that it turned out that cleaning scripts do not always work, the main problem is if Windows is not English-speaking (somehow I did not think that the utility utilities would be localized).I will fix it. Most of the problems should be fixed, see release 1.0.1
In addition, for Windows 8 cleaning scripts, apparently, are not relevant, as Skywrtr rightly points out in his comments .
- I have an SSD, but it will still be more expensive than regular HDDs (my current SSD is 120 gigs)
- The laptop is working, respectively, the data on it, too, must be encrypted, all that, so the self-made and not approved by the employer carrier should not be stuck
I'm greedy :)
This topic, perhaps, is intended and can be useful to those people who care about the free space on the system drive, the usual cleaning tools have already been tried, and I want to squeeze out a little more (as in the old joke - the first link in the Google joke that tells bad - sorry).
In general, I sometimes clean the disk space. Standard procedures are cleaning% TEMP%, cleaning the disk (erasing all the error reports there, stuck on the system for every fireman, all kinds of memory dumps of fallen processes, etc.), removing more unnecessary programs.
However, as I found out, there are folders that no one cleans (from the word at all). Well, in the sense of the standard tools. And now I want to talk about the folder% WINDIR% \ System32 \ DriverStore.
If you have this folder occupies a lot, a lot of space, and reluctance to read the whole post - please come to the very end, there are links to github, where you can get the finished result of my research and try to squeeze (or squeeze) some space from Windows.
Introduction to the problem - what is this folder, why is it needed, who is to blame, what to do
If you rummage through the Internet , you can find that this is the place where the system caches all the drivers that it has ever been on the way. Yes, and those that were installed for your video card three years ago also lie there, despite the fact that you updated them yourself many, many times.
')
I will result a little theory from that MSDN:
Starting with Windows Vista and the third-party driver packages. The hard disk. Only the driver can be installed for a device.
When all the driver files are copied, it’s all out. This includes the INF file. All files are the driver package. This is an information file for device installation. The package is not copied to the store.
The process of copying is a driver package. A driver package must be used to install any devices. As a result, driver installation and installation are separate operations.
A driver package is validated by the driver store.
In my free translation, you get something like:
In Windows Vista and later, the driver store is used as a collection of trusted pre-installed and third-party drivers. The operating system maintains this compilation in a safe place on a local disk. Only those drivers that are in the repository can be installed.
When a driver is copied to the repository, all its files get there, including the .INF file and all the files to which this .INF refers. All files that make up the driver are considered necessary for the operation of the device. The INF file must refer to all the files necessary for the device to work, so that they all fall into the repository. If a .INF file refers to a file that is not included in the driver, this driver is not copied to the repository.
The process of copying the driver in the repository is called staging ( did not try to invent the term, left the English word - comment. Per. ). In order for a driver to be used for any device, it must go through a staging process, thus installing the device and staging the driver are separate operations.
Before entering the repository, the driver is checked for the validity of the signature and the integrity of the files.
Is it all so bad, and no one will help?
It looks scary for climbing with your dirty hands, isn't it? However, there is a small (and not very convenient) straw from Microsoft, it is called pnputil.exe and it can:
- List the drivers that are in staging (but not included in the standard distribution of your Windows, ie, not integrated into the installation distribution)
- Add driver to storage
- Remove driver from storage
Moreover, during removal, it checks whether the driver being deleted is currently being used for any connected device, and without the / f option (ie / force - force it), it refuses to delete such drivers.
I used this utility.
I’m not to mention that I’m not the first one so smart who thought about this problem, there is a GUI application for the DriverStore Explorer on the codeplex, but it is actually only a graphical wrapper around pnputil and doesn’t analyze the driver in any way, giving complete freedom to its user.
First of all, I didn’t really want to find outdated versions of drivers manually, and secondly, I wanted to understand that I would gain by removing one or another driver (in the sense of disk space).
So I picked up Python
Hooray, build your bike!
With a close look, I found that in order to find the most recent version, there is enough data from pnputil, but not to determine the size, because pnputil about the driver says something like the following: who did, when, the version and the name of the INF file. Which of the heap of folders in the DriverStore refers to this driver - it does not say.
Looking more closely at the% WINDIR% \ Inf daddy, I found there those same .INF files (by name) that pnputil lists, and looking in the folders in the DriverStore, I found there ... the same .INF files, but with different names - each in a folder of its driver.
Surely there is a simpler way, but I went to the forehead - built a display on behalf of the .INF file in the pnputil output to a folder in the DriverStore, which has the same contents of the .INF file (with a different name). And I took the size of this folder for the size of the driver.
Now it was up to the small thing - to wrap all this in scripts for convenient execution.
On the way, however, lay a setup in the form of UAC - pnputil worked only with administrator rights, which means it was necessary to raise the privileges from Python. A quick googling gave a few recipes that said something like “you can do this, but the output (and even less input) will not be how you will be debugged - without a clue,” and it did not suit me, so I did a little bit examples
True, my implementation is not perfect at the moment - it will fall when I try to redirect stdout or stderr, because inside I use the Windows concept of the console, but for redirected threads this does not work ...
But for the time being, I have closed my eyes to this, because to fix this a little more complicated mechanism is needed than the FreeConsole / AttachConsole call, i.e. to redirect all threads manually.
We try written in practice
And now, in fact, the most gusto - the results of all this footballer text. You can take, use at your own risk, you can try to do good and benefit the source code (MIT license, yes). You can even tell me thanks in the comments, if someone can help these scripts :)
Release on github'e
If you download the binary version (the interpreter is wired inside), take the one that corresponds to the bitness of the operating system (the 32-bit version on the 64-bit OS will not find pnputil and work, respectively, will not ... if you really need to - write, you can try to get around it).
If you take the scripted version - the same way, you need to run the interpreter with the bitness of the operating system.
I personally checked it on two computers with Windows 7, in theory it should work on Vista and 8. On WinXP it should be (sort of) useless.
The script will analyze the driver repository, try to find outdated versions of the drivers (i.e., those for which a newer version is in staging at the same time) and offer to remove them by issuing an estimate of the place occupied by the drivers (and the win estimate, of course, also).
Result on my laptop
Personally, I managed to squeeze out about 6 gigabytes (!), Mainly due to the removal of older versions of NVidia video cards.
On another laptop, everything turned out to be not so rosy, I managed to clear only 200 (in my opinion) megabytes, but there the system lived significantly less than mine and simply did not have time to accumulate a lot of drivers.
Both laptops have since lived a full life, in the sense of any problems from cleaning, I did not notice.
If you have read this far - thank you for your attention!
Afterword
It was expected that it turned out that cleaning scripts do not always work, the main problem is if Windows is not English-speaking (somehow I did not think that the utility utilities would be localized).
In addition, for Windows 8 cleaning scripts, apparently, are not relevant, as Skywrtr rightly points out in his comments .
See the picture for Win8
Source: https://habr.com/ru/post/196404/
All Articles