Windows 10 Capture Is Causing 0kb/s Freeze On Initial Source Capture!

setolyx

New Member
TLDR: Discovered I could reliably cause a crash to 0 kb/s by simply switching on/off a source that was captured using the Windows 10 method. Upon switching to the BitBlt capture method, I could not get my stream or obs to freeze/crash. Re-installs, driver updates, addon removal, none of these had any effect and the only fix was using BitBlt instead of the Windows 10 method.

I've tested extensively to verify this using the test stream feature, and unfortunately this isn't the kind of thing I was seeing any sort of warnings about in my logs or in the OBS logs analyzer. The 0kb/s lockup itself was NOT resulting in a crash log being produced as obs technically was not crashing. I have been reliably able to reproduce this freeze/crash with the following steps:
1) set up a window capture with the win10 capture method (in my case i was capturing Unity Editor).
2) Swap to a separate scene that does not contain the window capture, resulting in the window stopping its capturing.
3) Quickly swap back to the scene with the window capture.
4) repeat steps 2 & 3 until OBS is well cooked, tender, and can be split/shredded with a fork (AKA 0kb/s and frozen, only shutting down when killed by task manager)
^ The above process could result in a 0kb/s tank in less than a minute.

To clarify, I have tried re-installing OBS, moving to old versions, rolling back drivers, running OBS with no addons, running OBS in safe mode, etc. I'm running it with admin priv, i've tried with/without that too. The ONLY consistent factor is every single time it was during a moment where a window was starting to be captured via the Windows 10 capturing method, typically during scene swaps.

I worked around my unity editor issues by simply using BitBlt, but some applications literally do not allow capture without the windows 10 method (IE: chromium browsers) so it is virtually unavoidable and thus I can never 100% guarantee my stream won't crash due to this issue unless I can get to the root reason of why this capture method causes issues.

I'm running on Windows 10 Pro, OS Build 19045.3803 - which is above the required 1903 mentioned in obs - and I genuinely can't think of what else could possibly be contributing to this. I'm 100% certain that the windows 10 capturing is the culprit, and my suspicion is something about the initial hooking into a source causes the crash. Once the source is captured, nothing goes wrong, it is only in that initial moment of starting to capture the window that seems to trigger the 0kb/s drop and un-responsiveness of OBS.

I'm including my logs from a session today where after over 4 hours, randomly trying to enable a browser window capture (which was using win 10 capturing) caused my stream to drop to 0kb/s and require a task manager based shutdown of OBS. I've already run the log analyzer and have since fixed the issues with my audio source sample rates & device timestamps, but I doubt those were relevant to the crash. Nothing in the analyzer pointed to any issues with window capturing, etc.

So yeah! I'm mostly posting this not expecting help, but to make note of the issue, and in the odd case that anyone else went on a massive search for information regarding OBS dropping to 0kb/s, it's another thing to investigate and a likely cause if you're on Windows and know it's not a net connection issue.

Also, as a side note, something probably quite obvious if you look at my logs, I get one million instances of this type of warning/error for my browser sources (not sure if it's just the ones for streamelements but those are my actively running sources) and can't get it to go away:
[obs-browser: 'FollowSub'] Error: [Report Only] Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'none'".

Note: I've done my best to dig around in the forums and make sure this is not a duplicate post, but in the case that it is, my sincerest apologies. If not, I hope that someone can find this information useful, and perhaps this post will help save folks some suffering and distress if it is indeed not just isolated to my own PC.
 

Attachments

  • 2023-12-25 03-57-26.txt
    235.6 KB · Views: 6
Top