chatterino2
chatterino2 copied to clipboard
Chatterino
ucrtbase.dll crash [Windows]
Describe your issue
I'm just going to start with the fact that I'm 99% sure this is a windows issue, but just incase somebody has had it and fixed it with something that google searching doesn't know about, I'm opening the issue.
Somewhere around 2021-04-27 (That's the oldest crash log I can find) this started happening, was using 1f5b62e6e when the crashes originally started.
I've been able to deduce that the crashes only happen in the evening/night PST (via EST testing), Had no crashes before 6pm PST, and nothing after 5am PST.
Interestingly enough when the crash takes place, only one of my Chatterino instances crashes (main), but if the main crashes and isn't re-opened for long enough, the secondary window usually will crash (sort of like the main Chatterino is taking the bullet).
Googled options checklist:
Clear AutomaticDestinations (quick access) cache ✓
DISM.exe /Online /Cleanup-image /Restorehealth & sfc/scannow ✓
Uninstall Display Drivers ✓
idk maybe we still have a windows god of war in this circle of arch linux btw-ers
Screenshots
I've been asking people to check their crash logs for at least a week and finally somebody had the same crash
OS and Chatterino Version
Windows 10 Pro 19041.928
d59bb80 -> 1f5b62e6e | consistant between various versions in this commit range
After a little googling I found that 0xc0000409 is STATUS_STACK_BUFFER_OVERRUN. The StackOverflow thread also mentions Qt but the crash is in the app itself not ucrtbase.dll.
Edit: It might not be exactly a stack buffer overrun
Quote from here
However, this status code is also used when the runtime library encounters an unrecoverable error and terminates the process. That would be a reason why ucrtbase.dll is identified as the faulty module, even if the problem originated elsewhere. For a more detailed discussion of the above, see STATUS_STACK_BUFFER_OVERRUN doesn’t mean that there was a stack buffer overrun
After a little googling I found that
0xc0000409isSTATUS_STACK_BUFFER_OVERRUN. The StackOverflow thread also mentions Qt but the crash is in the app itself notucrtbase.dll.
Actually now that you point out 0xc0000409 I realize it does apply to #2229 & #2323 | when I originally searched I must have misspelt ucrtbase.dll so no issues came up, but copy pasting the error code brings leads me to both of them.
All mine are all the same for stable release (I have many of these but they are identical). I have found no pattern to them. They happen as I type, as it is alt+tabbed, when in game or when system is clean.
ucrtbase.dll, version: 10.0.18362.1110 Exception code: 0xc0000409 Fault offset: 0x000000000006dace Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
I have since abandoned that build for the latest nightly. By the way, actually adding version info to the exe would make this way easier to track across builds. All Chatterinos I have have no correct version resource.
P.S. My system logs contain 20 crashes by chatterino.exe, 19 of them are this error above. The 20th is within the exe itself and I am almost 100% sure it's the "remove ignored user at your own peril" bug.
Found the root cause, https://github.com/Chatterino/chatterino2/blob/0a51252b761ac4a846725ce6b6e8cf8bba5efdf4/src/singletons/NativeMessaging.cpp#L153
Call trace traces all the way back down to that function.
I guess I could make starting the ipc thing a setting if you want to use the extension
Confirm fixed in the latest nightly.
As much as I believe your God of War Windows ability, I am going to leave this issue open for a few days while I test this new commit 😁
I have unfortunately crashed | 2021-05-18 00:55:59 EST
I was going to checkback after 1 week as I have no longer gotten any crashes since 2021-05-21~ , but unfortunately I got a qt related crash which ruined my testing. I do know of someone who still gets the crashes but I myself am unable to replicate them anymore.
qt crash error incase its somehow related
Faulting application name: chatterino.exe, version: 0.0.0.0, time stamp: 0x60a17e1d
Faulting module name: Qt5Core.dll, version: 5.15.2.0, time stamp: 0x5fa4dd3b
Exception code: 0xc0000005
Fault offset: 0x00000000001f1df7
Faulting process id: 0x3a00
Faulting application start time: 0x01d74d6beb992afb
Faulting application path: C:\Users\Felanbird\Desktop\2021_05_16_chatterino2\Chatterino2\chatterino.exe
Faulting module path: C:\Users\Felanbird\Desktop\2021_05_16_chatterino2\Chatterino2\Qt5Core.dll
Report Id: 6c4495c0-6af7-4224-be2b-ae8e26188c1c
Faulting package full name:
Faulting package-relative application ID:
At least it's a different exception code this time around, but that still suggests something is broken somewhere related to memory.
back to the normal error, that's what I get for jinxing it
Faulting application name: chatterino.exe, version: 0.0.0.0, time stamp: 0x60a17e1d
Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process id: 0x4390
Faulting application start time: 0x01d751355810d16f
Faulting application path: C:\Users\Felanbird\Desktop\2021_05_16_chatterino2\Chatterino2\chatterino.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: 7f1fc466-b65a-43cb-94a6-a47c6e05a629
Faulting package full name:
Faulting package-relative application ID:
Hello, apparently somehow I trigger this bug very frequently (I don't use the extension)
I think one of the ways to reproduce this crash could be open ~110 chat tabs and wait since I got the crash very frequently but upon closing all of the tabs and leaving Chatterino open for about a week the crash apparently gone. No idea if this could help.
Crashing never seems to happen when I'm running Chatterino in debug mode
Anyways is there a way to open Chatterino in debug mode, or is it a Visual Studio debug mode?
Alright so here's my update, I went with no crashes from 05/26 to 06/06, I decided to update, now I've been using nightly as portable versions of Chatterino for as long as I can remember, but I forgot to mention it since it's basically second nature to me.
all times are EST
So when I downloaded this new version and moved my settings folder over, I eventually crashed an hour or so later, 06/06 04:36:17, so I had a thought about the fact that I'm using a new Chatterino with a brand new cache, I wonder if this is somehow related? The next crash happens at 17:09:39 EST, and I decide to haul my old cache over to this new portable instance, and after I do this, I have no crashes until around 9am EST on 06/10 when I have to restart my PC, but this doesn't cause any immediate crashes the crashes don't start until 06/10 23:54:50 EST, 06/11 01:31:00 & 06/11 02:20:20.
From then there's no crashes until 06/14 22:33:06, and then today crashes at 06/17 23:13:32 & 06/17 23:34:19, but these 2 crashes on 06/17 included 2(?) crashes that Chatterino handled and properly restarted, the problem being after the second handled crash, I was met with the following
Only after the second ucrtbase crash did I ask them to check Event Viewer to which I was informed that there was a ucrtbase crash log. (also this user has Chatterino via the installer so it's not some crazy nightly bug)
Summary: I thought I was able to replicate the issue with cache "testing", but honestly I have no idea, I can't see any world where this isn't some God of War windows issue, purely based on how often it happens in the middle of the night. 🤷
I have the same mysterious issue and have been having it for a long time. After leaving Chatterino running for days it tends to crash leaving ucrtbase.dll, version 10.0.19041.789 in the windows error log. This happens on two separate tested PC:s.
I used to stick to the old version of Chatterino 2.2.2 until Twitch implemented rate limiting of being in over 20 channels at once, https://github.com/Chatterino/chatterino2/issues/3107 which pushed me to update.
Trying to track down the reason for the bug I've done a bit of testing and for 5 days I'm running two fresh portable versions of Chatterino 2.3.4 having divided all channels I watch into two separate executable instances. One with 18 tabs open and another with 30 open. Strangely enough it only occurs on the one with 18 open of which I'm moderator in most, perhaps its connected to that?
EDIT: The old version 2.2.2 has never crashed for me due to this bug.
I also have this happen from time to time at random. Event viewer shows the same 409 exception code others have already posted. Most of the time I don't even notice the crash immediately since Chatterino is sitting in the background and disappears quietly.
I just got this too 🤔 It wasn't happening on my normal window-layout, but I used a friend's one cause he was having crashes, and it seems like that is what triggered this.
The window-layout.json has 113 tabs and 99 splits with unique channels
Happened twice to me in the past 3 days. Chatterino 2.3.5 commit [81a62764c]:
Faulting application name: chatterino.exe, version: 0.0.0.0, time stamp: 0x624c33f4
Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process id: 0x9428
Faulting application start time: 0x01d854f3993b196f
Faulting application path: C:\Program Files\Chatterino\chatterino.exe
Faulting module path: C:\Windows\System32\ucrtbase.dll
Report Id: dd638033-18c9-423d-86cb-37dfd1491638
Faulting package full name:
Faulting package-relative application ID:
Faulting application name: chatterino.exe, version: 0.0.0.0, time stamp: 0x624c33f4
Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process id: 0xcce0
Faulting application start time: 0x01d857514b178887
Faulting application path: C:\Program Files\Chatterino\chatterino.exe
Faulting module path: C:\Windows\System32\ucrtbase.dll
Report Id: 75a52754-2261-4463-a8bb-cde3eec0728e
Faulting package full name:
Faulting package-relative application ID:
A user on Whingepool forums says it's related to the amount of "user objects" in the GDI layer of Windows 10 processes
https://forums.whirlpool.net.au/archive/3qr1m6p7
"After an EXHAUSTIVE search have found the culprit – a limit of 10,000 USER OBJECTS in the GDI layer of Windows 10 per process. This can be increased to 18,000 by registry hacks. Note there is a HARD overall limit (presumably per login session) mandated by the use of 16 bit pointers in the GDI layer."
https://randomascii.wordpress.com/2020/05/10/gdi-leaks-and-the-importance-of-luck
I'm going to test this and see if it's true, I have Process Hacker open with the GDI Handle column enabled and will monitor it as I leave Chatterino open. It's currently at 279 handles
Note that this probably only relates to Fault offset: 0x000000000007286e
Edit: ~24 hours later and it's only at 304 handles, and i've been using it like I normally would Edit2: 4 days later its at 332 handles, so the issue might be something else.. Unless theres a specific condition where it spawns handles like crazy
It crashed after 5 days of being open I had WinDbg attached to it here's the call stack when it crashed:
It wasn't happening on my normal window-layout
Well scratch that, it happened on my normal window-layout too now
The window-layout.json has 32 tabs and 42 splits with unique channels
A user on Whingepool forums says it's related to the amount of "user objects" in the GDI layer of Windows 10 processes
https://forums.whirlpool.net.au/archive/3qr1m6p7
"After an EXHAUSTIVE search have found the culprit – a limit of 10,000 USER OBJECTS in the GDI layer of Windows 10 per process. This can be increased to 18,000 by registry hacks. Note there is a HARD overall limit (presumably per login session) mandated by the use of 16 bit pointers in the GDI layer."
https://randomascii.wordpress.com/2020/05/10/gdi-leaks-and-the-importance-of-luck
I'm going to test this and see if it's true, I have Process Hacker open with the GDI Handle column enabled and will monitor it as I leave Chatterino open. It's currently at 279 handles
Note that this probably only relates to
Fault offset: 0x000000000007286eEdit: ~24 hours later and it's only at 304 handles, and i've been using it like I normally would Edit2: 4 days later its at 332 handles, so the issue might be something else.. Unless theres a specific condition where it spawns handles like crazy
If GDI leaks is the reason this is happening, would it be possible to implement preventive measures? https://www.deleaker.com/blog/2021/12/16/gdi-leaks-how-to-identify-and-fix-them/
Unfortunately I don't have enough experience on how but looking up "GDI leaks" and similar list some examples for prevention.
This shouldn't happen with the latest nightly version, and definitely not in the upcoming stable release. If you're able to reproduce this on the latest nightly version, please re-open this issue!
