Vistapocalypse

Looks like that WU hack is repeatedly giving you a few old updates, such as KB3060716 from 2015 (for both Vista and Server), also 4014793 (Vista) and 4036162 (Server) from 2017!?

Is this a kindergarten now? It was your friend Dixel who introduced the term “fake news” into this thread. I agreed with him, and you had no objections, so it must be some other new member who you now think is “teacher’s pet.” I simply dislike implausible posts, but I will try harder to disregard yours in the future.

Microsoft must have decided that ESU customers running 2008 SP2 deserve to have a supported .NET version after April 26, 2022. (Looks like I was formerly correct that 4.6.0 was the last officially supported version.) Thanks to all who have investigated this interesting development!

I was almost certain that .NET 4.6.0 was the last to officially support Server 2008 SP2, but I just looked it up and and a Microsoft document now shows 4.6.2 as supported!? (But it neglects to mention 4.6.1 in connection with 2008 SP2, so quite possibly an error. This is near the bottom of https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-requirements .) Special procedures are were required to install 4.6.2 or above on Vista. Edit: Subsequent posts reveal that installing 4.6.2 is no longer a problem, assuming that SHA-2 support has been installed. Btw updates for 4.6.1 and earlier are supposed to end on April 26.

I believe the previous extended kernel had the same issue. Aside from sticking with Firefox 88 or below, you could try the hex edits in win32’s September 11 post. Edit: Next post suggests that this advice no longer applies.

Installation is possible, but I would advise against it because you will get missing dependency errors with .NET software that should work on vanilla Vista (see this May 17, 2019 post). Unless you simply must test some program that specifically requires 4.8, you would get better results with any lower 4.x version.

IDK then, but your issue seems OT here.

Do you have BSODs before you install the antivirus that I think might be Webroot, or only after??

If you have an antivirus, get rid of it before installing extended kernel. (You use Webroot IIRC.)

That update is not required, and D.Draker probably thought it was causing your problem even though your BSOD is not Win32k.sys as reported by Avast/AVG users in 2019.

The extended kernel does not require KB4493471 that you say caused a BSOD that once affected many Avast/AVG users, however it does require KB4474419.

For someone who dislikes OT posts, you certainly post a lot of them. I was familiar with those anonymous posts at AskWoody, and linked directly to them in my April 30, 2019 post in the relevant MSFN thread (whereas you have quoted Woody’s interpretation without using quotation marks). Whereas you claimed “I’m getting BSOD right now” October 20, the anonymous poster running Server 2008 x86 without Avast reported some UAC-related issues. In addition to Windows Defender, that system had “an old spybot search and destroy.” (SpyBot ended support for Vista in 2015.) Some Vista diehards actually upgraded to build 6003 specifically because Defender definitions have required SHA-2 for the last 2 years, and none of them reported a BSOD.

Fake news then.

The worst thing about Newmoon 27 is its extremely old JavaScript engine. Newmoon 28 or any other UXP-based browser would probably perform better in this regard.

Thanks for reminding me to wish my sister a Happy Birthday today.

What version of VMWare workstation? Are you running 6003 solely because you installed the SHA-2 update KB4474419 (and perhaps the servicing stack update), which I believe is all the extended kernel requires, or have you also installed one or more monthly rollups or security-only updates released in April 2019 or later?

So if that upgrade actually affects Vista issues on Haswell and newer, a security-only update might be just as effective as a monthly rollup. In that case, I would suggest testing with KB4499180 from May 2019, which Microsoft actually encouraged Vista users to install due to the BlueKeep scare.

I admire your zeal to investigate something that was reported April 25, 2019 by one member who now runs Windows 8.1. Are you thinking this report was “fake news” as Dixel might say? I was a little suspicious at the time, if only because no one else ever reported a VMWare issue whereas Avast/AVG users with exactly the same BSOD were posting far and wide. (The member lives in the Czech Republic, where Avast/AVG is based - possible motive?) But in fairness to a member in good standing, he posted some clarification about affected and unaffected versions on September 6, 2019 in a short thread that might interest you. While searching for that, I went back too far and found something else that might interest you: Windows Vista + Intel Haswell issues: Documentation.

Lately there have been reports that devices cannot be restored using iTunes version 12.10.11.2 (e.g. https://discussions.apple.com/thread/253272795), so good luck with that version check bypass!

KB4489887 was a March 2019 Preview in which build 6003 was first introduced. For those actually running Server 2008 SP2, such Previews were Optional updates. I don’t think any MSFN member running Vista installed it at the time, since the build number change was not noted here until April 2019. About your BSOD: AFAIK those Win32k.sys BSODs were all attributable to applications that depended on version string “6002.” Even if you don’t use Avast/AVG, antivirus would still be my first guess. One MSFN member traced his BSOD to VMWare (see my link and read a few pages). If you can identify another program that was broken by 6003, I would be as interested as anyone. Since this seems to be the only Vista thread that new members want to read, I’ll mention that Avast solved their issue with a microupdate in June 2019. To install Avast 18.8 on 6003, I would try an online installer because the offline installer is older than the microupdate.

I am inclined to agree with that. Reports of limited improvement could be an example of the placebo effect.

Your skepticism is perhaps not unwarranted. I couldn’t help noticing that the BetaWiki link currently says “Last edited 5 days ago,” which was the same day the “news” appeared in this thread. Where did BetaWiki learn about this “new version of the HAL driver which fixes the corruption bug that affects Intel CPUs based on the Haswell and later microarchitectures”? Obviously not from the Microsoft link provided under References, which does not mention HAL at all. You also have a valid point that this discussion is rather OT here in the extended kernel thread. It might have been better to resurrect Server 2008 Updates on Windows Vista. (My link leads to the point where contemporaneous discussion of build 6003 began, but you wouldn’t find anything about Haswell+ issues there. Personally, I was rather concerned about 6003’s potential to break software that worked on 6002, and there were a few such instances.) Or perhaps Compatible hardware with Windows Vista, which AFAIK was where Haswell+ issues were first documented. On the other hand, I would very much like to hear what @win32 has to say about this HAL discussion. Your forum style is perhaps overly aggressive. I wouldn’t be surprised if TSNH feels offended, because I was once offended by one of your attacks. Let’s seek the facts without any flame wars.

That laptop GPU was not very powerful. Have you tried with Aero disabled? The last Vista driver should be 342.01. You mentioned “while using Chrome” in your September 12 post. If the issue is only with Chrome, maybe look up your CPU to see if it supports SSE3 that Chrome now requires.

I think @burd has them all (see his yesterday post), but not sure if he is currently on Haswell+ hardware and wish he could remember which Patch Tuesday he was referring to. I can’t test myself, but this is interesting.

Microsoft’s article on KB4493471 (April 2019) and associated links don’t appear to mention Hardware Abstraction Layer at all. Since it was a monthly rollup, any subsequent monthly rollup would presumably include the undocumented changes and perhaps even undocumented bug fixes related to those changes (but the Security Only updates might not include anything of the sort). If one were to install e.g. KB4499149 from May 2019, they should be able to duplicate your results and would also be patched against the once-infamous BlueKeep vulnerability. It might be worth noting that the SHA-2 update KB4474419 was not a monthly rollup, although installing it would change the build number to 6003.