Leaderboard

a workaround has been pushed to repo.

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/HostDrivers/Support/SUPR3HardenedMain.cpp?rev=85127#L29

this should be fixed together with download manager in next build

Sorry, it looks like no one here wants to help you.

Hi With the latest version of newmoon 27.9.7 and several tests, the problem of the german portal "www.heise.de" has disappeared with the solution of siria by activating "javascript.options.strict = true", but the youtube crash continues, obviously the problem is different.

I regret to deviate off topic, but reading this made me laugh the hardest I've laughed all week

OK the youtube crash bug is fixed and commited by backing out a patch that is backed out in mozilla.

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...

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