Detach portable version from CRT installed in system

[CaptainFlint]

What should be added?
Chatterino (at least in its portable mode) should include VC++ runtime in its local directory, or be statically linked with it, so that the CRT libraries installed in Windows were not used.

Why should it be added?
Several times I've had an issue, that when some program is installed or updated, and a new version of CRT is installed along, Chatterino begins to crash on start (report mentions an exception in ucrtbase.dll). If I restart Windows, Chatterino starts working again, without problems. But obviously, Chatterino is normally used while watching a stream, and losing several minutes for a computer restart is not an easy option (not to mention, that restart means closing and reopening all the programs, documents, browser tabs; losing all the active work, like undo-redo history in editors; etc., etc.). I tried to copy the CRT libraries directly into the Chatterino folder, but they were completely ignored, and were loaded from system32 instead. If a program is called portable, it is expected not to rely so heavily on the system libraries.

Chatterino is the only program where I've noticed this weird behaviour with crashes on updating CRT. I have lots of other programs, and none of them crashes like that. I took a look at how other programs are packaged, and noticed that many of them have a copy of CRT inside their installation directory. Some examples are: Mozilla Firefox, foobar2000, TortoiseGit, paint.net (the native components), Miranda NG... I hope Chatterino could be modified in a similar way to avoid this extremely annoying issue.

[fourtf]

This is actually pretty interesting! We can't statically link chatterino because of Qt's license (or at least that's my understanding) and it hasn't occurred to me that me might be able to simply include a copy of the runtime files. Thank you for this suggestion, I will look into that tomorrow!

[CaptainFlint]

That's a good point about the licensing, I have no idea if MIT and GPL could be combined. But I mostly meant static linking with the CRT (that is, using /MT option of cl.exe instead of /MD). That can be a bit tedious, because it would require rebuilding Qt from sources with the same static CRT linking. But the Qt still can be compiled as DLLs, so the license should not become an issue in this scenario, it's same LGPL dynamic library linkage. The only difference would be, they won't have the CRT dependencies in the import tables.

But just including the CRT libraries into the package should be easier.

[fourtf]

I suppose compiling all the libraries myself with /MT would be the best option

[NeelAPatel]

Please make this a priority, Currently crashing for the exact reason listed here: ucrtbase.dll.

From everything I have read, re-installing windows seems like the ONLY option I have to fix this issue. If any of you have workarounds, please tag me in it!

[CaptainFlint]

@NeelAPatel For me each time it was fixed after a reboot, no reinstallation of anything was required. If that does not work for you, I'd suggest you reinstall Chatterino itself (and reboot the PC). Or if you are using portable version, reinstall the CRT libraries.

[NeelAPatel]

@CaptainFlint Yes my first action was to reboot my pc as well. Also tried:

• uninstalling the CRT libraries + Chatterino, reinstalling from .exe ==> Error
• uninstall everything, install CRT library from the README, Portable version ==> Error

Just in case, here's what I'm facing:

[CaptainFlint]

@NeelAPatel Looks like we have different issues. In my case the exception code was 0x40000015. But I'm working in Win7; not sure if that could affect it.
Maybe try a different Chatterino version? Mine is 2.2.2-fix (af89e14), and according to the executable's timestamp, so is yours; but maybe another version would work better in your particular environment.

[NeelAPatel]

Sorry to report that all my random attempts at different versions have failed.

• Latest nightly
• 2.2.2-fix
• 2.2.3-beta and beta2
• 2.1.5-4
• 2.1.3
• 2.0.4-beta

[CaptainFlint]

That makes me think, there's something seriously wrong with your system. Maybe not even in the CRT libraries (the "faulting module" pointing at ucrtbase.dll means that the exception ends up there, but it does not mean that DLL is the actual source of the issue). Unfortunately, I have no idea what could be wrong here, but since such a wide range of versions show the same issue, I doubt it can be solved by static CRT linkage.

Unless anybody else has better ideas, you could try to do various experiments, narrow down the area where the origin of the probelm could be. Set up a virtual machine with clean Windows, check if Chatterino works there. Install there the same components that you have on your main computer: Windows updates, CRT versions, the most intrusive applications (which inject their DLLs into other processes). Maybe it's one of them. Also, it's worth checking the integrity of your system files with sfc, you never know. And you could try to build Chatterino from source; it's a bit complicated, but perfectly doable; it may help (if the issue lies in some library binary incompatibility). It's a long and tedious list, but I don't know what else to suggest.

[NeelAPatel]

well I guess apologies are to be made here. I believe my problem is definitely a windows issue as I reinstalled my windows and it still didn't work. I should've said earlier that I'm running Windows insider version 21301, so that is probably the source of my problems. (Irony is that it HAS worked on this build before)

Thank you for trying to help though!

[leon-richardt]

Posting on this issue as it explitcitly mentions ucrtbase.dll. The following is a transcript of what a user posted on the Chatterino Discord Server, reposted here for easier reference.

Transcript

the same thing is happening to me, with the crash in "ucrtbase.dll", as others have posted on discord.
I'm running insider Builds, but the problem started appearing once I upgraded from (I think) 2.2.1 to a higher version when I got prompted to update. ever since then, all versions crash.
The crashes started without a new build of Windows on my machine getting rolled out at the time. i.e. it was running fine with whatever build was running two weeks ago. I updated chatterino and ever since then all versions keep crashing. without any windows updates/reboots in between it working and it crashing.

I think the most promising thing I saw in issues was that comment about statically compiling in the runtime instead of relying on the version on the system

still I find it strange that it happened after a chatterino update without anything about my machine/environment changing

naturally I did all the common sense trouble shooting steps already, like removing settings, reinstalling vc runtime, etc etc, but to no avail

there isn't a binary debug build for windows by chance that emits usable stack traces or something like that, or is there?

the random crashes never happened for me

[...] it ran for weeks straight for me, until I would reboot to install a new windows build and then keep running rock solid before this thing happened after that one chatterino update I was talking about.

i mean I can't entirely discount the possibility that it's the Windows Insider build causing it. at least one other guy in github issues was also on insider builds. but it's still strange that it happened between chatterino updates without apparent changes to my windows build at the time

i'm on rs_prerelease, so the newest available basically

i think it really could be the insider builds, because I just tried the last 3 chatterino versions with the installer and everything in windows sandbox. that environment is as squeaky clean as it gets, but is the same build as the host machine. the crashes happen there too

the ucrtbase.dll from event viewer also has a version that matches my exact build

I recognize that insider builds can't reasonably be supported, but maybe it'd still be good to statically compile in nc runtime or at least look for the DLL in the .exe path first instead of relying on the underlying system being sane

yeah it's fine on the latest version of beta and release preview, which is 19042.782

if it really just affects builds from 21301, maybe that helps triage the issue

dev 21286 works fine

yeah so all the newest versions in 20H1 and 20H (Release, Insider Slow, Beta) are fine. RS_PRELEASE (dev) is fine in 21268, but broken (i.e. crashes on start after displaying a white window briefly) in 21301. I couldn't test the dev Builds in-between 21268 and 21301 (21592 and 21296).
Not sure if Microsoft's telemetry is enough to get to the bottom of the problem or if there's something that could/should be done on Chatterino's side. Either by mitigating it in Chatterino or by reporting the Bug to MS via Feedback hub to make sure the breaking change doesn't land in downstream releases.
I couldn't find much other information about issues with the build, save for people online reporting problems with nVidia drivers and that crashing certain games. I don't experience those problems though. Feedback Hub has nothing on the issue.

Everything was tested on a clean install of all the relevant build, the error is visible in the Application Eventlog (as reported on GitHub) like here:

for each windows build i tested, I installed chatterino 2.2.1 to 2.2.3-beta2, resetting checkpints to the clean insall in between chatterino installs and tests

so pretty sure RD_PRERELEASE (dev) build 21301 is the culprit here

i'll wait fot the next build of Windows dev channel comes out, and if that either doesn't help or it takes too long, then I'll set up a Chatterino dev environment and try to debug it. I'm not very well versed in debugging Qt applications though.
Anyway. I hope this information helps getting to the bottom of this particular issue a bit. If people keep reporting it in GitHub issues, maybe make sure they're not running Windows Build 21301.

Summary: User has extensively tested different combinations of Chatterino versions and Insider Windows builds. They have identified Windows builds from 21286 and before to work correctly, while build 21301 crashes on startup. There are two more builds between these two versions (21592 and 21296) that have not been tested so far.

[NeelAPatel]

Made an FBH post yesterday, hopefully it might help: https://aka.ms/AAb4n7p

[cineafx]

I had the same issue on stable Windows 10.0.19042 Build 19042 yesterday. But a restart fixed it for me as well.

when some program is installed or updated

On that day the following programs had updates before the issue occurred:

• Adobe Creative Cloud
• Adobe Acrobat DC
• Origin
• MS Edge

This is the Event Viewer content as well as all the referenced error logs: Chatterino 2 crash.zip

This is a subsection of the Report.wer:

[...]
Sig[3].Name=Fault Module Name
Sig[3].Value=ucrtbase.dll
Sig[4].Name=Fault Module Version
Sig[4].Value=10.0.19041.789
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=2bd748bf
Sig[6].Name=Exception Offset
Sig[6].Value=000000000007286e
Sig[7].Name=Exception Code
Sig[7].Value=c0000409
Sig[8].Name=Exception Data
Sig[8].Value=0000000000000007

Exception Code c0000409 means STATUS_STACK_BUFFER_OVERRUN

[Nerixyz]

Chatterino (at least in its portable mode) should include VC++ runtime in its local directory

This should be possible by removing --no-compiler-runtime when deploying Qt:

windeployqt --no-translations --no-opengl-sw --dir bin bin/chatterino.exe

listdlls now shows Chatterino using the local CRT.