Dave-H

I can't remember the full details, but the wuaueng.dll I'm using is dated 2nd June 2012, and it is a modified version (for SHA-2) so that could well be the issue.

Thanks, very interesting. My authorization.xml file has an expiry date in it of 2014-11-17, so it appears to have expired over ten years ago! The article does say that the expiry of that file is not relevant on the XP version of Microsoft Update when using Legacy Update. "Legacy Update hosts a proxy service to connect to this server, which we use on Windows 2000, XP, and Vista. Due to the way Microsoft Update is designed, configuring a custom server in the registry also inherently allows it to receive Microsoft Update updates. It also means the expiry doesn’t apply, because the authorization file is no longer relevant. This is the workaround we most likely would have used." I don't know if that also applies with the workarounds I and others here are using, but the fact that the file actually expired many years ago would seem to indicate that. So, why isn't it working any more?

So has Win32ss engineered the patch for Supermium, even though it's only at Chromium 132? It is based on the ESR version, which should surely be able to have the patch applied?

Microsoft Update seems to be no longer working for me. It had been fine, although I hadn't tried it for a long time. Now getting error 0x80248015 as soon as the scan starts.

I do hope that remark was a generalisation referring to the software, and not aimed at anyone on this forum personally.

Thank you so much, but I'm afraid that is pretty much all completely over my head! Do you know why the /3GB switch cannot be used with the RAM patch applied?

Having now reviewed things, I've come to the conclusion that increasing the apparently available RAM won't do anything at all to help with my crashing browser. Correct me if I'm wrong, but from what I've researched, the problem is fundamental, and it's because it's a 32-bit browser on a 32-bit system. My understanding now is that 32-bit processes are limited to accessing 2GB of RAM, and that remains the case regardless of how much RAM is on the system. All the RAM patch will help with is running more processes simultaneously, it won't help at all with giving more memory to individual processes. The Facebook browser tab is constantly running out of memory because of the FB Purity add-on, which is eating huge amounts of it. It appears that there's nothing I can do about that. Although it caused other problems, unfortunately, the only thing which helped was using the /3GB switch in boot.ini, which I gather allows a process to access 3GB of memory instead of 2GB. I've tried using the /3GB switch with the extended RAM patch, but the system then just BSODs on startup, so I assume that configuration isn't an option. Am I right here, and there's actually nothing I can do about the browser problem? Thanks, Dave.

New release 132.0.6834.226 R5. This release was expedited to cover critical vulnerability CVE-2025-6554 (#1486). Some other changes were made: (#1480) - "Web Scrobbler" extension should now work on Windows XP, as well as other extensions that create notifications (#1473) - Favicons should no longer slide out of tab bounds when dozens of tabs are open in a given window (#1483) - Support for custom tab and new tab button shapes that are derived from an scs file are disabled by default after some users experienced performance declines after their introduction. This functionality is now gated behind the --enable-advanced-customization switch. Unless someone tells me that CVE-2025-6554 (#1486) is really important, I think I'll pass on this one.

Sotwe.com is working fine here in the UK on Supermium 132.0.6834.224 on XP.

Members are reminded of forum rule 1a. 1a. This is not a warez site! Links/Requests to warez and/or illegal material (e.g., cracks, serials, etc.) will not be tolerated. Discussion of circumventing WGA/activation/timebombs/license restrictions, use of keygens, or any other illegal activity, including, but not limited to, requests for help where pirated software is being used or being discussed, will also not be tolerated. Offenders may be banned on first violation. It is expressly forbidden to post links to, or to discuss, any form of warez.

In case anyone is interested, here attached are the two pairs of files used on the system by daniel_k's patch (hal2.dll and ntkrnl32.exe) and the '64G' patch (hal64g.dll and ntkl64.exe). I'm afraid I don't know how to analyse them to see just how similar they are. Looking with CFF Explorer, the dlls certainly do look very similar (they are exactly the same size), although of course not identical. If anyone with the necessary skills can compare them properly, I would be very interested to know the results! RAM Patches Files.zip

So it would be a waste of time installing daniel_k's patch on a uniprocessor machine anyway? I wonder why he bothered to include the option! So, do you think the two patches I've tried are actually doing exactly the same thing, so there's no advantage of one over the other? One isn't making the extra RAM any more accessible to programs or the system than the other, for instance?

OK, I decided to have a try with daniel_k's patch to see if it produced any different results to the one I was already using, which was linked to here. It took me a while to get it installed. As I have a multi-boot machine, my file paths are not standard, which caused the batch file to fail. For instance, the batch file contains many instances of the path "%SystemDrive%\Windows\". As my Windows XP installation is in D:\WIN-NT this did not of course work! The author should really have used "%WinDir%" I would have thought, unless I'm missing something. Do be aware of this if you try to use this patch on a system which doesn't use the standard paths. Anyway, once I'd edited the batch file so all the paths were correct for my system, it still didn't work. It said it couldn't open SP3.cab, so couldn't extract the files it needed to patch. Why I do not know, It warns that it needs to be run as Administrator, but apart from the fact that I am of course an Administrator user on the machine, there is no option to run the batch file as an administrator as far as I can see when the installation is on FAT32 drives. Maybe that wasn't the issue, but I could execute the commands fine manually in Command Prompt, the batch file just didn't seem able to do that itself. Very strange. Anyway, I did the whole thing that way, manually executing the lines in the batch file one by one, and it all seems to have worked. Everything looks exactly the same as with the previous patch, the browser is still falling over on Facebook. It's certainly a much more complicated install routine than the patch I was using first. How the other patch does it by just using two extra files added in System32 and a simple modification to boot.ini is a mystery to me. In the daniel_k patch, you have to specify what sort of machine it is (ACPI Multiprocessor in my case) to get the right HAL files. How the other patch does it without having that specified is impressive! I'll let you know how I get on now with this patch. Cheers, Dave.

Linking to pre-activated versions of software is forbidden under forum rules. Links and name references removed.

I must say that I couldn't see anything obviously wrong on reboot12's video either, no crashes or error messages. Is Explorer being sluggish the only issue? I've been using Explorer a lot since I applied the patch, and I've not noticed any difference in performance, apart from the USB issue I mentioned earlier, which now seems to be fixed. Incidentally, I've now determined what specifically is causing the out of memory problem on my browser. It's being caused by my Facebook Purity extension, which is why it was only happening on Facebook! If I disable the extension, the problem goes away. Of course, that isn't the answer. It works fine on the 64-bit version of the browser on Windows 10. The issue still is that although the extension might be causing high memory use in the browser, now that it supposedly has 16GB of RAM to play with, it shouldn't still be running out of RAM!