Leaderboard

I've just finished an update list of Office 2010 (32/64-bit). The patches are automatically applied during installation. Anyone interested? If so, should I create a topic in the Office section?

Just checked the WindowsUpdate.log on Vista, XP and Win7, the block is in the remote WU servers. On supported OSes, this url is used to check for updates: https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx On unsupported OSes, this url is used to check for updates: http://www.update.microsoft.com/v6/ClientWebService/client.asmx But it was deleted. If we could redirect it to the link above, maybe it would still work. Any ideas?

Was working a few hours ago. Now they killed it for sure: WARNING: SyncUpdates failure, error = 0x80244019, soap client error = 10, soap error code = 0, HTTP status code = 404 Database was deleted. RIP.

It is now ca. 20:40 UTC, Aug 6th 2020, and Windows Update is again broken here, in Windows Vista SP2 32-bit ... When I opened the WU window I got: Notice that WU did last perform a successful check on Aug 6th 2020, 00:57 EEST (that was Aug 5th 21:57 UTC); as expected, the check had ended with a Windows is up to date message () ; when I click "Check for Updates", I end up with: i.e. no dice, but with a different Error Code this time (80244019) Something similar happens when I manually check Windows Defender for updated definitions: 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: I think we can say, with a fair degree of certainty, that WU on Vista IS DEAD... Of course, there are various online articles pertaining to Windows Error 80244019 (or 0x80244019), e.g. https://blog.pcrisk.com/windows/12473-how-to-fix-widows-update-error-code-80244019 which states: but in this case I think it is both a "Windows Server problem" (M$ shut the door to it, took it down, etc. ) as well as due to "computer system and configuration" (we have the Vista OS, which M$ vehemently wants to swipe off the face of the Earth...). FWIW, I have WS2008 M$ updates installed that enable SHA-2 code-signing support: so I had, at least, expected that I would still be able to connect to the newer SHA-2 WU endpoints, though, of course, nothing would come down from there, as Vista 6.0.6003 is detected (not being proper Vista SP2 & not being proper WS2008 SP2) and fenced off... PS: KB4474419 is v4 ; please also notice that the last thing ever WU fetched on this machine (then at version 6.0.6002) was a WD def update, on July 6th 2019; after that date, nada ! EDIT:

Update (11/30/2020): The new KernelXE thread is now called "KernelXE - My Unofficial Windows 2000 Kernel", making this thread completely obsolete. Summary: KernelXE is based on kernel32 from WildBill's KB2479629-v3 and includes all of the functions present find in BlackWingCat's kernel32. KernelXE also includes a few functions not found in either kernel32 from WildBill's KB2479629-v3 or BlackWingCat's Extended Kernel. Some full functions have been used in KernelXE instead of the stubs in BlackWingCat's Extended Kernel. Download Functions: New in KernelXE: BaseSetLastNTError (from One Core API) CreateRemoteThreadEx (from One Core API) RestoreLastError (redirected to RtlRestoreLastError from ntdll) EncodeSystemPointer (redirected to RtlEncodeSystemPointer from ntdll) DecodeSystemPointer (redirected to RtlDecodeSystemPointer from ntdll) Full functions that are stubs in BWC's kernel32: GetSystemDEPPolicy SetProcessDEPPolicy GetProcessDEPPolicy GetFirmwareEnvironmentVariableW SetFirmwareEnvironmentVariableW GetFirmwareEnvironmentVariableA SetFirmwareEnvironmentVariableA CancelIoEx CancelSynchronousIo CheckForReadOnlyResource CheckRemoteDebuggerPresent SetSearchPathMode PowerClearRequest PowerCreateRequest PowerSetRequest Known Issues: A Microsoft Visual C++ Runtime Library error appears when running VMware Tools. (Solution) Some other dlls from BWC's Extended Kernel might behave erratically because of the fact that KernelXE is based on WildBill's kernel32. Note: VMware Tools must be installed before KernelXE.

Yes. But you can edit your post here above and add a link to that topic, for easy reference, too.

@docR Say, I heard you came across a slipstreamed Vista ISO through 2019 on archive.org somewhere? Do you know if this legit/where I can find it? Trying greenhillmaniac's script, but it's taking forever. About 2 hours and it's done maybe 30 updates out of ~400.

Sounds right. My MSO.DLL file is exactly 18,640,016 bytes, if yours matches that, it must be it! Drop the 86 off the file name, and check its version, it should be 14.0.7214.5000.

I'm pretty sure the broken behavior is because of other BWC files being made with the expectation that certain functions in kernel32 are stubs. In KERNEL32-XEC, some of these stubs have been replaced with full functions, which explains why the broken behavior disappears when no BWC files are present. I added my files and the new prerequisites to KB2479629-v3 and felt like it was enough of a change to change the v3 to a v4. The update can be found here. I noticed that the Microsoft Visual C++ Runtime Library errors related to VMware Tools are still there. Honestly, I have no idea what's causing them.

Well we had it for over a year longer than we thought we were going to. Had to end sometime. I guess it will have to be manual updates from the catalogue for the last few months of Office 2010 updates.

I think latest for XP are 368.91: https://drivers.softpedia.com/get/GRAPHICS-BOARD/NVIDIA/NVIDIA-GeForce-iCafe-Graphics-Driver-36891-for-XP.shtml But it seems like it is a hit and miss game, see: https://msfn.org/board/topic/177373-winxp-drivers-for-gtx-10xx-video-cards/ https://msfn.org/board/topic/177373-winxp-drivers-for-gtx-10xx-video-cards/?do=findComment&comment=1177300 jaclaz

Who's "we"? MSFN's policy is simple: we do not propagate FUD. Period.

Hi, I'm busy with other stuff, so can't provide you with a script/batch file to rename the files. I'm sure you'll eventually figure it out by yourself. For obvious reasons, you shouldn't have such long filenames to avoid issues during installation because of long pathnames exceeeding MAX_PATH size.