Jump to content

Windows Update Error Code 80072EFD


TheRobster5555

Recommended Posts

I am also getting the 80244019 error from WU. :(

Fortunately I made lists of the updates that previously installed when WU was working.

Edited by SIW2
Link to comment
Share on other sites


3 hours ago, SIW2 said:

Checking the catalog with windows patch loader at this moment reveals updates from 2007 are there and can be downloaded. I have just checked in the last couple of minutes.

What build number are you testing with? The only prerequisite for SP2 was SP1, so “updates from 2007” are of no value.

Link to comment
Share on other sites

Running windows patch loader in win7 offers the same downloads for vista from the catalog.

It is up to the user to select any they want to download.

This is why I kept a list.

When vista WU was working, windows patch loader could create a list of download links for currently installed updates. I have already done that.

Edited by SIW2
Link to comment
Share on other sites

  • 1 month later...
On 8/6/2020 at 4:38 PM, VistaLover said:

...Something similar happens when I manually check Windows Defender for updated definitions:

7dAo5CC.jpg

Normally, the manual check would return a "No updated definitions were found for Windows Defender" result (or something to that effect...), but now it quickly errors out like this:

kJ73qC7.jpg

...I have WS2008 M$ updates installed that enable SHA-2 code-signing support:

jHp6vVO.jpg

PS: KB4474419 is v4

Hello @VistaLover:) It looks like you were able to manually install definition version 1.321.787.0 created on August 6, 2020. Are you still able to manually install mpas-fe files? I only ask because of an AskWoody thread Defender updates no longer install on Vista, much of which sounds like baloney to me. If I may be allowed one more silly question, does your Vista laptop have an NVIDIA card? That thread contains a peculiar hypothesis that updating to build 6003 causes a black screen of death on Vista systems with NVIDIA cards. :wacko:

Link to comment
Share on other sites

On 9/13/2020 at 1:09 AM, Vistapocalypse said:

Hello @VistaLover:) It looks like you were able to manually install definition version 1.321.787.0 created on August 6, 2020. Are you still able to manually install mpas-fe files? I only ask because of an AskWoody thread Defender updates no longer install on Vista, much of which sounds like baloney to me. If I may be allowed one more silly question, does your Vista laptop have an NVIDIA card? That thread contains a peculiar hypothesis that updating to build 6003 causes a black screen of death on Vista systems with NVIDIA cards. :wacko:

With all due respect, @Vistapocalypse, the above referenced thread doesn't sound like baloney to me.  While it is indeed a peculiar hypothesis, it may very well be peculiar to only that individual who is experiencing the problem.  Their attempt at updating to build 6003 only seems to cause a black screen of death on their Vista system which is running an NVIDEA GeForce GT 640  graphics card, not on all Vista systems with NVIDIA cards.  

Link to comment
Share on other sites

On 9/18/2020 at 3:43 AM, XPHomeSP3 said:

What version of WSUS Offline are you using to download updates to Vista?

The last release channel version of WSUS Offline with Vista support was v10.9.2, released on 2017-03-19;
the last release channel version of WSUS Offline with WS2008 support was v11.8.3, released on 2019-11-14.

Vista users should probably use the ESR channel of WSUS Offline; the last/most recent version advertised on their download page with any Vista support is v9.2.5, released on 2019-06-04:

https://download.wsusoffline.net/ => Archive

However, there's still a more recent v9.2.6, not being publicly advertised, released on 2019-11-08:

https://download.wsusoffline.net/wsusoffline926.zip

cEiD5f0.jpg

Edited by VistaLover
Link to comment
Share on other sites

If I'm posting this in the wrong place, please do PM me and I'll move it to the right place. :yes:
the pic below shows MSE v. 4.4.304.0 (this is x86, but the same applies to x64) still working OK and updating by itself on Windows 7 SP1.
I don't know whether this is relevant or not for the Vista community, but decide to post just in case. This is the last version that works OK with no nags at all on XP SP3, but nowadays cannot update anymore on XP, due to the required engine version being unable to run on XP... however, the fact that it runs OK on 7 means that even in the case it cannot auto-update on Vista (but I didn't test it on Vista to ascertain whether it can or not auto-update on Vista), it sure should run OK, with no nags at all and support being updated by hand. HTH.

20200917_MSE.gif

Link to comment
Share on other sites

3 hours ago, dencorso said:

I don't know whether this is relevant or not for the Vista community, but decide to post just in case. This is the last version that works OK with no nags at all on XP SP3, but nowadays cannot update anymore on XP, due to the required engine version being unable to run on XP... however, the fact that it runs OK on 7 means that even in the case it cannot auto-update on Vista (but I didn't test it on Vista to ascertain whether it can or not auto-update on Vista), it sure should run OK, with no nags at all and support being updated by hand. HTH.

@dencorso: You probably missed reading

... and the 3 following posts (exchange between me and @Vistapocalypse ), especially this:

Historical progression of facts:

1. WD/MSE on Vista stopped being update-able directly from Windows Update (or via their integrated [manually] "Check for Updates" feature [which also evokes WU]) in the start of July 2019, when Microsoft changed the WU delivery infra to employ only SHA-2 endpoints (the SHA-1 ones were still on-line at the time...)

2. WD/MSE users on Vista had to turn to manually fetching files (for 32-bit OSes) mpas-fe.exe/mpam-fe.exe and running those to get the definitions of their M$ antispyware/antimalware "solution" up-to-date; these standalone files (links of which can be found on http://www.microsoft.com/en-us/wdsi/defenderupdates ) were, at the time, still dual-signed (i.e. both SHA-1+SHA-2 code signatures), so running them and installing updated defs was working....

3. Towards the middle of October 2019, M$ stopped dual-signing those files (as well as their "ingredient" files), updated versions came as only SHA-2 signed; while running an SHA-2 only signed file is not necessarily a problem on Vista SP2 patched fully until its EOS (April 2017), it is in this case because the security app/OS has to verify the integrity of both the engine and updated definitions, before installing/integrating them... Without SHA-2 support in the OS, definitions for both WD/MSE would stay at their last dual-signed version and become stale in a few days... For posterity, the last dual-signed version of the off-line updaters was v1.303.1946.0, sharing the same mpengine.dll v1.1.16400.2 :huh: ...

4. To overcome [3], Vista SP2 users had to manually download and apply some KBs, targeting Vista's Server counterpart, WS2008, which bring SHA-2 support to the Vista OS; with that implemented, mpas-fe.exe/mpam-fe.exe [SHA-2 only] could properly update off-line their respective M$ security apps...

NB: While the finer details were not very clear then, installing those SHA-2 enabling M$ updates on Vista has the following shortcomings:
4.1. Vista's Windows Update Agent (wuaueng.dll) is not being updated to its SHA-2 compatible version (M$ made it sure, via checks, that only the supported WS2008 SKUs got that privileged treatment, not poor EoS'ed Vista :realmad:, despite them both sharing NT 6.0) , so connection to the new SHA-2 only Windows Update endpoints was/is not feasible; hence, WD/MSE could not connect to WU and be updated, again, via that route (as in the era before July 2019) ... :angry:
4.2. Vista's build number is changed to 6.0.6003 (SP2 = 6.0.6002) and that fact by itself made the WU SHA-1 endpoints give it the cold shoulder (this is OT in this discussion, but if available dual-signed Vista updates were not installed prior to the migration to SHA-2 support, these would no longer be offered via WU[SHA-1] :realmad:

5. On the first week of August 2020, M$, as announced, shut down permanently their WU SHA-1 endpoints, cutting off completely Vista SP2 (with/without SHA-2 enabled support) and, I'm sure you know already, WinXP :whistle: This had, of course, no bearing on either WD/MSE on Vista, but is at least related to this thread's title... :sneaky:

6. Closing in on recent times, v1.321.xxxx.0 was/is the last Vista compatible series of offline security updates (i.e. files mpas-fe.exe for WD & mpam-fe.exe for MSE); that series introduced engine file (common for both installers) mpengine.dll v1.1.17300.4; the last version in that series was 1.321.2290.0, released on Aug 28th 2020:

ZBZjh6O.jpg

Next series of off-line installers,1.323.xxxx.0, introduced new engine version 1.1.17300.5, but that one is no longer compatible with Vista/NT6.0:

19w8vdZ.jpg

So Vista SP2 (with SHA-2 support installed) users of either WD/MSE can't manually update their definitions past v1.321.2290.0 (close to a month stale :realmad: as it is...)

M$ continue to advertise on their "Security Intelligence" (:puke:) portal that they offer off-line updaters for "Windows Defender in Windows 7 and Windows Vista", and in fact I have sent them feedback informing them of the current predicament Vista users find themselves in, but they have yet to respond to my report... :realmad: BTW, next series v1.325.xxxx.0 is closing in...

PS1: There have been reservations expressed by members here, notably @Vistapocalypse, about the efficacy of running Vista's native WD or a considerably old, nag-free, version of MSE on Vista, and probably with good justification ... But this is NOT the gist of this post; so please refrain from such remarks here... ;)

PS2: As of this writing, I have employed a "hack" to keep updating my WD with defs past Aug 28th, which essentially boils down to keep using the last compatible engine, v1.1.17300.4, with definitions (files *.vdm) prepared for the non-compatible engine 1.1.17300.5; for now, it seems to just work; but the two engine versions are close enough/similar; I bet when a future engine version is released, say 1.1.19xxx.0, the new definition files it will come with won't be backwards compatible with v1.1.17300.4 - it'll then be GAME OVER! :(

PS3: I haven't yet jumped into @win32's Extended Kernel, especially since I'm on a physical machine (so not on a VM I can experiment with), but also because I am on 32-bit, which presents special challenges towards the ExtKernel goal... If @win32 has already implemented TryAcquireSRWLockExclusive in his kernel32.dll wrapper, then that would be the ultimate solution for Vista users wanting to keep their WD/MSE installation updated with current definitions/engine!

PS4: A new project has come to light (first mentioned here by @burd ) that restores WU[SHA-2] support to Vista SP2 past last August's breakage; the legality of that project is still unclear; also unclear is whether WU connection is being restored to either WD/MSE, so that the apps could (again) download updated definitions directly from WU (Vista Extended Kernel would be required for successful installation...). 

I guess that's it! :sneaky:

Edited by VistaLover
Link to comment
Share on other sites

31 minutes ago, VistaLover said:

A new project has come to light (first mentioned here by @burd ) that restores WU[SHA-2] support to Vista SP2 past last August's breakage;

It'd be lovely if someone could eventually accomplish the same thing for XP (at minimum at least XP 64-bit, since it is vaguely similar to Vista RTM/SP0, and thus probably somewhat more fixable using modified Vista methods than 32-bit XP, which is a rather different beast).

Or even better, reverse engineer and implement a 100% compatible clone of the server-side WU/MU v6 engine so it can work indefinitely, which would be much better, because even if SHA-2 support were to be somehow retrofitted into XP (for instance), the relevant XP-related updates will eventually be removed anyway, therefore rendering such support mostly moot.  Having a clone of the server-side back end running locally can host a user-defined archive of updates locally (or optionally, some online archive of select official and maybe even unofficial updates) that will always be preserved in some form.

c

Edited by cc333
Link to comment
Share on other sites

26 minutes ago, cc333 said:

because even if SHA-2 support were to be somehow retrofitted into XP (for instance), the relevant XP-related updates will eventually be removed anyway, therefore rendering such support mostly moot.

The same stands true also for Vista updates currently hosted at WU SHA-2 endpoints; that project I mentioned simply enables connection to the endpoints, M$ could purge Vista related content at anytime... :(

30 minutes ago, cc333 said:

(or optionally, some online archive of select official and maybe even unofficial updates) that will always be preserved in some form.

... and I'm sure Microsoft will use all their powers to hunt down and "terminate" such public WU alternatives... :}

Link to comment
Share on other sites

1 hour ago, VistaLover said:

PS2: As of this writing, I have employed a "hack" to keep updating my WD with defs past Aug 28th, which essentially boils down to keep using the last compatible engine, v1.1.17300.4, with definitions (files *.vdm) prepared for the non-compatible engine 1.1.17300.5; for now, it seems to just work; but the two engine versions are close enough/similar; I bet when a future engine version is released, say 1.1.19xxx.0, the new definition files it will come with won't be backwards compatible with v1.1.17300.4 - it'll then be GAME OVER! :(

That hack is essentially the same we used on XP: by keeping Engine Version 1.1.15800.1, we were able to continue updating up to the *.vdm v. 1.293.2807.0... then the next *.vdm files required a newer engine version and game over it was. But, from that period just before game over, @heinoganda had cobbled up an automated updater that download the the new definitions, replaced the engine by the last one working and put all files in their proper place, therefore helping more people to keep their MSE up-to-date up to game over, and I bet he sure might be able to modify that tool for the Vista community to enjoy the last leg of their MSE/WD more confortably. In case he doesn't ping this theread soon, do send him a PM. I'm sure he'll be delighted to be of help. Ceterum censeo Decimum delendum esse!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...