AstroSkipper

@Dave-H Have you already tried this new solution?

@Dave-H And check in form of a binary comparison one more time if the correct patched version of wuaueng.dll still exists in relevant folders. I assume in your system is SFC enabled. Just to be sure.

Of course and definitely not! And I am not omniscient. But I decide what is promising by reading, analyzing, checking facts, concluding and if possible proving. I am mathematician and that's the way these strange people like me do it.

@Dave-H Ok, here is a final solution. If that doesn't work too I'll be out of ideas related to error code 0x80072f8f. You can't find any other solutions in the World Wide Web, nay, despite a very deep research I couldn't find any other reasonable solutions related to this error code except those I've already posted. Before performing this backup the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate and the folder WINDOWS\SoftwareDistribution completely or better create an image of your system partition! Here it is: This is a fix if client machines are not reporting to WSUS properly: Client-Side Script: From an administrative command prompt on your system, run: net stop bits net stop wuauserv reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIDValidation /f rd /s /q "%SystemRoot%\SoftwareDistribution" net start bits net start wuauserv wuauclt /resetauthorization /detectnow PowerShell.exe (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow() Explanation: What is this Doing? Should I be Afraid of Running this? This client-side script is something you should not be afraid of. Let’s walk through what is happening and why we’re doing it. We stop the Background Intelligent Transfer Service (BITS), and the Windows Update Service (wuauserv) services because we’re working with items that are in use by these services. We remove the following registry keys if they exist: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\AccountDomainSid (usually errors out but is included to be totally inclusive but I haven’t seen this since before 2005) HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\PingID (usually errors out but is included to be totally inclusive but I haven’t seen this since before 2005) HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientId (This is what is responsible for most issues – duplicate SusClientId entries across multiple clients) HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientIDValidation (This also is responsible with SusClientId) We remove the SoftwareDistribution folder from the Windows folder on the system drive – represented using a dynamic variable. This folder contains the history of Windows Update locally on the machine, but it also includes things like the cache of the downloads and temporary files that Windows Update uses. We remove this folder so that it will be recreated by the Windows Update Agent the next time it checks for updates, creating a corruption-free cache. We start the Background Intelligent Transfer Service (BITS), and the Windows Update Service (wuauserv) services. We run the Windows Update Client (wuauclt) and tell it to reset the authorization to re-create the SusClientId and SusClientIDValidation registry keys. We’ve also stuck on the /detectnow switch on the end of that command to initiate a detection for updates for Windows 8.1 systems and lower. We’ve run the PowerShell equivalent of /detectnow for Windows 10 systems and Server 2016+ systems as they no longer use /detectnow as it has been deprecated. (We can also use UsoClient.exe StartScan instead of the PowerShell line however, Microsoft never intended UsoClient.exe to be used by anything other than the system itself through the orchestrator so your mileage may vary. The correct way is the PowerShell API). Background: What is SusClientId and What Symptoms Does Having Duplicate SusClientId Entries have? WSUS servers use the SusClientId to identify unique devices and then associate the computer’s hostname to the unique identifier for easy recognizable display purposes. Because more than 1 system has the exact same SusClientId, the WSUS server replaces the computer object’s hostname with the latest hostname that communicated with the server. This gives the appearance of a magician’s disappearing act with computers objects. More than 75% of the time that clients have issues, it is due to cloning or imaging computers. Systems that are the ‘golden’ image are often created in an environment that allows the system to communicate with any WSUS server, including Microsoft’s Windows Update. The moment a client system communicates with a Windows Update server, it creates 2 registry keys that are essentially a security identifier (SID) [SusClientId] and a validation key [SusClientIDValidation] that gives a unique hardware identifier in a binary form. The Windows Update Agent is supposed to use a hardware validation routine to determine whether the current client hardware has changed since the SusClientId value was created, and if it has, it is “supposed to” regenerate both the SusClientId and the SusClientIDValidation. “Supposed to” doesn’t always equate to “does” and this is where the problem lies. Note: In my system the subkeys AccountDomainSid and PingID don't exist probably due to the fact that my computer is a stand-alone one. In your system I could see in a screenshot that the subkeys PingID, SusClientId and SusClientIDValidation are present. Therefore I've crossed out all unnecessary steps and explanations including steps for Operation Systems except Windows XP.

I don't believe that this has an effect. In my system I have same date and time format in this key although my regional settings have been set to German DE and nonetheless MU is working flawlessly. @Dave-H Any news? Does changing services mode have any effect? Here is another change to Internet Options of IE, Advanced: unselect "Check for publisher's certificate revocation" too. Note: in my system it is selected at the moment. The entry "Check for server certificate revocation" should already be unselected in any case.

@Dave-H And I've taken a short look at your status of system services. Three system services are absolutely important for MU: bits, wuauserv and cryptsvc. These services should be started and set to automatic. So please set bits and cryptsvc to automatic! And truth be told you should have seen that. Short explanation: not all services could be started if they are set to manual only. Even your web site https://www.blackviper.com/service-configurations/black-vipers-windows-xp-x86-32-bit-service-pack-3-service-configurations/ has a recommended setting of automatic (started) for service cryptsvc. And in my screenshots too. Maybe bits works with mode manual too, seems to be standard but in my system I've set it to automatic. By the way thanks for this interesting link!

No problem but a little bit funny. Read post above!

@Dave-H The idea was only showing Microsoft system services in window of ServiWin sorted by company. Please new screenshots! And you may and should stay at HTTPSProxy but you know you can have both. They are portable and have their own certificates. We have fixed a lot in your system, maybe something has changed and ProxHTTPSProxy is now working you'll never notice. It's just a game called trial and error. PS I don't know how you usually start ProxHTTPSProxy but it has to be started by ProxHTTPSProxy_PSwitch.exe to let it change proxy settings automatically.

@Dave-H Requested certs have been sent via PM. And give your ProxHTTPSProxy a second chance by installing original certificate in program folder. For this purpose apply ProxHTTPS Cert Install.exe. Maybe your generated HTTPSProxy CA certificate is problematic when you try to connect to MU. You know my HTTPSProxy CA certificate has a different timestamp. And don't forget to close HTTPSProxy by clicking exit in systray menu if using ProxHTTPSProxy.

Of course the 10th of March 2021. I'll send you missing certificates as soon as possible. I think they aren't unique, only made for my system. They are from Microsoft. And try method "Turning back time" at all costs! But now Microsoft Update isn' t working anymore. You have to check all including status of all services. And please send me your screenshots listed by ServiWin. Comparing with help of your log file is too tiring.

@Dave-H A little correction. I meant registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate and there the value of LastRestorePointSetTime. Here is my value: 2019-04-12 13:45:09. You see it's your English format. Try the point in time you have there first! Then you may try other points in time. The method "Turning back time" can mean to go back one year or one day. You just have to try out. It's trial and error. Maybe it works. I'll forgive you due to your "senior moment". But where is the 'Use HTTP 1.0' option? I have only these entries: Use HTTP 1.1 and the Use HTTP 1.1 through proxy connections. If there wasn't both entries it had to be assumed that your Internet Explorer was not properly installed or is faulty. Anyway, look at last post of me above to download screenshots of my services in better quality.

@Dave-H Do you want me to upload these missing certificates via PM or not? Your decision. By the way I found out that on platform imgur images in jpg format have a bad quality due to strong compression. Therefore here a link of my two screeshots of all Microsoft services existing in my system listed by ServiWin but more readable plus all services in a txt file: https://www.mediafire.com/file/odq8y7iyx7i5kdf/Microsoft_services_-_AstroSkipper.7z/file

@Dave-H Due to the fact that the Microsoft service HTTP-SSL was disabled in your system I think it is a good idea to compare our Microsoft services and their status generally to be sure all necessary system services are still working. There might be some services not being essential but anyway in my system Microsoft Update is working properly. To do that download the tool ServiWin 1.71 from NirSoft. Here is the homepage link: https://www.nirsoft.net/utils/serviwin.html and here the download link: https://www.nirsoft.net/utils/serviwin.zip. It's portable so there is nothing to install. I've taken two screeshots of all Microsoft services existing in my system listed by ServiWin. Columns with German description have been faded out. So it's much easier for comparing. Here they are: https://imgur.com/az67Jo6 and https://imgur.com/bIQ2jIN.

@Dave-H What about the 5 missing certificates under Intermediate Certification Authorities? You didn't mention it. In the next days I'll post another very interesting solution to fix your problem. I still have to work it out a bit. Of course if turning back time doesn't help! Now I'll go to bed. Cheers!

@Dave-H Maybe your Internet Explorer installation is faulty. Just a guess!

Here the DNS servers I suggested: Google Public DNS. 8.8.8.8. 8.8.4.4. and Cloudflare. 1.1.1.1. 1.0.0.1. Try them! And here's another fix referring to error code 0x80072f8f I have found while researching: Open in a registry editor the key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\LastRestorePointSetTime. Here you can see a date and a time (that's my idea to find a suitable point in time). Now go back to this date and time plus for example one hour. Try to access MU. Reboot. Then adjust clock to current date and time. Do a synchronization. Reboot. Then try again! The idea is to go back in time to the last successful update on MU web site and try to access the MU server. Some people had success with turning back time to solve error code 0x80072f8f. And here a screenshot of my Internet Options - Advanced referring to HTTP settings: https://imgur.com/EHW7rix

@Dave-H Ok, thanks for further details! I have compared our lists of certificates intently. If you had compared our lists of certificates intently too you would have realized that only one of them is identical. And that is the list of certificates referring to Microsoft in Third Party Root Certification Authorities. But in my list of Intermediate Certification Authorities I have 8 certificates referring to Microsoft and you only 3. Have a look! That's a big difference. If wanted I can upload these missing certificates via PM so that you can import them under Intermediate Certification Authorities. As I told you two posts above expired certificates can still be required and in use too. At last I have analyzed your Windows Update Log once again. Here the interesting lines: 2022-02-01 22:53:27:781 1856 9b0 PT +++++++++++ PT: Synchronizing server updates +++++++++++ 2022-02-01 22:53:27:781 1856 9b0 PT + ServiceId = {7971F918-A847-4430-9279-4A52D1EFE18D}, Server URL = https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx 2022-02-01 22:53:28:796 1856 9b0 Misc WARNING: Send failed with hr = 80072f8f. 2022-02-01 22:53:28:796 1856 9b0 Misc WARNING: SendRequest failed with hr = 80072f8f. Proxy List used: <https=localhost:8080> Bypass List used : <<local>> Auth Schemes used : <> 2022-02-01 22:53:28:796 1856 9b0 PT + Last proxy send request failed with hr = 0x80072F8F, HTTP status code = 0 . . . 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: GetConfig failure, error = 0x80072F8F, soap client error = 5, soap error code = 0, HTTP status code = 200 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: PTError: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: GetConfig_WithRecovery failed: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: RefreshConfig failed: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: RefreshPTState failed: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: Sync of Updates: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 PT WARNING: SyncServerUpdatesInternal failed: 0x80072f8f 2022-02-01 22:53:28:796 1856 9b0 Agent * WARNING: Failed to synchronize, error = 0x80072F8F 2022-02-01 22:53:28:796 1856 9b0 Agent * WARNING: Exit code = 0x80072F8F As we already know Microsoft Update 0x80072f8f error code means ERROR_INTERNET_SECURE_FAILURE ErrorClockWrong. What does it really imply in your case? You can see it in your Windows Update Log. Look at bold text! A client fails to contact its server. In your case client is your computer and server is Microsoft Update Server. Request sent from your computer to MU failed. Synchronizing of client and server failed. Getting configurations failed. That' your problem. What is the conclusion? The connection and synchronization failures between client and server have to be fixed. At first we have to think about what we've already restored and fixed. The Windows Update Agent looks fine and you have reported that all steps of my post "Manually reset Windows Update components (KB971058)" have been performed: Have you performed step 4 too or have you skipped it as recommended? If you skipped step 4 then it should be catched up. Furthermore I added another registering of a DLL component: in step 6: Perform this registering to complete step 6. Now some settimgs: Go to IE Internet Options, Advanced and click to select the Use HTTP 1.1 and the Use HTTP 1.1 through proxy connections check boxes if not already selected. Next check if system service HTTP-SSL has system been started. If not start it and set it to Auto Start. Now reboot your computer, try to access MU again and post your Windows Update Log. If these tips don't solve the problem I have another one: Change your DNS servers to Cloudflare or Google and check if it helped. I use often DNS servers of Cloudflare but at the moment the servers of my provider. So far from me today!

@Dave-H I've read an interesting article of a person who had same error code and the solution was a missing certificate in a chain of certificates. Check if following certificate exists under Trusted Root Certification Authorities: GTE CyberTrust Global Root valid until 14.08.2018. I know it has expired but I've read that such expired certificates can still be in use. It's just a try. Furthermore I've found another tip that obviously others had helped: And one more question: Do you have a normal installation of XP or are you running it in a VM? Is your computer a clent or server in a network or a stand-alone one?

@Dave-H Yesterday I had trouble to access Google and other web sites using HTTPSProxy. What had happened? I checked and found out that HTTPSProxy's cacert.pem was faulty. I downloaded a new one manually from this link https://curl.se/ca/cacert.pem and copied it in HTTPSProxy's program folder. I deleted all certificates in certs folder and after starting the proxy I could access all sites without any problems. Updating cacert.pem in SysTray menu is working again. So what is the teaching of that? You have to check and deeply too. Comparing two files only due to size and date is not enough. A binary comparison is necessary or comparing hash values. You can do it for example with Total Commander. So download a fresh cacert.pem from link above and compare it to yours just to be sure your certs are valid and proper in your HTTPSProxy's program folder. Here is a screenshot of my Intermediate Certificate Authorities (there are Microsoft related certificates too): https://imgur.com/G2ogHnj I don't know if they are relevant, they seem to be expired. And here my Third Party Root Certificate Authorities: https://imgur.com/vY3dnq8 What is your current time server? And please upload a new WindowsUpdate.log! Maybe something has changed. A lot of Windows users have reported getting error code 0x80072f8f due to activation problems. So my next question. Is your Windows XP Professional properly activated? Do you have Windows Genuine Advantage (WGA) Validation Tool installed and what is your version? As far as I know the latest version for XP is 1.9.40.0. And I know a lot of questions. Sorry!

Don't be afraid. I use Autoruns since 1995. It's from Sysinternals i.e. from Microsoft. It's totally safe. And there is nothing to install, it's portable. Make exclusions to Malwarebytes!

@Dave-H A proper user agent is very important to let a web site working correctly providing all services for a visitor. Your user agent is bit strange and especially your entry "BTRS111060". My IE 8 user agent is "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; "Trident/4.0; .NET4.0C; .NET4.0E; .NET CLR 3.0.4506.2152; .NET CLR 2.0.50727; .NET CLR 3.5.30729). You can see an absolutely clean UA string. Now there are two ways to change the UA string in Internet Explorer 8: editing registry entries or using an addon called UAPick. Here is the link: https://www.enhanceie.com/ietoys/uapick.asp and download link: https://www.enhanceie.com/dl/UAPickSetup.exe Here more information about IE UA strings and related registry keys: https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/ms537503(v=vs.85)?redirectedfrom=MSDN, https://www.heelpbook.net/2014/useragents-on-internet-explorer-registry-workaround/ and this one https://admx.help/?Category=Windows_8.1_2012R2&Policy=Microsoft.Policies.InternetExplorer::Customized_UserAgent_String. By the way browser modes have been provided since IE8 to help developers fix issues quickly by telling a site to render like a previous version of the application. You can find it in developer tools -> browser modes. In my opinion using UAPick is much easier and safe. I had installed it years ago and you can deactivate it or uninstall whenever you want. Install it, backup your current UA string and then override it using my IE 8 user agent. Then try to access MU again. Hope will never die!

I didn't say you should uninstall Malwarebytes I suggested to deactivate all autostart components and services by using Sysinternals Autoruns (portable tool, lists all autostart entries) with the effect that after restarting no module of Malwarebytes is in RAM any longer. This can be reverted easily without harming your installation. Only a few clicks. Due to your Windows Firewall here another screenshot of my ICMP-Settings: https://imgur.com/9iqJdDP And your are right either your error code is caused by SSL problems reading certificates or unsuitable settings in your system. And you see we have already found a lot. Here I've uploaded for you the latest XP compatible version of Autoruns. More recent versions don't run under XP. https://www.mediafire.com/file/m4b2khdjjjfvlic/Autoruns_v13.98.zip/file

@Dave-H Maybe BTRST - The Braintrust Token? The Braintrust Token is an ERC-20 token issued on the Ethereum blockchain network by the Braintrust Technology Foundation, a nonprofit foundation. Perhaps you had got some adware in the past but anyway. Backup your user agent if needed in the future and set it back to original one just for testing purpose! Or use an addon to manage user agent strings! Here a link: https://www.howtogeek.com/howto/18450/change-the-user-agent-string-in-internet-explorer-8/ And what about item 7 of our list?

@Dave-H So with the help of @RainyShadow (Thanks once again!) I found out that I have an overall size limit for uploading of 1.95 MB and a Max total size of 512 KB. Truth be told these limits would have been fantastic in year 1985 if there had been an internet but in this day and age unsuitable and counterproductive to help people by uploading screenshots. Therefore I've removed all attachments substituted by links and follow the advise of @RainyShadow using imgur for image uploads. For other files I'll use a hoster. Attachments only in case of emergency or size is not exceeding 1 byte! @Dave-H Any news about getting rid of error code 0x80072f8f?

@Dave-H I totally agree to @maile3241. You have to uninstall Chrome Frame for testing purpose. I do not have Chrome Frame installed in my system. And restore your original user agent (maybe Chrome Frame is the causer). Maybe it is another version of IE or screenshot taken from Win 2000. So it doesn't matter. In Internet Explorer 8 it is labeled "Internet Options".