Supermium v124 does not start on Windows XP x32 SP3.

[EDSln]

Describe the bug After startup, several chrome.exe processes start in Task Manager and then terminate. The same with the profile from v122 and with a clean profile. In debug.log the following entry: [0622/001536.515:ERROR:registration_protocol_win.cc(136)] TransactNamedPipe: Channel was closed. (0x6D)

Desktop (please complete the following information):

• OS: Windows XP SP3 x32]

Additional context If you install back v122, it runs without errors.

[Vangelis66]

If I may ask, where were you able to retrieve v124-pre x86 (32-bit) binary files?

Under Assets here, all I can see is the huge archive supermium_124_32_setup.exe.7z which, once fully downloaded and extracted, ONLY contains *.PDB files :angry: ; where can one download the 32-bit installer supermium_124_32_setup.exe from?

Thanks in advance :smile: ...

[Vangelis66]

... What a terrible mess, indeed :rage: ...

The actual 32-bit v124-pre installer, that should've been labelled as supermium_124_32_setup.exe, is behind asset file supermium_64_syms.7z.exe ; FWIW, Supermium's native Google Security Protection (set at basic level here) thinks this file is malicious for one's system, so I had to manually approve its download to disk :disappointed: ...

@win32ss : Please fix the filenames of the assets under the latest pre-release ...

[win32ss]

Please provide any crash dumps that were created in the "Crash Dumps" directory of the user profile, which is located in Documents and Settings\%user%\Application Data\Supermium by default, as this issue is not reproducible on my end.

... What a terrible mess, indeed 😡 ...

The actual 32-bit v124-pre installer, that should've been labelled as supermium_124_32_setup.exe, is behind asset file supermium_64_syms.7z.exe ; FWIW, Supermium's native Google Security Protection (set at basic level here) thinks this file is malicious for one's system, so I had to manually approve its download to disk 😞 ...

@win32ss : Please fix the filenames of the assets under the latest pre-release ...

I have also fixed the file names. While I had just created a script to automatically apply branding, build 32 and 64 bit builds, build installers for them, and build PDB archives for them, the files were created correctly with the proper names and uploaded in that state, which means that this may have been caused by GitHub. I'll look into this problem.

[EDSln]

No such folder is created. So I packed the entire user folder, maybe there is something useful there. User Data.zip

[EDSln]

Another system does not start, also XP SP3, but in a virtual machine. It was the same on version 121, on the same systems it did not start, but then they fixed it.

[EDSln]

with progwrp.dll v1.1.0.5012 and v1.2.0.5063 by IDA-RE-things i get this error.

This version is not designed to work with version 124, wait for an update.

[IDA-RE-things]

@rereser , my alternate DLL is not compatible while with the latest v124 release, because of new added functions. I will update it later.

no such error with progwrp.dll v1.1.0.5016.

Of course, because he changes his API.

[rereser]

the fact remains that Supermium 124.0.6367.245 x32 will not run on my xp sp3 install.

[win32ss]

As dumps are not being created, I would like to see the results when run through an external debugger such as x32dbg. There, a minidump can be created when an exception is hit using minidump name_of_dump.dmp on the command line at the bottom of the window.

[rereser]

name_of_dump.dmp as in: run x32dbg.exe / file open - chrome.exe / paste cmd minidump name_of_dump.dmp / hit enter?

[win32ss]

You should click the "run" button (the button with the arrow pointing right) until the status bar at the bottom reports "First chance exception at XXXXXXXX (C0000005)) or (80000003), then run the minidump command.

[win32ss]

You will have to run it past all INT3 breakpoints and only run the command when the status bar specifies a "first chance exception" that either references C0000005 or 80000003.

[EDSln]

I think I did everything right: https://mega.nz/file/HqRgjCKB#tC0wrg5paX7NuhY3o05UoM_5ZHG1LSvEunY9kRBOiDM

But it's my bedtime, so I'm off to bed.

[win32ss]

The dumps are now correct. With this I found that sometimes the first TLS access comes after a call to FlsGetValue (all my test systems) but sometimes after a call to FlsSetValue (the subjects of the bug). This means that TLS thread attach calls must be made after both functions. This also works on my test systems. progwrp_32.zip

[EDSln]

It won't start with the new progwrp either. New dump: https://mega.nz/file/DqIzUTYC#oWY5c6aZDt9AdJ2m7DIilKEDnUKxzHyng3Ex18aaxy4

[win32ss]

In any event, I will try again. All FlsSetValue calls should go through progwrp now instead of CRT trying to look for them in an api-set introduced in Windows 10: progwrp_32.zip

[EDSln]

Still won't start. New dump: https://mega.nz/file/qyJmFKoT#N4vBXZYXOPcK3jKUSow4aVh0wROuEwtm5aYjVM-kMXQ

[win32ss]

Here is another version: progwrp_32.zip

Is there an api-ms-win-core-fibers-l1-1-0 or api-ms-win-core-fibers-l1-1-1 on your system?

[EDSln]

It didn't start. The file api-ms-win-core-fibers-l1-1-1.dll was found in the folder of one of the programs in Program Files, but it is not in system32. I deleted the file for the test, nothing changed.

Answered immediately, but the dump file is still being uploaded, my internet is very slow at uploading, so it takes time to upload a file of this size. As soon as it is uploaded, I will add a link.

[EDSln]

Dump https://mega.nz/file/SiAGFK6J#9qnmipcSWUHzjEGxtOchxuzWU7ILKGpGumDeXFeVpFA

[win32ss]

Here is another one. progwrp_32.zip

[EDSln]

Don't start. https://mega.nz/file/P2hEUDKR#4gAnHWrVi1QJ7zAiwxlXtx-PxOjvwGpt65K3ASMpFQQ

[win32ss]

Are you running Russian language Windows XP? I just installed it and it does not work for me there either (but the problem in my case is extremely high CPU usage instead of crashes - 122 works fine). I will have to look deeper.

[JoachimHenze]

For me on XPSP3 x32 german Supermium 122.0.6261.152 (R6) runs fine Supermium 124.0.6367.245 does not start. Some processes do get created, CPU maxed out, but does not launch.

I will stick with "Supermium 122.0.6261.152 (R6)" for now.

[Vangelis66]

... I'm well aware this issue is specific to (non-English?) XP SP3 x86, but...

My OS: Windows Vista SP2 32-bit, en-US locale My Sm version: v124-pre 32-bit, el locale

In this thread and as of this writing, win32ss has already uploaded four (4) different v1.1.0.5017 progwrp.dll files, let's call them 1.1.0.5017.0, 1.1.0.5017.1, 1.1.0.5017.2 and 1.1.0.5017.3.

v124-pre comes with v1.1.0.5016 of the wrapper lib; in my setup, versions 1.1.0.5016, 1.1.0.5017.0 & 1.1.0.5017.1 all work as expected to successfully launch the browser; however, versions 1.1.0.5017.2 and 1.1.0.5017.3 both BREAK the browser here :disappointed: ; in Task Manager, only one chrome.exe process stays alive, no browser window ever shows up...

What I'm trying to say is: In the efforts to fix things under XP SP3, please don't break Vista SP2 :wink: ...

Many thanks already for this tremendous work of yours! :+1:

[win32ss]

It turns out that 32 bit XP (NT 5.1) does not set the value of BaseAddress in LdrLoadDll to NULL on failure. Server 2003 and up do, as does ReactOS. Thus, I assumed NT 5.1 would behave identically.

And it happened that the value of BaseAddress was the base address of progwrp in my Russian testing VM. This meant that when a DLL did not exist, like dwmapi.dll, the succeeding LdrGetProcedureAddress calls would use the address of progwrp to determine the presence of the functions. This would always be successful as progwrp exports these functions, and causes the address passed to the function pointer in progwrp to be the address of the progwrp function stub itself, causing an infinite loop.

As a result, the addresses are not initialized to 0: progwrp_32.zip

Note: this issue is not directly related to the original TLS issue.

[EDSln]

Are you running Russian language Windows XP?

Yes, I have an OS with Russian language. But that's not the problem, because on another computer, which is also Russian XP SP3, the browser starts and works, both with progwrp that comes in the v124 installer and with the newest one. But I have noticed that the problems occur on systems installed years ago, but they are updated and should be no different than OS's installed and updated recently. Especially since v122 works on either one.

It still won't start. New dump: https://mega.nz/file/PqgH2ZgI#8_mwKRTq60Qsc1-Jy-odCCcreP22zR8ZrjiyiOLHPvA

[JoachimHenze]

I can confirm, all on XPSP3 german:

• "Supermium 122.0.6261.152 (R6) x86" starts up fine with its stock progwrp.dll.

• "Supermium 124.0.6367.245 prebuild x86 with its stock progwrp.dll 1.1.0.5016 from win32ss" does not start up.

• "Supermium 124.0.6367.245 prebuild x86" with all below: a.) D3DCompiler_XP.dll extracted from chrome-xpapi-adapter_x86.b5064-wD3D9accel.zip from https://github.com/IDA-RE-things b.) progwrp.dll v1.2.0.5064 renamed from "chrome-win7-xp-api-router.dll" which itself extracted from "chrome-xpapi-adapter_x86.b5064-wD3D9accel.zip" from https://github.com/IDA-RE-things c.) chrome-xpapi-adapter.dll v1.2.5065 renamed from "chrome-xpapi-adapter.5065.dll" which itself extracted from "chrome-xpapi-adapter.5065.for.testing.zip" from https://github.com/IDA-RE-things This combination works for me. For your convencience here is that compressed again: 5064_5065_combination_that_works.zip

It is getting a bit confusing to setup and rename all of that, but it works for me.

[IDA-RE-things]

@JoachimHenze , now I have updated the distributive and all requered DLL's included in main archive. Separate 5065 dll was only for testing on machines, having problem with previous build.

[win32ss]

Anyway, if anyone still having TLS issues wants to test progwrp, here is a DLL that writes a debugging log to tls_log.txt: progwrp_dbg_log.zip

[JoachimHenze]

To help you @win32ss I tested with your progwrp_dbg_log.zip v1.1.0.5017 on XPSP3 and the following cmd-line: C:\Programme\Supermium124test\chrome.exe --disable-remote-fonts --disable-alternate-ds --safebrowsing-disable-download-protection --in-process-gpu --compact-ui --disable-features=DownloadBubble --ungoogled-supermium and the resulting log looks like that: tls_log.txt

It hang during the startup, and stalled almost the whole OS. With some patience I could kill it in the taskmgr.

[win32ss]

I can tell that it never got to load chrome.dll, as only chrome.exe and chrome_elf.dll are represented in the TLS slots (chrome_elf is in chrome.exe's import directory so the PE loader does allocate a TLS slot for it automatically).

But the previous two iterations of progwrp posted in this thread should not have the infinite loop issue anymore. I think you should you check the offending threads in a tool such as Process Hacker or Process Explorer; it's possible the thread that loads chrome.dll is stuck in such a loop.

[EDSln]

I did the logs. tls_log.zip

I didn't notice anything unusual in Process Explorer, so I made a detailed report of Supermium startup in Process Monitor. There are two files of one log in the archive, in Process Monitor format and in CSV. https://mega.nz/file/HvpwTZKQ#_n7KCHpVa4uu24YXV1HvRGlbfGhRuP0VnHThvWRbFNQ

[EDSln]

other (eng xp install) users could test this: move all pak files except en-US.pak file to another folder. replace the original progwrp.dll and start the browser, if successful close the browser. move the other pak files back to the locales folder and see if the browser now starts in the OS locale.

No, uninstalling all language packs didn't help, still fails to launch. Moreover, on another computer with the same Russian language, the browser works. There are no antiviruses, so there's nothing to block. I also tried uninstalling something I had problems with before, namely C++ 2015-2019 and Prio, that didn't fix the crash either.

That said, with chrome-xpapi-adapter_x86.b5065-wD3D9accel from @IDA-RE-things the browser works fine, no problems.

[EDSln]

i know about the progwrp.dll alternative but we are here to solve this with the progwrp file provided by win32ss.

I just clarified that it's not about the browser itself or my OS, because it might seem like something is broken in my OS.

don't know in how many languages the xp iso's were released, never used a language pack.

Updates came out in 25 languages, probably the same number of localized ISOs. Plus there were a lot of MUIs coming out, I don't remember exactly how many, but more than 50. I have both OS's originally Russian, no MUI's installed. But on one the browser launches, and on the other it doesn't.

[rereser]

@EDSin, you posted an hour ago the browser runs with the alternate dll. so your xp issue with the original progwrp.dll 1.1.0.5017 is still relevant.

tested supermium 124 again with the latest posted progwrp.dll. the browser now runs on my system without the need for deleting pak files. so my previous problem solving post was wrong and is deleted.

[EDSln]

@edsin, you posted an hour ago the browser runs with the alternate dll. so your xp issue with the original progwrp.dll 1.1.0.5017 is still relevant.

Yes, I meant that the problem is not with chrome.exe itself, but with progwrp.

[win32ss]

I looked at the TLS log. I noticed that the iteration of the TLS index is wrong. It should be 0-1-2-3, but it is 0-1-0-3-2 instead. The Ldr Data Table is presenting DLLs in an unusual order, and either chrome.exe has been loaded twice or another DLL has been loaded and failed the TLS loading. With this in mind, the TLS loading code was updated to only include modules loaded through progwrp's TLS slot allocator, restoring the order. The logs also include the DLL name to identify the modules by name. progwrp_dbg_log.zip

[JoachimHenze]

@win32ss I tried your most recent progwrp_dbg_log.zip v1.1.0.5018 from your comment 20 minutes ago https://github.com/win32ss/supermium/issues/686#issuecomment-2189324440 on XPSP3german x86.

On the first run it displayed a lot of garbage output on my whole screen for some seconds, until I killed it with the taskmgr. On the 2nd run it only displayed garbage on part of the screen and ended itself after a few seconds.

In both cases it created a tls_log.txt with 0 bytes size. It doesn't work yet to bring up the 124_pre.

The chrome-xpapi-adapter_x86.b5065-wD3D9accel from @IDA-RE-things works fine though.

Edit: I just saw that I (accidentally) still used the command line C:\Programme\Supermium124test\chrome.exe --disable-remote-fonts --disable-alternate-ds --safebrowsing-disable-download-protection --in-process-gpu --use-angle=d3d9 --ignore-gpu-blocklist --compact-ui --disable-features=DownloadBubble --ungoogled-supermium here.

I will retry without the --use-angle=d3d9 --ignore-gpu-blocklist again...

[EDSln]

@win32ss Yay! It's finally up and running! 👍 On both systems where it wouldn't start before. tls_log.zip

[JoachimHenze]

Yes, with just C:\Programme\Supermium124test\chrome.exe --disable-remote-fonts --disable-alternate-ds --safebrowsing-disable-download-protection --in-process-gpu --compact-ui --disable-features=DownloadBubble --ungoogled-supermium the new progwrp v1.1.0.5018 from win32ss does bring up the browser fine for me again. I can browse the web again like that. It does create an empty tls_log.txt with 0 bytes size and holds a lock on that file during the browsers lifetime. Creating that log should be stripped from the final thing for the next release.

But still: 1.) poor performance on the Pulsebutton is still a thing 2.) audio stuttering on youtube is still a thing 3.) not having HW acceleration is still a thing 4.) and I notice a small glitch here when doing enumerations within a github ticket when placing a minus in the bottom-most line of a comment, then writing some words, and then hitting enter

I do know that the ida-re-version does overcome at least problem 1,2,3 for me, so I will switch back to that again now. I am not sure where problem 4 originates from.

[JoachimHenze]

I tested: problem 4 does not happen with the ida-re version, but it does happen reliably for me with your v1.1.0.5018. Please try to fix that. Do you want me to create a fresh ticket for it, or is mentioning it here enough?

[win32ss]

Creating that log should be stripped from the final thing for the next release.

Yes, that log and all associated code will be hidden behind an #ifdef and will not be a permanent fixture of progwrp.

But the fact that the new TLS code works on all systems is important, as this new iteration allows for dynamically loading third-party proprietary binaries with TLS directories on XP in addition to ones built explicitly for the progwrp TLS API. This includes several Chromium components such as soda.dll and widevinecdm.dll which are downloaded by the browser on request.

I tested: problem 4 does not happen with the ida-re version, but it does happen reliably for me with your v1.1.0.5018. Please try to fix that. Do you want me to create a fresh ticket for it, or is mentioning it here enough?

Yes, put this in a separate ticket. This seems to be more like a font rendering issue than a thread local storage issue.