Bug Report Windows 10 - OBS immediately freezes OS

Kisai

New Member
Hey there,

I've been trying to figure out what's going on with this when I went and looked at the log file.


22:04:16: Interface: Intel(R) Ethernet Connection I217-V (ethernet, 1000 mbps)
22:04:16: Completed handshake with rmtp://192.168.1.17/live in 2 ms.
22:04:16: SO_SNDBUF was at 65536
22:04:19: RTMPPublisher::SocketLoop: Stalled for 2164 ms to write 3213160 bytes (buffer: 0 / 3216384), unstable connection?
22:04:20: RTMPPublisher::SocketLoop: Increasing send buffer to ISB 131072 (buffer: 0 / 3216384)

When searching the forums I came accross this:
https://obsproject.com/forum/threads/full-stop-computer-locks-up-using-obs-on-any-game.4339/ but on Windows 7. Now I didn't have this problem on Windows 7.

So this is new, and in fact the exact same settings I was using on Windows 7 (that sometimes randomly crashed QSVhelper.)

Now what's really interesting is that it only locked up the OS once it started sending a large amount of data across the wire. Having it capture a blank screen results in the -29.log file

The -08.log file is from 07-27 before I upgraded to Windows 10, and the RTMPPublisher behaves differently:
04:37:10: Interface: Intel(R) Ethernet Connection I217-V (ethernet, 1000 mbps)
04:37:10: Completed handshake with rtmp://192.168.1.17/live in 2 ms.
04:37:10: SO_SNDBUF was at 8192
04:37:10: SO_SNDBUF is now 65536
04:37:13: RTMPPublisher::SocketLoop: Stalled for 2000 ms to write 781870 bytes (buffer: 0 / 3216384), unstable connection?
04:37:36: RTMPPublisher::SocketLoop: Increasing send buffer to ISB 131072 (buffer: 11803 / 3216384)
04:38:29: RTMPPublisher::SocketLoop: Increasing send buffer to ISB 262144 (buffer: 69649 / 3216384)
04:39:46: FlushBufferedVideo: Flushing 26 packets over 416 ms

So it appears the "increasing send buffer" mechanism is causing OBS to lockup and in turn, locking up Windows. I will try the previous version of OBS before upgrading to Windows 10 to see if it's repeatable there, but I somehow doubt it will change.
 

Attachments

  • 2015-08-12-2203-57.log
    10.3 KB · Views: 15
  • 2015-08-12-2129-29.log
    20.6 KB · Views: 14
  • 2015-07-27-0437-08.log
    15.9 KB · Views: 15

Kisai

New Member
Pulling 651b x64 that I compiled on 6/28/2015 from version control still works.
 

Attachments

  • 2015-08-12-2242-51.log
    10 KB · Views: 13

Kisai

New Member
Scratch that, it worked the first time, but when I restarted OBS from the same OBS to the same scene it locked up in about 5 seconds. I'll note that FFXIV generates rather large data streams during daylight, but they aren't so large during night scenes. So it appears to lockup once a certain about of data is pushed.

I'll see if running the current exe again using the same "it doesn't seem to lockup right away" pattern.
EDIT: Nope.

Appears to be network related but not quite sure what work-around would work yet.
EDIT2: I can push a 5GB file to and from the same machines via filezilla, so it doesn't seem to be something specific to Windows 10?

EDIT3: I can get Steam's in-home streaming to do the same host system lockup.
 
Last edited:

R1CH

Forum Admin
Developer
PC freezes generally indicate hardware instability or a driver problem. Try using x264, and check your system stability with some stress testing tool.
 

Kisai

New Member
So updating this... Running x264 and NVSync for about 25 minutes each didn't induce a crash. QuickSync in ICQ or CQP crash within 2-10 minutes (average about 90 seconds) LA-* options crash OBS/QSVHelper like on Windows 7.

Clean Windows 10 install, only the video drivers were installed. At this point I'm willing to blame QuickSync on Windows 10 itself since the problem also appears in Steam's In-home-streaming, but I'm not sure what settings Steam is using, only that it locksup at a nearly identical time, which is why I was quick to blame the network.
 
Top