AstroSkipper

@NotHereToPlayGames! As I reported weeks ago, I observed BSODs on my Windows XP system when starting one of the 360Chrome versions, caused by WiseVector StopX. Now, I checked the used memory addresses in my system and found out that WiseVector StopX loads the file WiseVectorHelperOne_X86.dll at the default address 0x10000000 of chrome.dll. I think that was the reason for the BSODs. Therefore, a rebasing of chrome.dll is mandatory for those Windows XP users who use WiseVector StopX.

My suggestion to offer a special rebased version for Windows XP users is due to the fact that this thread only targets the version 360Chrome 13.5 build 2022. This version is rather a poor choice for Windows XP users on old, low-powered hardware. Therefore, a rebased version of, say, 360Chrome 13.5 build 1030 would be more suitable for these users. So only one additional version would have to be provided. All Vista users do not need a rebased version, they have the ASLR feature. And all users of Windows 7 and higher do not need this browser anyway. Anyway! Ultimately, it is solely your decision. I personally switched to the version 360Chrome 13.5 build 1030 which I already rebased.

I have also already downloaded the ReBase tool from the Windows SDK. When I have time, I will try that out as well.

Hello @NotHereToPlayGames! Since I was the one who discovered and documented the abnormal RAM consumption of the 360Chrome browser in Windows XP, for which I received extremely friendly comments in this thread at the beginning, then called for further investigations and researched the causes, I will now take a look at the state of play. First, the good things. For all Windows XP users who really need this browser, i.e. who want or need to run old, low-powered hardware for which this Windows OS is the last compatible one, the method of rebasing the chrome.dll is an excellent stroke of luck to put an end to the memory hunger of this browser. Thanks again to @UCyborg and @mixit for their tips! I have now rebased the chrome.dll file in all my 360Chrome installations. I was able to reduce the RAM consumption of 360Chrome 13.5 build 2022 by almost 85%. That is truly enormous. It's almost beyond belief! Now, the bad things. For me, the time it takes to start a browser is totally unimportant and frankly irrelevant. What is much more important is the loading behaviour of websites in general when the browser has already been started. And that's where this browser doesn't look good at all. Many websites take eternities for being loaded if at all. It is not uncommon for the endless loading process to end in an error page. Not comparable to @roytam1's UXP or moebius browsers at all! That would be much more of a cause to be concerned. Anyway! If I were you, I would leave all 360Chrome editions for users of Windows Vista and higher as they were. For Windows XP users, however, I would offer a separate version in which the chrome.dll file has been rebased in any case. The reason for such a procedure is the ASLR feature, which all Windows versions from Vista onwards have, but unfortunately Windows XP lacks. On the subject of rebasing, you can certainly test which address is best suited for this procedure. Personally, I have done it automatically with libase. And that seems to be sufficient, at least for me. However, I hardly think that this will improve the loading behaviour of websites on old, low-powered hardware. In any case, I couldn't notice any improvements in the loading behaviour of websites on my system. This is probably more of a browser-specific problem which presumably can't be solved without further measures as for example recoding, code changes or code optimizations. And I doubt that 360Chrome 13.5 build 2022 is the best suited version for Windows XP. For example, 360Chrome 13.5 build 1030 seems to be better suited as far as I can observe in my case, according to the 360Chrome rule: the newer, the worse.

My Windows XP system runs like a charm without any errors. We have an interesting range of working browsers which are constantly being further developed, and a lot can be done on such a system. Windows XP is a perfect Windows OS for old, underperforming computers. I hope this OS will live forever.

Dito!

The worksround for translate.google.com is to set the dom.enable_performance_navigation_timing preference to false.

You forgot to mention which browser you are referring to.

The last days, the website of Legacy Update had an certificate error and couln't be accessed. This seems to be fixed now.

Try again! The last days, their website was unavailable due to a certificate error. It seems to be fixed now. BTW, there was and is no need to open a new thread for an error with Legacy Update, actually. We already have two threads about WU/MU. Specifically for Windows XP: And for Windows in general: Kind regards and Merry Christmas, AstroSkipper

The quotation is from here: http://www.jsifaq.com/SUBJ/tip4800/rh4851.htm (no longer available, only via archive.org). To fix such errors, you can try to replace the file ntdll.dll in both folders, System32 and dllcache, by a fresh, working one! Your existing file is most likely corrupted due to any reason (bad image, scratched or badly copied CD or DVD, and so on). Anyway! Your installation medium is probably corrupted, and I wouldn't trust in any case. If one file is corrupted, there still might be more. Therefore, try to create a fresh medium maybe by using a different computer!

Glad it finally worked for you! But in terms of Windows XP, my guide "General and specific solutions for problems regarding AU/WU/MU in Windows XP" is completely sufficient. And by the way, I personally have a complete, offline update archive with all updates for Windows XP. For the German edition, of course! I don't like relying on Microsoft's update servers, where everything concerning abandoned Windows operating systems could be deleted at any time.

Hello @UCyborg! I compared your chrome.dll to my rebased one. The sizes are the same but the hashes are different. I thought libase uses the hash from the original dll file for rebasing. So why are the hashes different? Is it also dependent on the system? Or did you perform the rebasing manually with specific addresses?

I already did that. Version 1030 runs more smoothly on my old system than version 2022. Both versions are consuming very little RAM.

I think it was the chrome.dll from the version 360Chrome v13.5 build 2022 rebuild 3. I also downloaded @UCyborg's rebased chrome.dll to compare it to mine. The sizes (of original and rebased chrome.dll) match in any case, and it works.

And again, you are absolutely right! In some special cases, it's better to use old programs on old systems what you may call "period correct". They were developed for these anchient OSs, and one can avoid problems that much more modern programs can cause. I have often experienced this on my old computer.

If it doesn't work for you, try the method Legacy Update alternatively! Link:

I have never used Windows Server 2003, but in the archive Restore_WU_XP.7z, there are updates for both OSs, Windows XP and Windows Server 2003. Try to install the failing updates manually!

Hello @Great_Life! All you need you'll find in my article: Cheers, AstroSkipper PS: In that thread, I have listed all existing methods to restore WU/MU.

Hello @mixit! You are absolutely right! I also tried to rebase the chrome.dll of 360Chrome 13.5.1030 rebuild 6 and failed. Only after removing the file signature with your recommended tool delcert, I was able to rebase this chrome.dll, too. Thanks for your tip! Kind regards, AstroSkipper

Hello @UCyborg! You are great! I have chrome.dll rebased, and now 360Chrome 13.5.2022 consumes much less RAM than before, such as it is the case on many other systems. Here is a screenshot: The total of RAM usage is now 4.4 + 28.05 + 22.61 + 13.24 + 31.52 + 20.25 = 120.07 MB Thank you very much! Greetings from Germany and Merry Christmas! AstroSkipper

I already did that in 360Chrome v13.5 build 1030 months ago. This version is generally less RAM consuming than 360Chrome v13.5 build 2022. One 360Loader.exe and only four 360Chrome.exe processes with a total of round about 500 MB. That's the lowest value I ever had for 360Chrome 13.5. And I don't know why the version 360Chrome v13.5 build 2022 consumes much more.

360Chrome v13.5 build 2022 in safe mode Same consumption values in safe mode as in normal mode. But I have to mention that the same drivers for memory management were loaded in both modes. Therefore, no further conclusions can be made here, unfortunately.

Thanks! This is a 64-Bit computer. Your values are a bit high in two processes of 360Chrome but otherwise similar to the others using 64-Bit CPUs. But more interesting would be values from a 32-Bit computer if you have one.

And your hardware specs? The consumption values without information about the system used are not meaningful. Just add a screenshot of SIV32X with your hardware specs!