In praise of Windows Update Minitool

Topic

New Reply

When the Lounge “appendage” finally comes onstream (in a week or two), we’ll have a forum devoted to Windows utilities. I’ve been watching for comment
[See the full post at: In praise of Windows Update Minitool]

Reply | Quote

Replies

Woody, Martin Brinkmann had a detailed write up of this utility a while ago in his blog… Here’s the link:

https://www.ghacks.net/2015/10/10/windows-update-minitool-is-a-third-party-client-for-updating-windows/

Reply | Quote

Happy New Whatever Woody – so appreciate your ongoing iiinsights. NOW: what is going on with the incessant 20% CPU utilization by “interrupts Deferred Procudedure Calls ” in BOTH win7 & win10?

Seen many many widespread questions since 2014 but never a compendium of thought. Lots to do with Nvidia / Intel drivers but no strong consensus. Wondering if you might host a thread dedicated to this?

Reply | Quote

WUMT is literally a masterpiece, not just for Windows 10, but for all versions specially XP and Vista

Reply | Quote

I will try to give more information to dwh, the original poster in relation to the purpose and use of this tool as I understand it.

1. WU Minitool is a GUI for the already built-in functionality. It does this better than the Windows Update tools in the same way some people find useful Classic Shell for Windows 8/8.1 or 10.
WU Minitool does not add functionality not available in Windows, but it “unhides” what Microsoft already designed and it does it very well and with a very intuitive interface.

2. The best way to use this tool is to configure Windows Update to Never update. This is to avoid the interference between the built-in configuration and WUMT. There are further developments of WUMT by other parties to entirely replace Windows Update and launch WUMT instead, but this is more in the realm of hobby than something to be done by everyone.

3. WUMT does not need installation, it is totally portable. It get updated often, but for most functionality, any version is “good enough”. For Windows 10 1607 in particular, it is recommended to use the latest version. For those who prefer to use the tool in other languages than en-us, there are translations available.

4. My preference is to not change the setting which configures the download mode. This acts on the registry area where the Group Policy configuration is done. This is redundant if Windows Update is configured to Never check and WUMT is used manually as intended.
Those without Group Policy Editor may find it useful to configure WUMT in Windows 10 Home Edition to Never check for lack of a better option.
Everyone else can have a different preference. Avoid Managed by Administrator though as we proved here that it may have unintended effects and this is due to the design of the equivalent policy in Windows and not due to WUMT.

5. As dwh noticed, there is little benefit is using download only functionality.
The normal use is to Select Update service to Windows Update or Microsoft update and click on the Refresh/Scan button (first top left).
After scan, it all becomes descriptive.

*** Very useful for those still with slow scanning on Windows 7 (which is only their fault if they are regular readers here, this was resolved first in March 2016 – KB3138612 and next and better in June/July/September 2016 – KB3172605/KB3161608) ***

Select the checkbox Include superseded and you will be amazed of the difference of scanning time! 🙂 But avoid to select updates to be installed with Include superseded. It is not harmful, but you may end with installing 500 updates instead of 100.

Reply | Quote

Would like to see some comments about use of the MiniTool with Win10 Pro and especially Home. Healthy New Year to you all!

Reply | Quote

Hi, how about a link to the minitool.

Reply | Quote

Nice tool.

Windows Update though runs as quickly inside Windows 7 Pro on my machine (around 25 seconds to search for updates).

Include drivers is checked by default.

Reply | Quote

Woody, WU Minitool can assist you your Group B style followers by using the so-called Offline Mode, under which the wsusscn2.cab file is used.
The Security Updates database from Microsoft can be downloaded from
https://go.microsoft.com/fwlink/?LinkID=74689
This file is updated regularly by Microsoft and has to be downloaded fresh to be relevant when scanning against it.

Reply | Quote

Care to put that in the form of a blog post? I’m pressed for time at the moment….

Reply | Quote

I was convinced that you like Komm’s KUC even more 🙂
http://windows-update-checker.com/

Reply | Quote

https://www.google.com/
Search for windows Update Minitool

http://www.majorgeeks.com/files/details/windows_update_minitool.html

https://www.wilderssecurity.com/threads/windows-update-minitool.380535/ with a lot of information

Reply | Quote

I think Include Drivers should work only for Windows 10 1607 by setting a specific new Group Policy. But read carefully the description of that Group Policy which appears not to do what most people believe it does.
Read also this thread https://www.askwoody.com/2016/how-to-roll-back-a-bad-driver-update/#comment-113143 in particular the comments by abbodi86 and me.

Reply | Quote

Documentation from Mr. X…

https://wumt.blogspot.mx/2016/11/windows-update-minitool.html

Reply | Quote

Keep up with changes via the Mr X WUMT blog

https://wumt.blogspot.com.au/

Reply | Quote

Different utilities, same love 😀

one of most useful features of WUMT is “Copy link to clipboard”
it allows you to have download links without having to use ESEDatabaseView to get it from DataStore.edb
and it shows if there are bundled updates within

Reply | Quote

See https://www.askwoody.com/2016/anomaly-in-blocking-win10-update/#comment-107845

Reply | Quote

“Translated by Mr.X”

the developer is clear 🙂
press on the version date “20.12.2016” to go to his page

Reply | Quote

Actually ch100, the KB3138612 update alone did little or nothing to resolve the WU slow scan problems in Win7. It first required a COMBINATION of KB3138612 AND the KB3139852 win32k.sys update Noel C. mentioned back in the spring of 2016. The PERMANENT fix was to install either KB3161608 or KB3172605, which updated the entire WU client for Win7 SP1 and no longer depends on the latest win32k.sys security fixes.

It was ultimately using the outdated WU agent/client apps for Win7, which cannot handle scanning & searching for 300+ updates for Win7.

And note that the WU slow scan problems also occur on Windows Vista SP2 which were worse than the problems encountered in Win7.

Reply | Quote

It is more complicated in fact.
Just get a new installation of Windows 7 with SP1 and install only KB3138612.
The first scan after, is in fact as fast as it should be.
After installing a reasonable number of patches to avoid failed updates, let’s say about 25 in any combination, the next scan is slow again.
Abbodi86 and me discussed this behaviour few times here and abbodi86 thinks it is something to do with certain unidentified patches causing a kind of corruption of the SoftwareDistribution cached database. I cannot pinpoint any of those patches, but I certainly identified Office 2013 patches behaving badly with incomplete references to the Microsoft back-end servers, fortunately superseded now. I posted the list of those patches in one of the previous months here on this site.
KB3139852 has different effect which is to supersede a lot of patches and this is true for all recent w32k.sys patches, it is not a true speed-up patch but acts like one in a given context.
The only true solutions are as you mentioned, one of KB3161608 or KB3172605.

Reply | Quote

On Vista, try WUMT with the option Include superseded selected, ideally on an upatched computer.
Tell me what you noticed 🙂

Reply | Quote

I installed and set up WUMT on Sunday. 1st scan took 45 minutes. it showed nothing new available. I figured that would happen
because I had run WU about 3 hours earlier. I’m concerned about the LONG run time. Yesterday I ran it again. this time there was a 30 minute run time. Still nothing new.

I was getting faster run times from WU without the mini tool.

IMHO, at this time I don’t feel it is a good fit for my Win 7 machine. However, I will not give up YET. Will run again tomorrow and see what happens.

Dave

Reply | Quote

Try adding the WUMT .exe file to the whitelist in your AV/AM program.

Reply | Quote

Well, WU took only 3 minutes to run this morning. WUMT took 17 minutes for the same results. Even though WUMT has more features, I will probably remove it later today.

Will be a busy day with Dr. appointments and errands to run.

Also, another problem has reared it’s ugly head. SEVERAL of the icons on my desktop have been automatically changed to generic icons. I have no idea what has caused this. Something else for me to do later.

Dave

Reply | Quote

KB3139852 has been superseded. As of release of KB3145739, KB3139852 has stopped having any positive effect on Windows Update, because it has stopped having a negative one.

It’s a wrong perception of this issue to search for triggers and fixes (win32K.sys updates) in different places.

Installation of a trigger of this issue, aka a magic patch, isn’t only installation. It’s also removal from the list of updates to be offered, which calms down the Windows Update Agent.

When the issue has been fixed for the moment, it doesn’t get relaunched by release of any new update or a number of them. It gets relaunched by the release of at least one new trigger. The trigger KB3139852 got replaced by the trigger KB3145739 on April 12 2016 5 PM UCT.

The general issue does not get triggered by corruption of the SoftwareDistribution folder. If Windows Update is working fine the day before Patch Day and is broken the minute Patch Day takes effect – what’s supposed to have corrupted SoftwarDistribution all of a sudden?

Regards, VZ

Reply | Quote

Donwload and run Shawn Brink’s batch file “Rebuild_Icon_Cache.bat” on SevenForums…

http://www.sevenforums.com/tutorials/49819-icon-cache-rebuild.html

Reply | Quote

You have a problem with Windows. The scan should not take longer than 5 minutes and even then, it is too long if you are fully patched as you claim. I believe you have corrupted Software Distribution database due to hiding previous updates.
I think it is worth resetting your WU database to fix the ongoing scanning problems.

Reply | Quote

If this is required, I think that AV/AM is a bigger problem 🙂

Reply | Quote

This may or may not be useful to you but I’ve been using WUMT for many months on a Win10 32bit. I’ve never had a problem with icons changing. Nor have I had issues with icons on my Win7 64 bit machine on which I only just started testing WUMT. Perhaps you need to look elsewhere for a reason your icons changed? The following link may help
https://www.startpage.com/do/dsearch?query=rebuild+icon+cache+in+windows&cat=web&pl=opensearch&language=english

Using the low-spec Win10 device, I don’t mind the time penalty as a trade-off for the better control WUMT gives over Windows update. I’m not trying to say the same is right for you. With Microsoft not offering choices, we are each left facing decisions and chasing methods that better suit our needs. For me, the inconvenience involved initially researching and finding WUMT, using it and updating it outweigh the lack of control over Win10 update.

I suspect WUMT will be short lived on my Win7 device. However, I can say checking the box to ‘Included superseded’ as suggested previously definitely improved WUMT’s check time.

Reply | Quote

Some Internet Security Suites can cause issues with slow WAN traffic…Avast used to be famous for this.

I don’t know about “required”, but it’s an easy try.

The only way to know for sure is to use a packet analyzer like Wireshark to see what’s happening when WUMT runs, which is a little more complex.

The tool ran about as fast as the native Windows Update GUI on my system.

Reply | Quote

Just curious…how does DataStore.edb in Software Distribution get corrupted by hiding updates?

Never heard that in many+years working on Windows
systems.

It can become fragemented over time, which is not corruption.

Easy fix for defragmenting DataStore.edb…

Open an elevated (Run as Administrator) Command prompt, and execute these three commands, one at a time…

net stop wuauserv
esentutl /d %windir%softwaredistributiondatastoredatastore.edb
net start wuauserv

Reply | Quote

It is a misunderstanding here.
We know why the scanning is slow, which is exactly what you said, too much supersedence to be calculated.
However, KB3161608 which was later superseded by KB3172605 introduced an updated Windows Update agent using probably a more efficient algorythm which allows scanning to be completed in a reasonable time which was not possible with the older versions of the agents.
KB3138612 was just a good step in the right direction when it was released, but currently KB3172605 provides the most effective agent for this purpose.
It was documented by Microsoft here
https://support.microsoft.com/en-us/kb/3200747
and discussed a million times before here on this site.

Reply | Quote

It’s still important to point out that the occurrence of the issue is triggered solely from the exterior (by an installation’s eligibility for what’s known as a magic patch) and cannot be prevented (or provoked) by the user unless an appropriate version of the Windows Update Client gets released, which has not happened yet for Windows Vista.

Regards, VZ

Reply | Quote

Well, I ran WUMT this morning and it only took 3 minutes to finish. MUCH better. WU was run about half an hour later and it also only took about 3 minutes. I guess it must have been just a temperamental computer that took so long the other day.

Also, I fixed the desktop icon problem by going back to an earlier restore point. Haven’t figured out what happened, but got it fixed.

Dave

Reply | Quote

“Corrupted”may not be the appropriate word, but this is for lack of a better one and to facilitate understanding.
I explained this concept too many times already.
When you hide an update, it normally has a reference at Microsoft and can be unhidden if required.
When that hidden update is expired at Microsoft, the reference disappears and you end with an orphaned record in the database without reference on Windows/Microsoft Update servers.
That can cause timeouts while scanning, so it is not a corruption as such, only that the client-server relation is broken at that time.
The reason many people think Microsoft somehow unhides their hidden updates is that sometimes there are new patches released under the same number while the old one is expired not long after, KB2952664 is well-known for this behaviour as it had about 20 releases/updates, but it is not unique. In normal conditions (not hiding updates), there would be 2 patches under the same number in Windows Update for a little while, until the old one gets expired.
Hiding updates breaks the dynamic management of the available patches from Microsoft.

Reply | Quote

Corruption has a totally different meaning.

For example, disk corruption is different than disk fragmentation.

Bottom line, hiding updates does not cause corruption, nor is it a bad strategy, especially if a problematic update could be installed accidentally.

Reply | Quote

Excellent, thanks for the feedback.

Reply | Quote

This thread has few mentions here
https://forums.mydigitallife.info/threads/64939-Windows-Update-MiniTool/page69

Reply | Quote

Just want to add my experience using the Windows Update Minitool. January was the first full month I used WUMT throughout the entire update process. I’m running WIN 10 1607 Pro on a five-year-old Dell Inspiron laptop, a four-year-old Gateway desktop, and a new HP Pavalion 2-in-1. I got the Pro Product Keys through my Technet membership.

At any rate, WaaS has done it’s break, brick and hose thing, or failed to install at all, especially on the older computers, every single month. I had to do complete bare metal re-installs on the two older computers when the 1607 Upgrade hit. (I’ll skip the details.) I met Woody via my RSS Feed from InfoWorld, and liked what he was writing, so I looked up AskWoody and added him to my RSS Feeds. I quickly became a daily caller — several times a day, in fact, just to keep up! 🙂

So, when the conversation about WUMT came up, I decided to give it a try, and I love it. Here’s my update routine, and so far it has worked to perfection: I used GPEdit to stop Windows from checking for updates, period. About once a week, I run WUMT to check for updates from WUS. If it finds any, I either hide them or install them, depending. I routinely install most updates when they hit, excepting device drivers (I only install them from the manufacturer if I have a problem), some Windows “surprise” updates that are not strictly security updates, and the monthly Cumulative Updates. Those I hide until the last week of the month or the first week of the next month, depending. I try to get as close to the week before the next Cumulative Update hits as possible, after and only if Woody gives the go-ahead, of course.

Whenever I decide I want to bite the bullet and throw caution to the wind, I do the following (these are things I’ve personally found, through trial and error, that keep the updates from doing their break, brick and hose thing, and refusal to install, on my computers. You can, of course take it for what it’s worth, and, as always with Windows, your mileage may vary.)

First: I do some serious housecleaning: I run CCleaner, followed by System Mechanic, followed by Windows Disk Cleanup, clicking the “Clean up system files” button, and then checking every single box available in order to clear out everything possible. I know MS would have a cardiac arrest, but I also let CCleaner and System Mechanic do their things on the registry, too. Horror of horrors! LOL

Second: I fire up WUMT and check for updates. I unhide the hidden updates, one at a time, and install them from within WUMT. I never have to even even think about messing around with WUS within Windows. So far, smooth as silk.

Third: I thank goodness that I no longer have to live in fear of those dreaded … Break, Brick, Hose, Refuse To Install — PATCH TUESDAYS!

I also thank Woody and the great group of helpful and knowledgeable folks here in the Lounge and at AskWoody.

My goal now is to postpone the upcoming Creators Update until these old computers need replacing. I’ve got all three humming and I want to keep them humming with 1607 as long as possible. I’m a retired seasoned citizen and I neither need nor want anything Creators Update has to offer. I also don’t want to have to buy new computers every two or three years. We’ll see how it goes.

Well, that’s about it. If anyone gets any ideas they can use from my update routine or change it in any way to suit their own needs, I would be most pleased. 🙂

Reply | Quote

Apologies for commenting on my own comment, but I guess I ran out of chances to edit my comment above.

I want to add that Woody DOES NOT recommend using the Windows Update Minitool. He offers several very valid reasons. Please see here:

https://www.askwoody.com/2017/in-praise-of-windows-update-minitool/

1 user thanked author for this post.

Kirsty

Reply | Quote

You can always decompile the application to see the inner-workings… I’ve not taken the time to do so, but I’m confident the Windows Update Minitool is safe.

Reply | Quote

I may have found a significant issue with Windows Update MiniTool v20.12.2016. When “Include superseded” is not ticked, the program doesn’t seem to properly take into consideration updates that are already hidden when listing available updates. Example: on a Windows 7 x64 virtual machine that was last updated in Sept. 2016, I used the program to hide the August 2017 Windows monthly rollup. Then I used the program to check for updates again. The July 2017 Windows monthly rollup should have been listed in the list of available updates, but it was not.

1 user thanked author for this post.

ch100

Reply | Quote

It is true, but the software uses documented Windows APIs which behave in that way.
This may be the reason why Windows or Microsoft Update never scan with “include superseded”, although this functionality is built in the APIs.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa387287(v=vs.85).aspx

A real bug is in the way registry keys are changed when various options are switched between Automatic/Disabled/Check Only etc.
To avoid this bug, the best option is to set the configuration outside of WUMT in Group Policy or in the WU GUI and keep it that way while using the software.
Switching between Windows Update/Microsoft Update/WSUS (if available) is OK and even recommended.

1 user thanked author for this post.

MrBrian

Reply | Quote

After hiding update(s) in Windows 7 with Windows Update, Windows Update automatically rescans for updates, and doesn’t suffer from this issue if I recall correctly from past tests. Does anybody know if this issue with Windows Update Minitool been documented anywhere before?

Reply | Quote

Just tested with Windows 7 Windows Update. I hid August 2017 Windows monthly rollup. The next Windows Update scan correctly listed July 2017 Windows monthly rollup. I hid that. The next Windows Update scan correctly listed June 2017 Windows monthly rollup.

Reply | Quote

I may have misread your original post.
I posted based on the assumption that Include superseded is ticked (enabled).
With Include superseded unticked (disabled, default, identical with WU), the issue should not happen.

1 user thanked author for this post.

MrBrian

Reply | Quote

A familiar user name posted these at another forum: https://forums.mydigitallife.net/threads/windows-update-minitool.64939/page-34#post-1308899 and https://forums.mydigitallife.net/threads/windows-update-minitool.64939/page-35#post-1308923. 🙂

1 user thanked author for this post.

ch100

Reply | Quote

It has been a while since then. 🙂

Reply | Quote

@mrbrian
I believe you have already read this

https://forums.mydigitallife.net/threads/windows-update-minitool.64939/page-35#post-1308936

1 user thanked author for this post.

MrBrian

Reply | Quote

@mrbrian
I believe you have already read this

Not yet, because I don’t have an account there yet.

Reply | Quote

That post confirms what I said earlier about limitations in the WU APIs and not a bug of WUMT for that matter.
In fact I learnt that WUMT uses WU APIs from that post from abbodi.
Technically that post does not confirm my post, quite the other way around 🙂

Reply | Quote

That post confirms what I said earlier about limitations in the WU APIs and not a bug of WUMT for that matter.

I can’t see abbodi’s post, but I don’t understand the logic of saying that, since Windows Update itself also uses the Windows Update APIs.

Reply | Quote

A followup: Portable Update with Search Criteria of “IsInstalled=0 and IsHidden=0” seems to replicate the behavior of Windows Update with regards to this issue, thereby proving that the Windows Update API is capable of being used to avoid this issue.

Reply | Quote

Actually abbodi might say exactly what you say in the above mentioned post – see the remark about the property which may be set.
I have no reason to doubt abbodi’s assessment of this issue, but there is always a possibility and I think he would agree with me 🙂

I tested hiding an update using sample updateSearcher vbscript, and the following update in the chain is not offered afterwards
so i believe WUA API takes the blame for this behavior

or maybe there’s a property needs to be set in order to offer following updates
https://msdn.microsoft.com/en-us/library/windows/desktop/aa386515(v=vs.85).aspx

1 user thanked author for this post.

MrBrian

Reply | Quote

I worked with the Windows Update API awhile a few months ago for code for this site. I’m not sure if there exists a Windows Update API search criteria string that would return the search result set that Windows Update Minitool does regarding this issue. Perhaps what Windows Update Minitool does is use a search criteria string that doesn’t include “IsHidden”, and then after the search result set is returned, manually deletes from the search result set those updates that are hidden.

Reply | Quote

Doesn’t the program work somewhat reasonable by ignoring superseded when not including them? 😀

Reply | Quote

A reason one might hide a given update (temporarily) is that it might have issues not present in older superseded updates.

Reply | Quote

If this is buggy, then Windows Update should be used instead for this particular functionality.
I tend to use WUMT only with Include superseded because this is what gives it a competitive advantage against any other tool that I know. I use this functionality for finding older and not expired updates, mostly for the purpose of analysis.
The main reason to use it for almost anyone else is to control Windows 10 updates for those who do not have other more evolved tools available.

Reply | Quote

I tend to use WUMT only with Include superseded because this is what gives it a competitive advantage against any other tool that I know. I use this functionality for finding older and not expired updates, mostly for the purpose of analysis.

You may wish to consider the Criteria editor of Portable Update.

1 user thanked author for this post.

ch100

Reply | Quote

I was not aware of the software named Portable Update.
Thank you for mentioning it.

1 user thanked author for this post.

MrBrian

Reply | Quote

@ch100: You’re welcome :).

Unlike Windows Update Minitool, Portable Update doesn’t seem to give users the ability to specify the setting IncludePotentiallySupersededUpdates.

Reply | Quote

I find the Include superseded updates the most powerful and useful (to me) functionality implemented in WUMT, rarely available elsewhere. I am not aware of any other software implementing this functionality and if this is the case, the only alternative is to write own software using the documented Windows Update APIs. As we have noticed, while this functionality is very powerful, it has downsides, which may explain why it is not available in the official WU GUI.

EDIT: I edit my original post while not changing its contents because it is not clear to me if the different behaviour for the default functionality is related to this implementation of Include superseded or it is as described in the original post just a bug.

1 user thanked author for this post.

MrBrian

Reply | Quote

I find the Include superseded updates the most powerful and useful (to me) functionality implemented in WUMT, rarely available elsewhere.

There are a few public scripts that have this functionality; do a Google search for “IncludePotentiallySupersededUpdates true” (with quotes).

1 user thanked author for this post.

ch100

Reply | Quote

Thank you, but at this stage I am not interested in spending more time with this issue, as it was already packaged in an acceptable format in WUMT.
If interested in researching further, you may find that the list of installed updates is not necessarily consistent with what Programs and Features show as installed. This is either a limitation or a useful feature of the same WU APIs, depending on how you see it. It can be noticed more easily on an installation of Windows 7 which has around 200 updates to be fully patched (without KB3125574 installed).

1 user thanked author for this post.

MrBrian

Reply | Quote

The program consistently ignores superseded when not including them, even hidden ones. When hiding IE11 and IE10,  IE10 will not be displayed under “hidden” when not including superseded.

Like I said before, it makes sense to the program to exclude superseded when not including them.

Reply | Quote

@volume z
We actually discuss here the supersedence as it is presented by the patches metadata, the only one taken in consideration by WU. In that sense, IE11 does not supersede IE10, although we know that it does in a practical sense.

Reply | Quote

What does it matter? When not including superseded, a hidden superseded will disappear, be it IE10 or the Cumulative Security Update for IE. I understand what you’re discussing, IE11 supersedes IE10, and you have a tendency to treat me like a 3-year-old.

Reply | Quote

For those who found the discussion so far too technical, here is the bottom line: if you use Windows Update MiniTool with “Include superseded” unticked, then if you have hidden updates, Windows Update MiniTool might not list some available updates that would have been shown if you had used Windows Update.

1 user thanked author for this post.

ch100

Reply | Quote

It is a good thing that you raised this issue, as I had almost forgotten about it.
Another way of summarising the conclusions:
– To see all available WU updates with WUMT, always use: “Include superseded”. However this will offer updates technically not needed and this option is useful only for analysis or for those who already know what they are trying to install. Hidden updates show separately.
– If you have previously hidden updates, never use the default functionality without Include superseded, before unhiding the hidden updates first. Otherwise, the results are not relevant, although no damage is done in any situation.

1 user thanked author for this post.

MrBrian

Reply | Quote

There is another possible use for Windows Update MiniTool with “Include superseded” ticked: a better Windows 10 alternative for hiding updates that avoids this potential issue with wushowhide. (@ch100: I know you’re not a fan of wushowhide.)

Reply | Quote

MrBrian wrote:

@ch100: I know you’re not a fan of wushowhide.

I am not, wushowhide is a hack, while I prefer to use the real tools for the purpose 🙂

Reply | Quote

If the information in this post is correct, I’ll revise my prior statement:

For Windows 7 users: If you use Windows Update MiniTool with “Include superseded” unticked, then if you have hidden updates, Windows Update MiniTool might not list some available updates that would have been shown if you had used Windows Update.

For Windows 10 users: If you use Windows Update MiniTool with “Include superseded” unticked, then you see the same updates that would have been shown if you had used Windows Update. If you use Windows Update MiniTool with “Include superseded” ticked, then you have the ability to install available updates that are superseded by newer available updates, which apparently cannot be done with Windows Update.

All of the above is subject to further revision :).

Reply | Quote

For Windows 10 users: If you use Windows Update MiniTool with “Include superseded” unticked, then you see the same updates that would have been shown if you had used Windows Update.

The above is not necessarily true. Windows Update MiniTool can show updates of type Recommended or Optional, while Windows Update does not.

Reply | Quote

I was not aware of the information in your previous post to which you made reference. In essence, this means that Windows 10 update behaves now like WUMT.
It is known that the code for Windows Update client has been re-written for Windows 10 and the client behaviour only keep an appearance of similarity with the legacy implementation and backwards compatibility with Group Policies known from previous implementations. In reality, it now uses new services and new scheduled tasks and the new code would likely explain the new behaviour, intended or not.
What most people need to understand if they are to be efficient and move ahead is that old Windows is gone and if they try to customise too much and deviate from the recommendations which change often, they are on their own. Microsoft will rarely go back and fix issues which are of academic interest and affect few vocal users who contribute very little to their bottom line.

1 user thanked author for this post.

MrBrian

Reply | Quote