When I update OBS to the latest version and open it, it crashes and does not open

[carlosnewmusic]

Operating System Info

Windows 11

Other OS

No response

OBS Studio Version

28.0.1

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/qBF1jQUIZJOPGm1j

OBS Studio Crash Log URL

No response

Expected Behavior

The programme to start normally

Current Behavior

the programme crashes as soon as it starts

Steps to Reproduce

1. I run the programme
2. the programme is opened in the background, with a pop-up window in front of it.
3. clicking yes or no on the scrolling window closes the programme.

Anything else we should know?

No response

[carlosnewmusic]

I also tried and failed to reproduce this on my Mac Studio. Hopefully the fix is related to issue #7287, or at least the combination of multiple Virtual Camera issues on Mac bumps up the priority for each.

I also have the virtual camera enabled :/ but this error is in windows 11.

[PatTheMav]

The issue report is not complete - a crash log is missing, as are concrete reproduction steps:

• What does "Program is opened in the background" mean (you can't open OBS "in the background")
• What does "a pop-up window in front of it" mean - what is the pop-up window, to which application does it belong, how does one reproduce this window?
• Where does the "scrolling window" come from? Which application does it belong to? What are the "yes or no" buttons?

Please provide the additional information, as the issue report is non-actionable in its current state.

[attaboyBrad]

I also tried and failed to reproduce this on my Mac Studio. Hopefully the fix is related to issue #7287, or at least the combination of multiple Virtual Camera issues on Mac bumps up the priority for each.

I also have the virtual camera enabled :/ but this error is in windows 11.

Apologies--I thought I was replying under a different thread entirely. Not sure how my comment ended up here. Best of luck.

[carlosnewmusic]

The issue report is not complete - a crash log is missing, as are concrete reproduction steps:

* What does "Program is opened in the background" mean (you can't open OBS "in the background")

* What does "a pop-up window in front of it" mean - what is the pop-up window, to which application does it belong, how does one reproduce this window?

* Where does the "scrolling window" come from? Which application does it belong to? What are the "yes or no" buttons?

Please provide the additional information, as the issue report is non-actionable in its current state.

1 https://obsproject.com/logs/-R-PJkjJ0cyxI1Ay

2 mimized in the system tray

3 the error window is obs, saying if i want to save the log i have put in this error by github
4 in this window you have the option to save the log to the clipboard or not to do it.

[RytoEX]

3 the error window is obs, saying if i want to save the log i have put in this error by github
4 in this window you have the option to save the log to the clipboard or not to do it.

The message you're describing is the crash report dialog. This means that there will be crash logs located here:

%APPDATA%\obs-studio\crashes

Navigate to that folder, and upload the most recent crash log.

[carlosnewmusic]

3 the error window is obs, saying if i want to save the log i have put in this error by github
4 in this window you have the option to save the log to the clipboard or not to do it.

The message you're describing is the crash report dialog. This means that there will be crash logs located here:

%APPDATA%\obs-studio\crashes

Navigate to that folder, and upload the most recent crash log.

https://obsproject.com/logs/qBF1jQUIZJOPGm1j

[derrod]

This is a crash in Qt we've seen before but so far have been unable to reproduce. For some reason it crashes when restoring the dock layout. Specifically it crashes on this line in Qt: https://github.com/qt/qtbase/blob/6.3.2/src/widgets/widgets/qdockarealayout.cpp#L219

[ghost]

unable to reproduce

I (edit: can, but no longer do, but will if you ask me to) get this crash on startup every single time. If my ability to reproduce it (or not) consistently can be useful, please let me know.

TL;DR seems it's something related to a combination of using twitch, and starting minimized to the Windows tray. Either of those things taken away, and my OBS works fine with the other in place. I'm not using a virtual camera. I'm on win10.

I was able to get OBS to start once (I only now realise how), and having seen the crash logs (mine's the same as above), the first thing I did was disconnect my twitch account and remove all the twitch UI elements. After that, everything worked fine. I could close and open OBS at will without error. I reconnected the account, haven't touched it since, and it's broken again today, so I'm here seeing who else has reported it.

Noting that others mentioned starting minimized, as do I, I thought I'd try and get around it, and that seems to do the trick. %appdata%\obs-studio\global.ini has the entry SysTrayWhenStarted and setting that to false, as well as avoiding the --minimize-to-tray launch param, OBS behaves.

To confirm, I re-enabled systray at start, and it crashes. Disabled it again, it starts. Next, I disconnected the twitch account. Now, it starts. Re-enable systray at start, and it starts. Re-connect twitch account, it crashes.

In any case, if I can double-click on the systray icon to maximise OBS, before the twitch docks start to paint their contents, everything works fine.

Hope this is helpful.

[Wilko01]

I have the same issue after updating to the latest version 28. Tried downgrading to the latest version of 27. The same problem. Then I installed the version that I have downloaded some time ago v 24.0.3 64 bit and it runs without issues. I run the latest Windows 11 version 22H2 OS Build 22621.521.
Before downgrading I tried admin mode and in compatibility mode. Both without success. Hope this helps.

[carlosnewmusic]

In the latest version 28.0.3 it starts the first time without problems but the second time the error described here starts to happen.
Unhandled exception: c0000005, Fault address: 7FFFAD6BC0FC (c:\program files\obs-studio\bin\64bit\qt6widgets.dll)
https://obsproject.com/logs/p7sneZGIBoreEKEu

[frvfrvr]

unable to reproduce

I (edit: can, but no longer do, but will if you ask me to) get this crash on startup every single time. If my ability to reproduce it (or not) consistently can be useful, please let me know.

TL;DR seems it's something related to a combination of using twitch, and starting minimized to the Windows tray. Either of those things taken away, and my OBS works fine with the other in place. I'm not using a virtual camera. I'm on win10.

I was able to get OBS to start once (I only now realise how), and having seen the crash logs (mine's the same as above), the first thing I did was disconnect my twitch account and remove all the twitch UI elements. After that, everything worked fine. I could close and open OBS at will without error. I reconnected the account, haven't touched it since, and it's broken again today, so I'm here seeing who else has reported it.

Noting that others mentioned starting minimized, as do I, I thought I'd try and get around it, and that seems to do the trick. %appdata%\obs-studio\global.ini has the entry SysTrayWhenStarted and setting that to false, as well as avoiding the --minimize-to-tray launch param, OBS behaves.

To confirm, I re-enabled systray at start, and it crashes. Disabled it again, it starts. Next, I disconnected the twitch account. Now, it starts. Re-enable systray at start, and it starts. Re-connect twitch account, it crashes.

In any case, if I can double-click on the systray icon to maximise OBS, before the twitch docks start to paint their contents, everything works fine.

Hope this is helpful.

I had the same issue something to do with qt6widgets.dll, and this solved in the meantime, thank you. I don't have twitch. I don't have obs virtual camera either. OBS 28.1.2 64-bit Windows 10 build 19044.
https://obsproject.com/logs/tM7LqZ-tgEBpWCdX

[carlosnewmusic]

In the latest version 28.0.3 it starts the first time without problems but the second time the error described here starts to happen. Unhandled exception: c0000005, Fault address: 7FFFAD6BC0FC (c:\program files\obs-studio\bin\64bit\qt6widgets.dll) https://obsproject.com/logs/p7sneZGIBoreEKEu
OBS Studio 28.1.2; Windows 11 Pro 22H2

https://obsproject.com/logs/pywlL3bpVC731vwb

[carlosnewmusic]

The same applies to the new version
7348-crashlog-01.txt

(Maintainer Edit: replaced inline crash log text with attachment.)

[RytoEX]

In the future, please use a file attachment instead of copying and pasting the crash log contents as text. Unfortunately, this latest crash log doesn't tell us anything new, and we still have not reproduced this as far as I know. We have some guesses, but it mostly boils down to suspecting it could be a Qt bug when restoring the various dock windows when the user has connected a service account. There are some changes in upcoming versions of Qt that may address this, but those versions are not yet released.

[ghost]

we still have not reproduced this as far as I know

I'm very happy to help with this if you need it. I can reproduce this 100% of the time. I honestly wonder why you can't.... although....

it mostly boils down to suspecting it could be a Qt bug when restoring the various dock windows when the user has connected a service account

As per the above, the requirement for the failure is a connected service account AND starting minimized.

[RytoEX]

As per the above, the requirement for the failure is a connected service account AND starting minimized.

As far as I know, we have tried exactly this and still not reproduced it.

[ghost]

Aha, got it. The crash happens when you are connected to a streaming service, stack docks, maximise the application before exiting, and minimised at startup. That specific combo. No three out of those four will do it. And yes, that took a long time XD

Steps to reproduce:

• Download fresh OBS from https://github.com/obsproject/obs-studio/releases/download/29.0.0/OBS-Studio-29.0-Full-x64.zip and unzip it somewhere temporary (I used the desktop)
• Create a shortcut to obs64.exe and add --portable
• Start OBS from said shortcut, and complete the wizard preferring streaming and accept the defaults and connect to a streaming service (YT).
• Complete the wizard, open settings, Enable Minimize to tray when started, save and close settings
• Stack two docks, eg
  
• Feel free to exit and restart OBS to see that everything works fine.
• Maximize the OBS window and exit
• Observe a crash on startup

Trying to keep a very long story short here, so feel free to ask for details should you need them.

[gxalpha]

Fixed by #8135.
This will be part of OBS 29.0.1

[ghost]

Fixed by #8135.

That change seems to outline a workaround, as opposed to a fix. If there isn't some other issue tracking an eventual resolution for this, it might be too soon to close this one.

[RytoEX]

Fixed by #8135.

That change seems to outline a workaround, as opposed to a fix. If there isn't some other issue tracking an eventual resolution for this, it might be too soon to close this one.

The use of the word "workaround" in the PR and commit titles just indicates that it's not an ideal fix. The user's saved dockstate (docks enabled/disabled, positions, sizes, etc.) will not be restored, but OBS will no longer crash immediately if they start OBS minimized to tray or maximized. The crash, as reported, is fixed.

[ghost]

I'm aware of the meaning of the terminology and the function of the PR.

The crash, as reported, is fixed.

Expected Behavior
The programme to start normally

We're not there yet.
The reported issue is, a crash when restoring dock states to certain configurations.
Fixing this means, no crash when restoring dock states to certain configurations.
The above PR provides, not crashing by not restoring dock states to certain configurations.
If this issue is closed, where would a developer or user track progress toward the actual fix where 'the programme starts normally', including restored dock states and not crashing?

[Fenrirthviti]

The actual bug is with Qt, to my understanding, so there isn't anything we can do at the moment but wait for them to fix it. I'm checking to see if there was an associated Qtbug report, but it's not a bug that we'll be able to fix.

EDIT: Still checking, but I think this might be related? https://bugreports.qt.io/browse/QTBUG-102718

[ghost]

I'm pretty sure it is, it walks, talks and quacks just like a classic Qt window geometry bug. I'd also been watching this one https://bugreports.qt.io/browse/QTBUG-110140 among others. Someone around here said on a similar issue with restorestate, "file a bug against Qt if you dislike it crashing when reading its own output." which gave me a chuckle.

Perhaps I have some misconception of the path forward. Based on my long sad history of discovering upstream Qt window geometry bugs in large projects, and knowing that a fix would be some time away, I had anticipated a similar response, which would be an attempt to fix to OBS in spite of this Qt bug persisting. Perhaps the intention is that it might get fixed by them in fairly short order, so there's no point wasting time on fixes here?

Anyway, I'm a bit off track here, because regardless of the root cause or the path forward, my point was: how do we track this OBS behaviour, here, in OBS-land, now that this issue is closed?

[WizardCM]

I had anticipated a similar response, which would be an attempt to fix to OBS in spite of this Qt bug persisting

In this case it's an unfortunate situation where the crash is deep in Qt code, and the only safe thing to do is to discard the state data. as Qt themselves have said it's unreliable. We can't even throw it into a Qt function that'll tell us "hey this is corrupted, don't use it" as it just.. crashes.

Could we try and decode it, piece it together from what remains, and hope the end result doesn't crash? Maybe, but is it worth the dev time if we have no idea whether it'll fix it? It might make it worse.

[ghost]

is it worth the dev time

That's basically what I'm wondering. Naturally, it depends on the cost of waiting instead. In my experience, it's been a long wait, so the cost was high, and the dev time was worth it to avoid that. Since it seems the decision here was to not spend time on it, I got the impression the wait is not so long.

But anyway, regardless of all that, there doesn't seem to be any place where this bug is actively tracked at present. It's not here since this is closed (which is why I posted) and it's not upstream either. That's my real objective in this conversation, is to know where/how to track this in the future.

Gotta say, I took a very quick look at the OBS code, and restoring dock states before the window has ever been painted, is uhm... optimistic ;) I know it should work, but it's famous for not. I've seen this exact failure mode in Qt apps, every year or so, for the last 20 years or so.

Were any experiments run, to change the timing on all this? Generally speaking, the first thing I'd be doing here is removing the restore from the init and placing it in whatever code runs when/after you actually show the window. That might not be a solution, but I mention it to give you an example of what I mean by 'change the timing'. I spent all day clearing space and fixing virtualbox and messing with VS trials, setting up a dev environment so I could experiment with this, only to discover the hard way that the service integrations won't build from source, so I'll have to leave it in your capable hands. Sorry, I really tried!

[ghost]

That's my real objective in this conversation, is to know where/how to track this in the future.

thatstheneatpartyoudont.jpg

[Fenrirthviti]

It's tracked with Qt. Our current policy is that if we have identified something as an upstream issue, we don't keep an issue open on our repo about it. You are free to disagree, but let's keep the snarky and unhelpful comments to ourselves, please.

[ghost]

It's tracked with Qt.

It is now? Link?

You are free to disagree, but let's keep the snarky and unhelpful comments to ourselves, please.

Calling someone snarky because they made a joke about the fact that everyone rather rudely disappeared mid-conversation and the question went unanswered, continuing to refuse to answer, and calling them unhelpful after they literally put more time into fixing it than anyone else did, and provided you with a very likely root cause based on the decades of experience they're sharing with you. The irony.

[carlosnewmusic]

It's tracked with Qt. Our current policy is that if we have identified something as an upstream issue, we don't keep an issue open on our repo about it. You are free to disagree, but let's keep the snarky and unhelpful comments to ourselves, please.

hello, well do not fight, that all contribution in opensource projects never comes wrong and always comes well the help of anyone, but the truth would be nice that this bug reported in QT and linked with this error in OBS, for my part although it has been a patch instead of solution, it works and no longer gives problems when opening obs, by the part of QT I think it is a problem that could take time to fix it, because as many of you say they themselves say not to use those functions, or so I understood, for my part the error since obs is closed.