OBS 32.1.2 crashes when opening YouTube Chat Dock or Custom Browser Dock (libcef.dll / CrBrowserMain)

J

jiu.mikaduki

New Member
Hello,

I have a reproducible crash in OBS Studio 32.1.2.

System
- OBS Studio 32.1.2 (64-bit)
- Windows 11 25H2
- NVIDIA RTX 4060
- Intel Core i5-13400F

Problem

OBS crashes whenever I open the built-in YouTube Chat Dock or any Custom Browser Dock.

The crash is 100% reproducible.

If I launch OBS and immediately close the YouTube Chat Dock before it finishes loading, OBS continues running normally.

If I leave the dock open for a few seconds, OBS crashes.

The same behavior happens with Custom Browser Docks.

Browser Sources themselves can still be used, but browser docks trigger the crash.

This issue started around one week ago.

Things I already tested

- Created a completely new OBS profile
- Cleared obs-browser cache
- Renamed obs-browser configuration folder
- Disabled third-party audio plugin (VoiceConsult)
- Updated NVIDIA driver
- Browser cache recreated automatically
- Same behavior every time

Additional information

This OBS setup contains many Browser Sources (around 70 across all scenes), but the crash is triggered simply by opening a Browser Dock.

The crash log consistently points to:

- libcef.dll
- CrBrowserMain
- obs-browser.dll (CefBrowserHost::CreateBrowserSync)

Crash log:
(attach)

OBS log:https://obsproject.com/logs/oB9hL2bBBKBeOEOP
(attach)

The crash happens only when opening:
- YouTube Chat Dock
- Custom Browser Dock

Browser Sources inside scenes work normally.

If I close the Chat Dock immediately after startup, OBS continues running.


Could you please let me know if this is a known issue with OBS 32.1.2, Chromium (CEF), or Windows 11 25H2?

This crash also occurs even with a newly created OBS profile, so it does not seem to be related to profile corruption.

Thank you very much.
 

Attachments

A new empty scene collection uses only ~358 MB.


My normal scene collection immediately uses ~6.3 GB after startup.


This strongly suggests the issue is related to something loaded by the scene collection rather than OBS itself.
 
Additional information:

I tested again with a smaller Monster Hunter scene.

Before the crash, OBS Studio itself was using about 1.5 GB of RAM with that scene.

When I opened the YouTube Chat Dock / Browser Dock in that state, OBS crashed.

After restarting OBS, the same Monster Hunter scene started with much lower memory usage, around 271 MB.

After that restart, I opened the chat dock again, and this time OBS did not crash.

So the issue seems inconsistent:
- The same scene can start with very different memory usage.
- The dock can crash OBS in one session, but not after restarting OBS.
- This does not seem to be caused only by high memory usage.

The same setup was working normally until about two weeks ago.
 
Code: 
Unhandled exception: 80000003
Date/Time: 2026-06-30, 01:54:02
Fault address: 7FFEF222FB20 (c:\program files\obs-studio\obs-plugins\64bit\libcef.dll)
libobs version: 32.1.2 (64-bit)
Windows version: 10.0 build 26200 (release: 25H2; revision: 8655; 64-bit)
CPU: 13th Gen Intel(R) Core(TM) i5-13400F


Thread 8FA8: CrBrowserMain (Crashed)
Stack            EIP              Arg0             Arg1             Arg2             Arg3             Address
000000C6BBD9D1C0 00007FFEF222FB20 000042AC03099100 000000C6BBD9D778 000000C6BBD9D778 000000C6BBD9D6C0 libcef.dll!0x7ffef222fb20
000000C6BBD9D640 00007FFEF222F785 0000000000000000 000000C6BBD9D778 0000000000000578 000000C6BBD9DB10 libcef.dll!0x7ffef222f785
000000C6BBD9D720 00007FFEF222FB39 AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA libcef.dll!0x7ffef222fb39
000000C6BBD9D750 00007FFEF25FD651 0000000000000000 0000000000000000 0000000000000000 2F302F3700000600 libcef.dll!0x7ffef25fd651
000000C6BBD9D8C0 00007FFEF25FD5AB 0000000000061220 000042AC01366600 000000C6BBD9DC30 000002580000012C libcef.dll!0x7ffef25fd5ab
000000C6BBD9DA30 00007FFEF35C3326 0000000000000000 0000EA40305D8C26 AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA libcef.dll!0x7ffef35c3326
000000C6BBD9DB80 00007FFEF2EF4B7F 000042AC03820740 00007FFEF3D35E01 0000EA40305D8DA6 000000C6BBD9DDE0 libcef.dll!0x7ffef2ef4b7f
000000C6BBD9DC00 00007FFEED89F5D3 000042AC03860BD0 00007FFEEC9ABDC4 000042AC01C2C500 000000C6BBD9DD68 libcef.dll!0x7ffeed89f5d3
000000C6BBD9DC90 00007FFEF2EE9F5A 0000EA40305D8B76 000000C6BBD9DE10 000042AC030A5E80 00007FFEEE9C2FE9 libcef.dll!0x7ffef2ee9f5a
000000C6BBD9DD90 00007FFEED72A295 00011A1900000001 0000110500000000 0000000A00000004 0000000100000001 libcef.dll!0x7ffeed72a295
000000C6BBD9DFA0 00007FFEECA01D9F 0000000000000000 000042AC02B8A800 000000C6BBD9E3A0 000042AC02286150 libcef.dll!0x7ffeeca01d9f
000000C6BBD9E2E0 00007FFEECAE5F1A AAAAAAAAAAAAAAAA AAAAAAAAAAAAAA00 AAAAAAAAAAAAAA00 00006EAC002CE598 libcef.dll!0x7ffeecae5f1a
000000C6BBD9E4C0 00007FFEEC99D9CE 0000000000000000 77E0B30900000000 000042AC013BFA80 00007FFEEE9C2FE9 libcef.dll!0x7ffeec99d9ce
000000C6BBD9E570 00007FFEEC99D55B 000000C6BBD9ECE8 000000C6BBD9EAD8 000000C6BBD9ECE8 00007FFEEC9412D5 libcef.dll!0x7ffeec99d55b
000000C6BBD9EA10 00007FFEEC9B8BE7 000000C6BBD9EB10 000000C6BBD9EB08 00006EAC00362C00 0000000000000000 libcef.dll!0x7ffeec9b8be7
000000C6BBD9EA70 00007FFEEC9B8907 0000000000000000 000000C6BBD9EFA8 00000000000000E8 000001DA4B3A0000 libcef.dll!0x7ffeec9b8907
000000C6BBD9EC80 00007FFEEC93CCF1 000000C6BBD9EF68 000001DA435F65A0 000000C6BBD9EFB0 0000000000000000 libcef.dll!0x7ffeec93ccf1
000000C6BBD9EEC0 00007FFFBC4841CE 000001DC89C5F6C0 0000000000000000 000000C6BBD9EFA8 000001DA1BD3A060 obs-browser.dll!CefBrowserHost::CreateBrowserSync+0x11e
000000C6BBD9EF50 00007FFFBC47DD3E 0000000000000000 000001DC9CF31040 000042AC000AB000 0000000000000000 obs-browser.dll!`QCefWidgetInternal::Init'::`2'::<lambda_1>::operator()+0x46e
000000C6BBD9F1B0 00007FFFBC48864A 000001DC9CF31040 000001DA22507A60 00006EAC00221330 000000C6BBD9F3D0 obs-browser.dll!`anonymous namespace'::task_execute+0x3a
000000C6BBD9F1E0 00007FFEEE9AF03D 000000C6BBD9F2E8 00007FFEEE9AA5FB 00006EAC00221270 000000C6BBD9F444 libcef.dll!0x7ffeee9af03d
000000C6BBD9F280 00007FFEEEA35D07 00006EAC00221258 000042AC0001B720 00006EAC002211A0 00007FFEED7C0228 libcef.dll!0x7ffeeea35d07
000000C6BBD9F4C0 00007FFEF21F2E05 000000C6BBD9F620 00007FFEF7F41B28 0000000000000008 0000000100000000 libcef.dll!0x7ffef21f2e05
000000C6BBD9F580 00007FFEED5C11CE 000000C6BBD9F6E0 00007FFEEEDF594F 0000000000000000 0000000000000000 libcef.dll!0x7ffeed5c11ce
000000C6BBD9F5F0 00007FFEED7BE916 0000000000000008 000000C6BBD9F790 0000000000000038 000000C6BBD9F790 libcef.dll!0x7ffeed7be916
000000C6BBD9F670 00007FFEED5DA37F 0000000200000000 0000003100000000 000000C6BBD9F810 0000000000000000 libcef.dll!0x7ffeed5da37f
000000C6BBD9F740 00007FFEEC9F06E6 000001DA1C487FE0 0000000000000000 0000000000000000 0000000000000000 libcef.dll!0x7ffeec9f06e6
000000C6BBD9F7E0 00007FFFBC46EF3E 0000000000080001 000001DA164C5340 0000000000000000 0000000000000000 obs-browser.dll!BrowserManagerThread+0xe
000000C6BBD9F810 00007FFFBC47275B 000001DA00000000 0000000000000000 0000000000000000 0000000000000000 obs-browser.dll!std::thread::_Invoke<std::tuple<void (__cdecl*)(void)>,0>+0xb
000000C6BBD9F840 00007FFFBC4BE022 0000000000000000 0000000000000000 0000000000000000 0000000000000000 obs-browser.dll!thread_start<unsigned int (__cdecl*)(void *),1>+0x5a
000000C6BBD9F870 00007FF8011CE957 0000000000000000 0000000000000000 000004F0FFFFFB30 000004D0FFFFFB30 kernel32.dll!0x7ff8011ce957
000000C6BBD9F8A0 00007FF8027A7C1C 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x7ff8027a7c1c
...
This is certainly crash of the Browser source in OBS.

As for the RAM - you may try to monitor demand and fails via the Resource Monitor > Memory tab > Hard Faults column (search online how to launch Resource Monitor util in Windows). You are looking for the peaks in this column. What, I think, you may see there, is peak of hard faults right before the crash of the Browser source. If this the case then, in my opinion, only step you can do (with this PC) is to simplify the task for OBS.
 
Thank you for your suggestion.


I will definitely check the Hard Faults in Resource Monitor.


However, I think there is another important clue that may not have been clear in my original post.


The memory usage is not consistent, even with exactly the same PC and the same scene collection. Sometimes OBS starts with much lower memory usage, and other times it starts significantly higher.


Also, this same scene collection was working normally earlier that day. The problem appeared only after changing some Browser Source-related settings and testing other OBS settings.


Because of this, I suspect there may be something related to Browser Source / CEF initialization or state management, rather than only the total amount of RAM being used.


I'll monitor Hard Faults as you suggested and report back with the results.
 
I have already started splitting my original scene collection into multiple smaller scene collections. I'm also consolidating audio sources and simplifying the OBS architecture without removing the interactive features.
 
Even after splitting the original scene collection into a lighter version, the memory usage immediately after startup is still inconsistent.

If the issue were only that the scene collection is too heavy, I would expect the lighter version to start with roughly the same memory usage each time.

But even the lighter version sometimes starts much lighter and sometimes much heavier, with the same PC and same scene collection.

This is why I suspect something related to Browser Source / CEF initialization, cache, or state management.
 
The important part is not that OBS crashes when memory usage is high.


The important part is that the same scene collection does not always start with the same memory usage.


When it starts "light", Browser Docks work. When it starts "heavy", opening a Browser Dock crashes OBS.


I'm trying to understand what causes these two different startup states.
 
At this point, starting OBS in the low-memory state feels like an SSR pull.

That's why I'm especially interested in why the same scene collection sometimes starts in a “good state” and sometimes in a “bad state”.
 
You must log in or register to reply here.
Back
Top