[Windows 11] OBS crashes during regular Windows shutdown

[riidefi]

Operating System Info

Windows 11

Other OS

No response

OBS Studio Version

30.1.2

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/krQyPY0gGII9KRai (previous log) https://obsproject.com/logs/qaOHGs2BO4ydjHpB (current log)

OBS Studio Crash Log URL

https://obsproject.com/logs/FqCrvAHYdESIIupf (crash)

Expected Behavior

I would expect the OBS application to cleanly close during a standard Windows shutdown interaction.

Current Behavior

A crash dialog appears noting the exception being raised in the OBS application.

Steps to Reproduce

1. Open OBS
2. Stream to Youtube
3. Stop streaming
4. Shut down Windows while OBS is still running (but not streaming). Allow Windows to attempt to close OBS itself.

Anything else we should know?

No response

[Andre-Satorres]

Duplicate of #10833?

[Andre-Satorres]

Btw I just tested it here and I didn't even had to stream to YT, just shutdown Windows 11 with OBS still open.
Then, when the PC restarted, I open OBS again, but received this dialog: (it is in portuguese BR)

"Safe Mode
OBS Studio did not shut down properly last session.
Would you like to start in safe mode (third-party plugins, scripts, and websockets disabled)?
Run in safe mode / Run in normal mode"

[Fenrirthviti]

Possibly, there's not a lot of information in 10833 on what is causing it. Might be related, might not.

[Andre-Satorres]

I think it is related to this logic:
On obs-app main, a sentinel file is created. But it is deleted only if the function run_program() ends, which I believe might only happen if the window is closed (on click)

Then, next time application is started, the sentinel file already exists, and unclean_shutdown is set to TRUE, and trigger the message present in the log, and also in the #10833 title.

We should get a product decision: if this message is annoying and we want to get rid of it, let's think on a different approach rather than this sentinel file.

I believe we should put this "delete_safe_mode_sentinel" as required action on application closure

[riidefi]

We should get a product decision: if this message is annoying and we want to get rid of it, let's think on a different approach rather than this sentinel file.

In the case of this issue (#10848), it was not merely a spurious an error dialog upon subsequent application launch (perhaps a false positive), but a genuine application crash (with an error dialog (invalid instruction executed) and a crash report) during the Windows shutdown process. In particular, an invalid instruction was executed thereby invoking a signal handler. See the attached crash report.

Best

[PARTYMANX]

Without streaming, I have also been able to consistently recreate this issue. It has become immensely frustrating to not be able to shut my computer down without first closing OBS as the crash handler blocks shutdown (separate issue, it probably shouldn't be able to do this.).

[derrod]

Please provide a crash log.

[PARTYMANX]

Log: https://obsproject.com/logs/qxiCUPiOkdvLabAF
Crash Log: https://obsproject.com/logs/U3IusQ3YEGpbr4aQ

[RytoEX]

Without streaming, I have also been able to consistently recreate this issue. It has become immensely frustrating to not be able to shut my computer down without first closing OBS as the crash handler blocks shutdown (separate issue, it probably shouldn't be able to do this.).

Are you logged into to YouTube via account connection in OBS Settings (Settings -> Stream)? Have you logged into the YouTube Control Panel for their additional browser docks? Do you have any other browser docks open? Just trying to narrow down a reliable set of steps to reproduce.

[PARTYMANX]

In my case, I am logged into Twitch and use the chat, activity feed, and stream information panels docked.

[NormHarrison]

I know this isn't a high priority issue (which may not even be related to OBS code specifically) and while there is still more testing to do (a lot of which I am not sure how to approach yet), I think I was hopefully able to narrow down the problem at least some and thought it was enough to be worth sharing here.

I was able to reproduce the same issue fairly easily on a system I setup, and long story short, I think it is related to Nvidia GPUs; more specifically recent driver versions and some interaction they have with the version of libcef in use.

I first tried making it occur in both a Windows 10 and 11 VM running via VMware Fusion on a Mac, neither of which exhibited the issue. I then installed the most recent version of Windows 11 on an older physical system with a Sandy-Bridge-E Xeon and a GTX 760 in it, which is where some of the more interesting behavior began to appear.

To begin, I used the older driver that Windows chose from Windows Update (it was one from 2020, although I can list the exact version if desired). NVENC was not available when using this driver, and when using the software H264 encoder, OBS reported no crash upon shutting Windows down while it was running. I then tried with the most recent driver for this GPU available on Nvidia's website (only receiving security updates), which made this issue appear. I first thought that it might be related to NVENC, but regardless of what encoding method is selected, it still crashed. Trying with a GTX 980 (on same driver version as most recent Nvidia GPUs) also produced the issue (both riidefi and partymanx also have Nvidia GPUs). Below is what/all I see appear on this system after it occurs

Seeing that the error always seems to occur in a thread that is executing specific code inside libcef, I downloaded the PDB file for the version of CEF that OBS currently uses (103.0.5060.134) available here so we could see the symbols for the functions being executed in that portion of code (both version 3.1.2 and 30.2.3 use this version). As we have seen above from riidefi and partymanx, the specific trail/chain of function calls that seem to lead to this error is:
(Scroll all the way to the right to see the added symbol data)

Thread 9F4: CrBrowserMain (Crashed)
Stack            EIP              Arg0             Arg1             Arg2             Arg3             Address
000000D9205CEA60 00007FFFF38EBC10 0000111800724A00 00007FF83CF8656E 0000000000000018 00007FFFF38CB6ED libcef.dll!base::CancelableSyncSocket::CancelableSyncSocket+0x70
000000D9205CEF30 00007FFFF1C1BCB6 00001118008F6D28 00007FFFF38D42EF 0000000000000003 000011180037C480 libcef.dll!content::IndexedDBDatabaseCallbacks::OnComplete+0x46
000000D9205CF0A0 00007FFFF1C18E63 00007FFFF943A940 000000000000001F 0000111800258170 00007190ED8A6A2E libcef.dll!content::IndexedDBDatabase::BatchGetAllOperation+0xee3
000000D9205CF0D0 00007FFFF1C172A1 00001118002557D0 00007190ED8A6A5E 000000D9205CF2A8 00001118006A01A0 libcef.dll!content::IndexedDBDatabase::PutOperation+0x5b1
000000D9205CF110 00007FFFF1C2542F 000018ECFC029F81 00007FF83AE26E9C 000000D9205CF440 0000000000001820 libcef.dll!content::IndexedDBFactoryImpl::OpenAndVerifyIndexedDBBackingStore+0x5fd
000000D9205CF290 00007FFFF1C268A0 00001118007448C0 000000D9205CF500 0000000000000000 0000000000000000 libcef.dll!std::__1::__tuple_impl<std::__1::__tuple_indices<0,1,2,3,4>,content::IndexedDBBucketStateHandle,leveldb::Status,content::IndexedDBDatabaseError,content::IndexedDBDataLossInfo,bool>::__tuple_impl<0,1,2,3,4,content::IndexedDBBucketStateHandle,leveldb::Statu+0x62
000000D9205CF410 00007FFFF1ABD231 AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA 00007FFFF398D0C7 libcef.dll!content::CacheStorageManager::DeleteStorageKeyDataDidGetExists+0x71
000000D9205CF510 00007FFFF38C1315 0000000000000010 00001118007448C0 00001118002557D8 00001118002557D0 libcef.dll!base::PowerMonitor::NotifyThermalStateChange+0x75
000000D9205CF5A0 00007FFFF3B90808 00001118009AE840 00007FFFF3A37E21 AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA libcef.dll!ScalePlane_16+0x648
000000D9205CF640 00007FFFF3B91C26 00007FFFF3A386BF 000000066DE8F63A 000000D9205CF770 00007FFFF09C283D libcef.dll!ScaleAddCols2_16_C+0xb6
000000D9205CF6E0 00007FFFF38BE7EA 000000D9205CF7F0 0000111800241808 0000000000000000 0000111800241800 libcef.dll!base::OneShotEvent::~OneShotEvent+0x6a
000000D9205CF750 00007FFFF3A383B9 00001118002418D0 00001118002C4008 000000D9205CF9A0 0000111800241808 libcef.dll!icu_71::RegexMatcher::MatchAt+0x18bd
000000D9205CF7D0 00007FFFF393DFE7 0000000000000000 000000404B0F57CD 0000719000000001 0000000600000003 libcef.dll!base::internal::PartitionMalloc+0x57
000000D9205CF880 00007FFFF4656EB4 0000000000000000 0000000000000000 0000000000000000 00007FFFF39735A1 libcef.dll!bssl::parse_message+0xc4
000000D9205CFA30 00007FFFF4656B7F 00007FFFF9EF2E1C 0000000000000017 00007190ED8A606E 0000111800244260 libcef.dll!bssl::tls_add_change_cipher_spec+0x9f
000000D9205CFB10 00007FFFF3973356 0000000000000000 000000D9205CFCE8 000000D9205CFDA8 00007FFFF398CBE2 libcef.dll!fe_loose_invert+0x3e6
000000D9205CFBC0 00007FFFF3972C81 0000000000000010 0000000000000000 0000000000000040 00007190ED8A613E libcef.dll!X25519+0x1361
000000D9205CFC20 00007FFFF46576ED 000000D9205CFD30 00007FFFF398CBE2 0000000000000000 0000000000000000 libcef.dll!bssl::read_v2_client_hello+0x33d
000000D9205CFC90 00007FFFF39198A0 000000D9205CFE48 00007FF83A7DA45E 0000000000000000 0000000000000000 libcef.dll!std::__1::__split_buffer<base::Value,std::__1::allocator<base::Value> &>::push_back+0x50
000000D9205CFD80 00007FFFF46002E2 0000020A3AC9DED0 0000000000000000 0000000000000000 0000000000000000 libcef.dll!base::trace_event::TraceConfigCategoryFilter::IsCategoryGroupEnabled+0x172
000000D9205CFE30 00007FF81380EE0E 0000000000080001 0000020A40A2DD80 0000000000000000 0000000000000000 obs-browser.dll!BrowserManagerThread+0xe
000000D9205CFE60 00007FF81381274B 0000020A00000000 0000000000000000 0000000000000000 0000000000000000 obs-browser.dll!std::thread::_Invoke<std::tuple<void (__cdecl*)(void)>,0>+0xb
000000D9205CFE90 00007FF81385C432 0000000000000000 0000000000000000 0000000000000000 0000000000000000 obs-browser.dll!thread_start<unsigned int (__cdecl*)(void *),1>+0x5a
000000D9205CFEC0 00007FF83AE2257D 0000000000000000 0000000000000000 0000000000000000 0000000000000000 kernel32.dll!0x7ff83ae2257d
000000D9205CFEF0 00007FF83CFAAF28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x7ff83cfaaf28

(The full log and crash report are also attached below)

It always seems to halt at base::CancelableSyncSocket::CancelableSyncSocket, which appears to be a class meant to abstract-away the OS-specific details of cancelable, blocking, TCP sockets. Its part of the Chromium source code included in the CEF project, and is located in the files base/sync_socket.h, base/sync_socket.cc and base/sync_socket_win.cc. Assuming the stack trace is not lying somehow, I guess it is getting halted somewhere in the constructor, though there are a few different implementations of it and I'm not sure which one is being used yet.

For now, this is as far as my testing has gone. Naively, it seems to be libcef related, though I do not know enough about the architecture of it or OBS to really say more currently. Assuming it is used for the embedded-browser panels that can be docked, the issue occurs whether or not they are open/visible. I hope that this helps someone, and if you have any additional questions, you are free to ask.

2024-09-03 19-07-26.txt
Crash 2024-09-03 19-07-41.txt