[SOLVED] Windows 7 PRO SP1 64-Bit Multiple Windows Update Failures from Dec 2018 On

[Sysnative Windows Update]

See if the update works now. :)

 

[malletKATman]

2019-04 Security Monthly Quality Rollup for Windows 7 for x64-based Systems (KB4493472) succeeded! It ran three reboots before properly configuring everything. So your driver install fixed that problem.

However,
Definition Update for Windows Defender Antivirus - KB915597 (Definition 1.291.1728.0)
Installation date: ‎4/‎13/‎2019 5:12 PM
Installation status: Failed
Error details: Code 8050800C

Now I couldn't care less about Windows Defender; I run my own Webroot SecureAnywhere malware protection.

I include only the CBS.log file because KB915597 fails immediately, not on the restart, so the driver status does not seem important.

Do we declare victory at this point and go home?

 

[Sysnative Windows Update]

I believe that the error is caused by the fact that you are running a different security solution, so I would not worry about it.

Please get me the latest SURT report after all these installs.

 

[malletKATman]

Well, Webroot knows how to share and play well with others. It runs with most other security packages without incident to them or itself. But this is of little consequence.

 

[malletKATman]

Done. Leaving for a few hours.

 

[Sysnative Windows Update]

Okay, so there are 700+ deployments to fix which would take a lot of time and not really make a noticeable difference (at least not for now). I would suggest that I temporarily declare victory and we monitor for any issues, because if we decided to go down and fix all of the issues it would take a long time and worst of all, there likely wouldn't be any noticeable difference (as your WU is working as of right now).

 

[malletKATman]

Okay, so there are 700+ deployments to fix which would take a lot of time and not really make a noticeable difference (at least not for now). I would suggest that I temporarily declare victory and we monitor for any issues, because if we decided to go down and fix all of the issues it would take a long time and worst of all, there likely wouldn't be any noticeable difference (as your WU is working as of right now).

I agree completely. Your time is more valuably spent elsewhere. I want to make one more summary post after this about what happened and giving thanks for all the effort you put into this. After that we should declare this thread as SOLVED. I’ll open up another thread if this problem reoccurs.

As to why this happened: I lean to only three sources because as you know I do not credit viruses/worms/malware or disk I/O errors for these problems

• Using PCTools Registry Mechanic as a registry cleaner instead of just a “cookie monster”. Registry cleaners have a habit of removing “dead key” nodes, i.e., keys for which there is no value, as well as keys that have pointer values (e.g., path/filenames that don’t exist). These are similar to Directory/Folder entries for deleted files in the file system. Apparently W.U. wants these “dead key” nodes in the Components hive. I used PCTRM for over 9 years to clean my registry. I no longer do that.
• Running Windows 7’s Disk Cleanup on the Windows Partition and accepting cleanup of old Windows Update operations. That would also remove “dead key” nodes. I used to do this regularly when I had only an 80GB Windows Partition. (I now have 930GB of usable space, so I no longer do this.)
• Windows Update failures. I deem it possible that failed updates could leave damage that would inhibit future W.U. runs.

It’s unclear how a missing “driver” (not really an interface between the PC motherboard and a hardware controller) could suddenly have been missing as to cause the abrupt onslaught of W.U. failures on 2018-12, after 9 years of successful operations. But this is what you detected in the C:\Windows\Inf\setupapi.dev.log file, and “cured” by using pnputil to “install” a pseudo-driver already on my system, that is, without an intervening download. It also is unclear to me if this install would have arrived at the solution before many of the preceding registry cleanup operations. You probably do know. Care to comment?

 

[Sysnative Windows Update]

I am most inclined to believe that it was a combination of you running a registry cleaning software and a potential Windows Update failure which might have caused issues when it failed.

And a small correction, the driver wasn't on your system. The component was in the component store, but the driver was missing and needed to be installed and imported into the driver store. What I did was I used a pnputil to import it and install it from the component store directory.

I actually do recommend running Disk Cleanup after a system upgrade to remove remnants. I frequently do this after each and every system upgrade and never have an issue. I do not run it in between upgrades, though.

We will never know what really caused the issue, we can only make educated guesses on our experience. Especially in such a long and complex thread. Not to mention the fact that you have not upgraded the system in 9 years. Who knows what might have been lurking?

 

[malletKATman]

Not to mention the fact that you have not upgraded the system in 9 years. Who knows what might have been lurking?

I'm not sure what you mean by "not upgraded". I religiously kept the system up to date with every offered W.U. release for Windows 7, installed SP-1 when it was offered, etc. Any "lurking" problems should have been detected by MS (every W.U. release had a malware/damage scan as part of the package). No SFC or chkdsk run ever revealed any structural problems.

It behooves every software vendor who claims to be supporting a system release level to find problems "lurking" in that level and root them out, or offer work-arounds and/or restrictions of features whose problems they cannot fix at that level. It is not the user's responsibility if (s)he installs every recommended system update, short of an upgrade to a different major version of the system. That's not supposed to be the required fix to problems in a supported release level. After January 2020 MS can legitimately require an upgrade to fix problems because they will then officially drop Windows 7 support after having declared their intentions a reasonable amount of time beforehand. Still, there will be major customers who will not move off of Windows 7 and will turn to 3rd parties for fixes and solutions to problems, such as filling in breachable security holes.

 

[malletKATman]

The problems that caused W.U. to fail on December 2018 have been solved by an almost Sisyphusian (certainly Herculean) effort by softwaremaniac that started on February 19, 2019, and ran until April 13, 2019. At least seven different tools were used to analyze and finally fix the problem, at least three of which are from 3rd parties (not MS).

Earlier in this thread I reposted a post by Niemiro from on a similar thread describing how and why these problems are usually fixed by human, small-step repetitive cycles of analyses and corrections until a solution is converged, rather than through one direct analysis and correction by a software tool. Preceding that I also posted my critique of the W.U. process and Registry pseudo-database. I stand by those statements, which IMO document a serious flaw in Windows Update starting with the Windows NT release and extending at least through Windows 7 to which I can attest. I don’t have sufficient experience with subsequent major Windows releases to know if the problems continue, but from the large number of similar threads I have examined on this and other Windows Update forums, it would appear that they do. Unfortunately, IMO, those postings appear have been removed from this thread.

Other than my disappointment expressed in the last sentence in the preceding paragraph, Sysnative.com has proven its merit to me. Many hours of volunteered expert effort was expended to keep my Windows 7 system alive until MS casts us out of the nest on January 2020 or thereabouts. Sysnative.com people are indeed worthy of your support through contributions to maintaining this effort, which is why I am a contributor.

It is time to mark this thread SOLVED and freeze further posting, but I hope it stays “alive” in a read-only state for its valuable lessons in Windows Internals.

 

[Sysnative Windows Update]

I meant that you have not not reinstalled the system or switched to Windows 10.

Thank you for your kind words. Best of luck.

 

[malletKATman]

I meant that you have not not reinstalled the system or switched to Windows 10.

One should never have to reinstall a system level to fix problems. Imagine if that were required of a global airline reservation system or the federal Medicare database. During Apollo 11's successful mission to the Moon, two IBM 360-96 VM computer systems were locked into memory cycle synch to make sure the computer mission managing system never went down.

 

[malletKATman]

I must correct my final "Thank You" post, three levels up. I did not post my criticisms of W.U. and the Windows Registry to this thread, but rather to PMs to both s/m and jcgriff2. Thus I made an erroneous and unfair criticism of the management of threads on this website, for which I hereby apologize deeply. I have nothing to criticize about that, other than the inability to clip in screen images and attach files in PMs by ordinary users. Staff members are not so restricted in PM postings.

The gist of my Registry criticism is that it is an unduly fragile form of a database without the transactional journaling and recovery present in "modern" databases that must operate 24/7/365 with a minimum downtime and data rollback, which impacts W.U. reliability. This DB software and methodology predates even Windows NT. Such database software also routinely crawls the database (or a copy of the database) during slack hours looking for structural problems and correcting them. I also highly recommend reading Niemiro's posting How to Fix Windows Update Error Code 0x80073712 you can find in another thread on the Windows Update forum.

 

[Snickers]