MSVCP140.dll not found (Browser requires separate runtime for something IDK)

[ghost]

OS: Windows XP SP3 I receive this error every time I start up the browser, but it starts without any problem after closing the error dialog. Anyway, I was never required to install a VC++ runtime for a browser (all came with their own). And I especially don't want to install 2015-2019 because whenever I install it, I see a huge increase in memory consumption of Chromium-based browsers (from 150-200 MB idle to 1-1.5 GB idle 😮). So what causes this error (what component requires it) if the browser runs without any problem?

[win32ss]

The runtime is statically linked into the browser. It is not necessary and in my test VM it's running with only VC++ 2008 runtimes and below without errors. Something completely independent of the browser is looking for the runtime.

Ultimately I think chrome.dll should be rebased. It seems that on some configurations some of these extra DLLs (progwrp was rebased away from chrome.dll's image base for that reason) "take chrome.dll's spot" and causing memory usage to go up significantly. Ultimately it means that massive executables should be discouraged on NT 5.x and below for that reason.

[mserafym]

With 2015-2019 redist on XP we can see this memory bug in Supermium 121 after run:

Why 10(!) processes... Only one start page... Can you fix this? I need redist 2015-1019 for another programs...

[win32ss]

You can use the switches -in-process-gpu and --single-process to reduce the number of processes, but the latter may be unstable.

Anyway, the Visual C++ memory usage issue is caused by two files in the runtime: api-ms-win-core-synch-l1-2-0.dll and api-ms-win-core-string-l1-1-0.dll, which displace chrome.dll because they are loaded before chrome.dll is, while using the same image base. When those are rebased, chrome.dll should no longer be forced to load above its image base and should use considerably less memory. I will rebase them when I return to the development system later today.

[mserafym]

Thank you! You're just "God level" in a good way!

[win32ss]

Here are the rebased DLLs, to be put next to chrome.exe: rebased_dlls.zip

[mserafym]

Here are the rebased DLLs, to be put next to chrome.exe: rebased_dlls.zip

I just tried these restructured DLLs on the previous (121) and latest version (121 hotfixed), the memory error disappeared after running Supermium:

But other errors occurred (21 times one after another) before the GUI Supermium started, i.e. before the main window appears: Here is a translation of these errors into English for your convenience (I am from Ukraine, we often use the Russian-language and less often the English-language version of Windows XP, who else needs it, Microsoft did not have a native high-quality translation into Ukrainian at that glorious time):

chrome.exe - Invalid image The application or library C:\Utils\Supermium\api-ms-win-core-synch-l1-2-0.dll is not a Windows NT program image. Check the purpose of the installation disc.

In these 21 errors, only the name of the DLL "api-ms..." changes, the rest of the text remains the same. DLL name order: 1) api-ms-win-core-synch-l1-2-0.dll 2) api-ms-win-core-synch-l1-2-0.dll 3) api-ms-win-core-string-l1-1-0.dll 4) api-ms-win-core-synch-l1-2-0.dll 5) api-ms-win-core-synch-l1-2-0.dll 6) api-ms-win-core-string-l1-1-0.dll 7) api-ms-win-core-synch-l1-2-0.dll 8) api-ms-win-core-synch-l1-2-0.dll 9) api-ms-win-core-string-l1-1-0.dll 10) api-ms-win-core-synch-l1-2-0.dll 11) api-ms-win-core-synch-l1-2-0.dll 12) api-ms-win-core-string-l1-1-0.dll 13) api-ms-win-core-synch-l1-2-0.dll 14) api-ms-win-core-synch-l1-2-0.dll 15) api-ms-win-core-string-l1-1-0.dll 16) api-ms-win-core-synch-l1-2-0.dll 17) api-ms-win-core-synch-l1-2-0.dll 18) api-ms-win-core-string-l1-1-0.dll 19) api-ms-win-core-synch-l1-2-0.dll 20) api-ms-win-core-synch-l1-2-0.dll 21) api-ms-win-core-string-l1-1-0.dll

I've placed the new api-ms next to chrome.exe: I also tried to replace your api-ms with the existing original ones in C:\Windows\System32 (I have 32bit Windows XP) - absolutely nothing changes, the same errors before starting Supermium.

MyVCRedist.zip

Please fix it...

[win32ss]

Surprised to see that the api-sets were being seen as invalid PE images, as my own test systems accept them without issue. I decided to compile brand new ones. corrected_api_sets.zip

[Zero3K]

Will these offer any benefit to Supermium on a Windows 11 machine?

[jonm58]

Will these offer any benefit to Supermium on a Windows 11 machine?

Windows has the latest dll files

[Zero3K]

Will these offer any benefit to Supermium on a Windows 11 machine?

Windows has the latest dll files

I mean, changing the base address of the latest version of them or the ones I mentioned in another issue.

[jonm58]

Will these offer any benefit to Supermium on a Windows 11 machine?

Windows has the latest dll files

I mean, changing the base address of the latest version of them or the ones I mentioned in another issue.

Probably none of the things you mentioned above

[win32ss]

Will these offer any benefit to Supermium on a Windows 11 machine?

No. Windows Vista and up do not have an issue with high virtual memory usage resulting from relocated DLLs.

[Zero3K]

Will these offer any benefit to Supermium on a Windows 11 machine?

No. Windows Vista and up do not have an issue with high virtual memory usage resulting from relocated DLLs.

Okay.

[mserafym]

Surprised to see that the api-sets were being seen as invalid PE images, as my own test systems accept them without issue. I decided to compile brand new ones. corrected_api_sets.zip

WOW! Your latest versions of "api-ms" work without any errors!!! There are no more problems with excessive RAM consumption! The Supermium memory saving option works great!

You just can't imagine how grateful I am to you! You have done a very important job, thank you very much! I personally admire how beautifully you solve compatibility issues architecturally in relation to the main Supermium code! It would be great if these two little "api-ms" libraries were somewhere in releases, so as not to lose this issue later

[mserafym]

One last thing, I'll say a little off topic, but the whole reason why this VC Redist 2015-2019 is needed under Windows XP is the ability to return TLS 1.3 in-system functionality for Windows XP (working "WebRequest" with TLS 1.3 for other programs that rely on system Windows crypto libraries), described in this topic https://msfn.org/board/topic/183352-proxhttpsproxy-and-httpsproxy-in-windows-xp-for-future-use/. This is a kind of “crutch”, figuratively speaking, via https proxy in IE under Windows XP. The developers used the updated Python 3.7 with openssl 3.0.5, some of which required VC Redist 2015-2019.

If I find the time, I need to freak out and port it all to C# and the .NET Framework - write a Windows service, take the same openssl, compile it without unnecessary dependencies, make a PInvoke to it and directly wedge the service and GUI for settings for this product into one process.. .

Thank you again!

[andika207]

WOW! Your latest versions of "api-ms" work without any errors!!! There are no more problems with excessive RAM consumption! The Supermium memory saving option works great!

this fix didn't serve me well. the RAM usage is the same whether with or without those 2 api files

[Zero3K]

WOW! Your latest versions of "api-ms" work without any errors!!! There are no more problems with excessive RAM consumption! The Supermium memory saving option works great!

this fix didn't serve me well. the RAM usage is the same whether with or without those 2 api files

Do you have the Visual C++ 2015-19 runtime installed?

[andika207]

Do you have the Visual C++ 2015-19 runtime installed?

-let's gonna summarize this history with as much details as possible.

-here is the post https://github.com/win32ss/supermium/issues/207#issuecomment-1916105316 of when I first benched the RAM usage 5 days back

-RAM usage with :keycap_ten: youtube tabs did exceed or was nearly as much as the XP x86 RAM limitation which is about 3.25GB

-this one was the Supermium's 121 (1st release)

-some days later I put the rebased dll files next to chrome.exe

-not only did it not work https://github.com/win32ss/supermium/issues/200#issuecomment-1923391211 but also auto deleted all of my api-ms-win-crt files from the WINDOWS/system32 folder.

-today I restored my XP backup image (fully updated with POSReady updates)

-I also had to restore Windows Installer process msiexec /regserver which was disabled for no apparent reason

-this way I could install the VC++ AIO package from https://github.com/abbodi1406/vcredist/issues/67

-I repeat the same exact bench test with :keycap_ten: youtube tabs

-when launching 2-3 youtube tabs, RAM usage gets past the 3.25GB limit

-I repeat the same exact bench test with the corrected dll files

-this time I can again open the :keycap_ten: youtube tabs with barely 3.15GB or so.

:red_circle: conclusion: the fix does the job but doesn't really improve my first scores.

maybe and just maybe... the NVIDIA driver comes into play because I was using an old driver brought out by Legacy Update and this time I installed the latest one (368.81) from NVIDIA website and maybe this gets the computer to eat up much more RAM....go figure @win32ss

[win32ss]

If you can run Process Hacker, click on one of the chrome.exe processes and click on the "modules" tab and see if chrome.dll is outlined in orange, then something else is displacing it from its preferred address (0x1000000) and causing the memory usage to spike.

[andika207]

if chrome.dll is outlined in orange, then something else is displacing it from its preferred address (0x1000000)

is this a typo ? on my testbed computer (above tests) the base address is (0x10000000) but it's NOT outlined in orange however on my main computer the base address is different no matter what I do....

---

on the other hand my 360chrome version which works flawlessly and consumes much less RAM makes use of the nº4 chrome.dll file and it's NOT outlined in orange either.

[win32ss]

if chrome.dll is outlined in orange, then something else is displacing it from its preferred address (0x1000000)

is this a typo ? on my testbed computer (above tests) the base address is (0x10000000) but it's NOT outlined in orange however on my main computer the base address is different no matter what I do....

It was a typo, but the screenshot explains why it's happening; another DLL displacing chrome.dll. At this point I may as well rebase chrome.dll farther downward, perhaps to 0x10100000.

[Vangelis66]

another DLL displacing chrome.dll

... Yes, it's WiseVector component dll library; IIANM, that DLL was part of WiseVector StopX :stuck_out_tongue_winking_eye:, an XP-compatible AV/Security Suite, of Chinese origin, that was touted as an ideal solution for that "legacy" OS; the app was initially offered as free beta software, making its users on XP the perfect guinea pigs :smile: , but then its authors decided to move to a payware scheme, for enterprise ONLY; I don't recollect fully all the fine details, but relevant discussion is somewhere inside a MSFN subforum,,,

andika207: Do you have that Security Suite installed and, if yes, does it still receive def updates?

Kind regards.

[mserafym]

this fix didn't serve me well. the RAM usage is the same whether with or without those 2 api files

I thought you had some kind of crap with other software...

[andika207]

andika207: Do you have that Security Suite installed and, if yes, does it still receive def updates?

I installed it by september 2022 in my secondary (currently) disk in the attempt of ''repairing'' my main XP disk partition (no luck) but actually have not used it since... in fact I don't use any real-time AV back in the day I disabled the background service of this scanner for security reasons.

I have just launched it for you... :arrow_double_down:

[andika207]

At this point I may as well rebase chrome.dll farther downward, perhaps to 0x10100000.

I performed my bench test once again and this time Supermium took up less RAM, just about 2.80GB however the @weolar chromium 115 seems to be less RAM hungry with the same active tabs, roughly 2.15GB

[Vangelis66]

I have just launched it for you..

Thanks :smile: ; as I see in your sceengrab :+1: , it isn't getting updated definitions anymore (but the "statusbar" notification is ambivalent in that respect) , so might as well ditch it altogether (just my 2c, ofc), especially since you're not actively using it, by your own admission :wink: ...

back in the day I disabled the background service of this scanner

... But, as shown in your first attachment above, one of its DLLs (WIE918~.DLL) is now interfering with Sm's chrome.exe and is the most probable cause for your elevated RAM consumption by the browser - again, I'd advise towards getting thoroughly rid of WVSX ...

Regards.

[mserafym]

@andika207

I performed my bench test once again and this time Supermium took up less RAM, just about 2.80GB however the @weolar chromium 115 seems to be less RAM hungry with the same active tabs, roughly 2.15GB

Have you set the same settings for Supermium and chromium 115? For example, have you disabled synchronization, page preloading, or enabled memory saving? It is more correct to compare RAM consumption with the same browser settings (including flags).

And even if the settings are the same, it would be fair that the 121 engine consumes a little more than the 115...

Do you use a page file or disable it?

[andika207]

And even if the settings are the same, it would be fair that the 121 engine consumes a little more than the 115... Do you use a page file or disable it?

I didn't mess around with settings, everything is set up by default with no extensions

it's not recommended to disable the page file regardless how much RAM it's available

[mserafym]

@andika207 My result when simultaneously playing 3 FullHD videos (H264 codec) from three tabs + 2 static Github tabs: 1,923GB used / 3,233GB total 1,832GB (processes chrome.exe sum)

Without Supermium, windows XP uses 523.42Mb of RAM out of 3,233GB

I don’t yet know how to solve your problem with over-consuming RAM. Perhaps my RAM numbers will be a guide for you...

[andika207]

three tabs + 2 static Github tabs: 1,923GB used / 3,233GB total 1,832GB (processes chrome.exe sum)

what makes you think this outcome is better than mine ? (11 tabs = 2.80GB)

https://www.carthagosoft.net/MemInfo.php

[mserafym]

three tabs + 2 static Github tabs: 1,923GB used / 3,233GB total 1,832GB (processes chrome.exe sum)

what makes you think this outcome is better than mine ? (11 tabs = 2.80GB)

https://www.carthagosoft.net/MemInfo.php

I didn’t read your previous post to the end and missed out on the 11 Youtube tabs (I only read up to 3 tabs) Looks like the result will be the same

Let it be only for comparison about 3 Youtube tabs

[NS-Clone]

If you can run Process Hacker, click on one of the chrome.exe processes and click on the "modules" tab and see if chrome.dll is outlined in orange, then something else is displacing it from its preferred address (0x1000000) and causing the memory usage to spike.

my chrome.dll displaced by prio.dll, 0x10000000 (process priority saver) that injecting in all processes

so corrected_api_sets.zip doesn't works et all

[NS-Clone]

At this point I may as well rebase chrome.dll farther downward, perhaps to 0x10100000.

it's only 1M gap for "extra" unexpected dlls

move it to 0x11000000 or 0x20000000