Windows Update Error Code 80072EFD

[win32]

2 hours ago, VistaLover said:

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!

Yes, I did implement it. And it should be one of the few stable functions, as it doesn't call outdated ntdll functions that others do (banking on ntext x86 to fix that though!).

Though you don't have to replace your main kernel32.dll in this case. The addition of a string to the registry and a .local file in the Windows Defender folder along with my kernel32 should suffice.

Edited September 26, 2020 by win32

[Vistapocalypse]

@VistaLover the engine file mentioned here might be worth a look: https://docs.microsoft.com/answers/answers/96261/view.html

[Vistapocalypse]

@VistaLover latest engine version is now 1.1.17500.4

[InterLinked]

On 9/25/2020 at 10:05 PM, Vistapocalypse said:

Among recently active members, I only know of @SIW2 and @Dylan Cruz who might be interested in that.

I'd definitely be interested, but I tried the heinoganda method I think and it didn't work. If there's an easy way, that'd definitely be great for the community!

That being said, my Vista system is more of a novelty. Windows 7 is my "serious" OS.

[tamarindojuice]

--

 

 

Edited December 7, 2020 by tamarindojuice

[Vistapocalypse]

On 9/25/2020 at 7:59 PM, 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!

Compatibility with Windows 6.0 was reportedly restored when engine version 1.1.17500.4 was released earlier this month, apparently after complaints from paid users of System Center Endpoint Protection running Server 2008 SP2. 

However, there has been one recent report of trouble with another mpas-fe file, namely MpSigStub. Any comments?

[VistaLover]

On 9/26/2020 at 3:59 AM, VistaLover said:

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:

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:

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 as it is...)

M$ continue to advertise on their "Security Intelligence" () 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... BTW, next series v1.325.xxxx.0 is closing in..

On 9/28/2020 at 9:40 PM, Vistapocalypse said:

the engine file mentioned here might be worth a look: 
https://docs.microsoft.com/answers/answers/96261/view.html

On 10/30/2020 at 6:46 PM, Vistapocalypse said:

Compatibility with Windows 6.0 was reportedly restored when engine version 1.1.17500.4 was released earlier this month...
However, there has been one recent report of trouble with another mpas-fe file, namely MpSigStub.

Admittedly, I have been remiss in revisiting this thread, but to the extent it concerns my personal usage, I don't consider Vista's native Windows Defender an urgent matter (as explained previously, I'm only running it and try to keep it updated for "legacy"/sentimental reasons ) ...

In any case, Microsoft have been really hopeless in their - still advertised - NT 6.0 support

for the off-line WD standalone updater (file mpas-fe.exe); "Previously on Dynasty", I had reported that series 1.323.xxxx.0 of installers became Vista incompatible, because it introduced engine file mpengine.dll of version 1.1.17400.5, not NT6.0-compatible; that series ended with version 1.323.2309.0, digitally signed (SHA2) Oct 1st 2020.

During the course of the 1.323.xxxx.0 series, Vista users could update manually their WD by
1. Manually downloading mpas-fe.exe from
32-bit: http://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe
64-bit: http://definitionupdates.microsoft.com/download/DefinitionUpdates/amd64/mpas-fe.exe

2. Extracting from it (with 7-zip) the two *.vdm files (the actual definitions; the smaller-sized is a binary diff one)
3. In Windows Explorer, navigating to the Updates folder of their WD default installation, e.g. for Vista 32-bit it's in:

"C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Updates"

4. Dropping inside that directory the extracted *.vdm files (overwriting files, if present); in a matter of ~ 20 seconds, the newer defs will be auto-installed!

NB: Step 4 implies a Vista compatible engine file (e.g. v1.1.17300.4 from the previous 1.321.xxxx.0 series) is still in place in

"C:\ProgramData\Microsoft\Windows Defender\Definition Updates\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"

(the alphanumeric string changes into a new random value with each update)

 

Then, in the docs.microsoft.com URL provided by @Vistapocalypse, there was a link to a newer engine file, v1.1.17400.7, digitally signed Sept 3rd 2020, which was indeed NT 6.0 compatible; sadly, that file was only circulated "internally", while on-going series 1.323.xxxx.0 was still shipping to end users incompatible engine 1.1.17400.5 ...

FWIW, the very few Vista users with access to "fixed" mpengine.dll v1.1.17400.7 could finally upgrade past v1.1.17300.4 by placing it, as with the *vdm files, inside: 

"C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Updates"

 

On Oct 2nd 2020, series 1.325.xxxx.0 was released (with 1.325.10.0) and it introduced new engine mpengine.dll v1.1.17500.4 that reinstated NT 6.0 compatibility; Vista users could, once again, update their WD app by simply running file mpas-fe.exe It would appear all was hunky-dory for Vista users, but, once again in a very short while, Microsoft people goofed up big time

On Oct 22nd 2020, while series 1.325.xxxx.0 was still on-going, Microsoft released mpas-fe.exe v1.325.1199.0; the file still contained the compatible engine v1.1.17500.4, but trying to run said file under Vista you get: 

Probing the file itself with specialised tools revealed that it as well as the inner file MpSigStub.exe, though both remained NT 6.0 compatible functions-wise, had been compiled with a Subsystem 6.1 PE header, thus they couldn't be run under Vista in their default state ...

Of course, trying to mess with the PE headers (and I had no clue how to modify the internal .exe's one ) would invalidate Microsoft's SHA2 code/file signatures, "bricking" the mpas-fe.exe for updating purposes...

Series 1.325.xxxx.0 ended on Oct 29th 2020, with v1.325.1653.0 (the breakage still not fixed); if Vista users wanted to update their WD past v1.325.1177.0 (issued on Oct 21st), could follow the procedure outlined above (by selectively extracting *.vdm files, etc).

 

On Oct 30th 2020, series 1.327.xxxx.0 was released (with 1.327.7.0), introducing new engine mpengine.dll v1.1.17600.5; I am happy to report that
a. The new engine remains NT 6.0 compatible
b. Files mpas-fe.exe & MpSigStub.exe both have their Subsystem PE headers "fixed" to 6.0 
IOW, business as usual (file mpas-fe.exe launches and updates WD's definitions as expected!)

Given MS's previous record on this , I'd say the next f**k-up is imminent...

[Koishi Komeiji]

On 8/6/2020 at 3:18 PM, SIW2 said:

Someone has made an update rollup pack for vista? I don't suppose you would care to let us know what and where that might be?

They might be referring to BobPony's WSUSOffline backup from April 2017 but I'm really not sure, I'm not linking directly to it because there's other stuff on it but I used it and it works fine

I guess it's useful for avoiding that 6003 crаp

Edited November 4, 2020 by Koishi Komeiji

[burd]

On 9/26/2020 at 8:46 AM, win32 said:

 The addition of a string to the registry and a .local file in the Windows Defender folder along with my kernel32 should suffice.

could you please tell me what string needs to be added and where? also is it possible to fix definition updating through WD.

Edited November 29, 2020 by burd

[win32]

9 minutes ago, burd said:

could you please tell me what string needs to be added and where? also is it possible to fix definition updating through WD.

That would be the one used to enable local redirection.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options]
"DevOverrideEnable"=dword:00000001

But, don't the latest definition updates work on Vista again as suggested above?

[burd]

1 hour ago, win32 said:

That would be the one used to enable local redirection.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options]
"DevOverrideEnable"=dword:00000001

But, don't the latest definition updates work on Vista again as suggested above?

They work but one needs to manually fetch them , is it possible to enable manual updating through defender itself like before , or am i forced to download from the ms site now?

Edited November 30, 2020 by burd

[win32]

6 minutes ago, burd said:

They work but one needs to manually fetch them , is it possible to enable manual updating through defender itself like before , or am i forced to download from the ms site now?

Any method of updating through defender would rely on a method of enabling SHA-2 endpoints. I don't think I can say much about that here.