Bug Report OBS Studio 19.0.3 Crashes XHCI Controller

[FerretBomb]

System:
ASUS X-99A/USB 3.1 motherboard (i7-5820k @ 4.2GHz)
-Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)
--Microsoft Driver 10.0.15063.296 (4/27/2017)
(Also on machine but unused: ASMedia USB 3.1 eXtensible Host Controller - 1.10)

Erratically after starting OBS Studio 19.0.3, all USB devices will disconnect/depower. Appears to be an XHCI device crash. Only occurs when Studio is loading/loaded, and occurs erratically; can take 10 seconds, or 4 hours. Unplugging/replugging devices after the issue does not reconnect them. Some devices do maintain powered-on status (Logi BRIO, n52te speedpad) but cannot control/pass data.

Issue does not occur on Studio 14.*, or OBS Classic 0.659b 64-bit, though the same USB devices are in use on both with the same source parameters; scenes manually recreated identically between the versions/revisions. I have not tried any versions between 14 and 19 for an appreciable amount of time to determine if the issue existed in v16.*.

Logfile posted, crashlog unavailable because OBS itself does not crash. Only the USB devices do, rendering the system unusable aside from RDP (no PS/2 keyboard/mouse port available).

Entirely possible that it may be the USB drivers freaking out, but it's definitely something about OBS Studio 19.0.3 accessing USB devices that causes the host controller crash. Am open to troubleshooting, issue is semi-reproducible if intermittent on how long it takes to occur. Does appear to consistently happen when trying to access my Behringer mixer, or at least that seems to be the most common last-line in the log.

 

[R1CH]

You're probably overloading the controller, move some devices to other ports or stop running the webcam at 1080p.

 

[FerretBomb]

You're probably overloading the controller, move some devices to other ports or stop running the webcam at 1080p.

I can run the exact same scene setups in OBS Classic or Studio 14.* indefinitely without triggering the XHCI crash. I can even load it more heavily by running my BRIO at 1080@60 or 4K@30 under either of those two as a stress-test and still no crash.

Also, it's a modern XHCI setup; single controller on a direct PCIe bus with emulated multiple hubs, falling back to emulated multiple UHCIs through the single chip if XHCI is disabled. All of the ports on the motherboard (including the front ports and expansion headers) go back to the same single XHCI controller. It has a separate XHCI controller chip for the two USB 3.1 ports, but that's it (and the 3.1 controller has no internal expansion headers, which is dumb).

 

[R1CH]

It's probably a hardware or driver issue then. OBS is user-mode software so it never interfaces with USB devices directly, instead it uses the OS APIs like DirectShow / Windows Audio.

 

[FerretBomb]

It's probably a hardware or driver issue then. OBS is user-mode software so it never interfaces with USB devices directly, instead it uses the OS APIs like DirectShow / Windows Audio.

Oddly, OBS Studio 19.* is the ONLY thing that triggers the issue. Even older versions of Studio (14.*) do not. Again, it may be a driver issue, but there is an element in Studio that is acting as a semi-reliable trigger, that no other program I've found so far has even tripped once, much less every time I open it.

 

[FerretBomb]

Have had an additional report from Femmenenly that she was using a Gigabyte GA X99 Phoenix SLI with a 5820k, and had the same issue. Though her mobo did get coolant splashed on it, it only had the USB-crash issue with Studio running.
She fixed it by swapping out the motherboard for another of the same make/model, has not recurred. May be some kind of QA issue on the X99 boards, that Studio is triggering.

Also reported by Mektum in: https://obsproject.com/forum/threads/obs-suddenly-shut-down-all-usb-ports.72487/
who is also using a Gigabyte X99 with a 5820k.

Ping @R1CH as this does appear to be a hardware-caused edge case that recent versions of Studio is triggering.

 

[FerretBomb]

Ping @R1CH as after updating to 20.0.1 the issue has still recurred. All USB hubs/XHCIs are set to never "allow the computer to turn off this device to save power", and USB selective suspend is disabled in all of my power profiles. It did last quite a bit longer (a good ~16-20 hours of run time) than previously.

Again, this did NOT happen with Studio 14.*, and still does not happen with Classic 0.659b. It happens with NO other program except Studio 19.0.3+; anything else I can leave running indefinitely with the issue never occurring.

 

[R1CH]

So 19.0.2 is OK?

 

[FerretBomb]

So 19.0.2 is OK?

I haven't tried. For a long while I was only checking every few major versions and just using Classic due to a lack of needed new features. Prior to 19.0.3, the last I'd tested was 14.???, which didn't have the issue. Though to be fair I didn't use 14 extensively; just to check up on the features added. With the addition of the ability to delay Game Capture sources in 19, there was finally a compelling reason to switch and deal with the hotkey codex... namely the ability to sync the webcam, mic, system audio and gameplay together, so I can hum along with game music. (Yes, it's dumb. But it's been one of the largest irritations while streaming, especially when a good track comes on.)

I'm willing to go through the older versions one by one until the issue starts cropping up, but with the intermittent nature and lack of reliable steps to reproduce other than 'start and let it run for a few hours', testing could take quite some time.

Likewise, if there's any way to have a debug version to see exactly what's going on, and dump the last actions taken by OBS prior to specific USB devices disappearing (maybe a rolling FIFO log of the last 5-30 seconds?), I'm more than happy to be a guinea pig to help run down what appears to be a niche and hardware-related issue.

And not only because my only other options are to build a new machine, stay on Classic forever, or move to xsplit. :b None of which are appealing.

 

[Suslik V]

Downgrade to win7 32bit and see what happens. Or you can run linux live and make test OBS there.

 

[FerretBomb]

Downgrade to win7 32bit and see what happens. Or you can run linux live and make test OBS there.

Not helpful.

 

[Suslik V]

Then bug in hardware. Because linux has completely different every single part of the software. Some bugs may be masked by software updates from the manufacturer, just try to keep drivers up to date.

 

[FerretBomb]

Then bug in hardware. Because linux has completely different every single part of the software. Some bugs may be masked by software updates from the manufacturer, just try to keep drivers up to date.

Not saying it isn't a hardware root-cause issue. Just that OBS Studio is THE ONLY SOFTWARE that triggers the issue, EVER. I'm also not the only one experiencing the issue, I've spoken with 4 other streamers on X99 that have the same USB XHCI crash with Studio, and ONLY Studio. Two on Gigabyte motherboards, one besides me on ASUS, and one on MSI. All on i7-5820k CPUs. Only the USB 3.0 XHCI is crashed, the ASMedia USB 3.1 controller stays up and working normally.

If you wash your floors with gasoline and it works fine, that's great. But there are a few of us with open flames around that are otherwise safe, until the mopping starts. Independently there's no problem. But put them together, and boom.

Again, OBS Studio is THE ONLY SOFTWARE that causes the issue to occur. Even Classic and older versions of Studio run fine and do not trigger the issue.

 

[Harold]

correlation does not equal causation.

 

[FerretBomb]

correlation does not equal causation.

It does when the correlation is exclusive. Unless you're suggesting that the USB crash only chooses to happen when Studio is running, and at no other time, even once.

On a more useful note, I'm disabling xHCI handoff in the BIOS, as that solved a different USB issue for someone else with some similarities under X99 (but it occurred randomly regardless of software in use, instead of a 1:1 correlation as this one is). Time to test and see if it still happens.

 

[Harold]

Except it's not exclusive.

Or you're unwilling to complete all the tests to prove that it is (the above "try linux" suggestion)

 

[FerretBomb]

Except it is, under this use case. If it CAUSES the crash under Win10, and is the ONLY software that does it, does it matter if it crashes or not under Linux? It will STILL CAUSE THE CRASH under Win10, regardless of that testing.

I'm open to DOING the testing, if there is some useful information it will provide as far as solving the crash under Windows. Otherwise, it's just wasting time. Like testing the tires on a car, when the transmission is hosed. Creating inconvenience in hopes that the user will decide not to pursue the issue further, so the core issue doesn't have to be acknowledged and addressed.

 

[Harold]

If it must be Windows 10 AND obs, then you don't have a single point of failure.

 

[FerretBomb]

So switching to a different OS, that accesses USB in a completely different way, through a different OS architecture, is meant to diagnose an issue with THIS OS. What's next, if it still breaks under Linux (somehow) are you going to ask me to put in a different PSU? Maybe swap out the RAM? After all, if you don't change those out, how could you tell if it was a problem with them? Maybe try a different computer?

I'm very glad that your arm, and the majority of arms are not broken. But mine is, and telling me to try someone else's arm is not helpful. If you have a test that needs to be run that could reasonably contribute to solving the problem, I'm happy to comply. But the suggested above is not reasonably helpful to troubleshooting in any way, unless you can explain otherwise. At which point I'll be happy to test it again. But I'm not going to do random and totally unrelated make-work.

On a more useful note, disabling xHCI handoff did not resolve the issue.

 

[WolfWings]

Speaking as someone watching from the sidelines here,

Except it's not exclusive.

Or you're unwilling to complete all the tests to prove that it is (the above "try linux" suggestion)

in this case you're confusing the issue; I won't quote chapter and verse of invalid debate types, that's being needlessly and unhelpfully pedantic.

@FerretBomb is offering to regression-test versions of OBS Studio to bisect which release introduced whatever changes began allowing it to trigger this interaction with certain X99 XHCI USB 3.0 controllers under Windows 10.

@FerretBomb even said it's likely a hardware issue and they're okay if so but want to run it to ground to confirm; and it doesn't happen with older versions of OBS Studio. So it's possible that a change made in how OBS Studio does things in some area unrelated to USB directly (buffer sizes or any other not-exposed knob even) could be what's allowing this crash to occur, because it's doing something 'more efficiently' than other similar tools do and stressing things more.

Much like how Prime95 or the much older game HellFighter can often find issues with a CPU because of the particular type of workload they're doing, narrowing down the specific release could help find what changes were made and it might well be something as simple as 'changed compiler flags/updated compiler for release builds' so no actual code changes triggered it.

But it looked like @FerretBomb was just confirming if there were any extended-debugging versions of OBS Studio available or able to be compiled against the older versions to get extended logging, a simple "No, we don't have any way to add that quickly/unless we narrow it down to a specific release further," I think was all that's needed in this case.