Total system hang (intermittent)

[jmt333]

Description of problem or question:
When working in Handbrake, my system will sometimes fully hang. The screen goes black and there is no response. Whatever was going on halts. The system does not power off, it just hangs completely. I have to power-cycle the machine to get it to work again and, of course, I lose whatever unsaved work I might have had.

This happens only when running Handbrake. I have also run exhaustive system stress-tests (Prime95, Furmark, Cinebench, Memtest86, HeavyLoad, a couple of others) and they remain rock stable and error-free. Running normal workloads (my real work, which includes a lot of computationally-intensive data visualization) also results in normal/stable operation. I have some VMs (VMware Workstation Pro 16) on most of the time, but running VMs makes no difference. I've had these hangs both with and without running VMs. I cannot get this behavior to manifest in any condition that does not involve Handbrake.

Steps to reproduce the problem (If Applicable):
It's intermittent and there doesn't seem to be a theme. It always happens during encoding, but there is little rhyme or reason to it beyond that. I will be encoding and suddenly the computer will hang up. I am working on bringing in an entire TV series so there is usually a queue.

HandBrake version (e.g., 1.0.0):
This happens occasionally on all of 1.5.0, 1.5.1 and the latest nightly (2022101701). The behavior is identical regardless of version.

Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):
Windows 10 Pro (10.0.19044 / Build 19044), all updates applied

HandBrake Activity Log ***required***

Code: Select all

https://pastebin.com/12PkAsDB

Additional Information
* The source files are all ripped from Blu-Ray discs using MakeMKV for Linux
* I am transcoding to H.265/HEVC using GPU acceleration (Intel Arc), but the same behavior has occurred when using the H.264/AVC software encoder and the AV1 GPU-accelerated encoder (Intel Arc)
* To try to eliminate variables, I did all work locally on my PC (I usually store video on a NAS).
* This behavior has been going on since I built the machine in August. I have tried the three versions of Handbrake listed above with no change in behavior. This has happened both on my old GPU (AMD Radeon RX 6400 without a hardware encoder) and on the new GPU (Intel Arc A750 with a hardware encoder)
* There is no indication of trouble in Event Viewer. There will be normal operation that suddenly stops, and then a gap with the boot-time messages coming after the gap.

Hardware Information
In case it's necessary, here's the hardware in the system:
* CPU: AMD Ryzen 9 5900X (12 core/24 thread)
* Motherboard: Gigabyte B550M DS3H (BIOS revision F15) (BIOS is latest version)
* RAM: 32 GB DDR4, 2x16 (dual-channel)
* Primary Storage: Samsung 970 EVO Plus NVMe SSD (1 TB)
* Secondary Storage: Crucial CT525MX300 SATA SSD (512 GB)
* GPU: Asrock Intel ARC A750 (This is brand new. The same behavior manifested with my old AMD Radeon RX6400 GPU)
* Optical drive: HL-DT-ST BD-RE WH14NS40
** I have a bunch of USB devices (keyboard, mouse, headsets, webcam, etc.) plugged in via a USB 3.0 hub
** I am running in UEFI-only mode with resizable BAR enabled, but the same behavior manifested in legacy/UEFI hybrid mode without ReBAR being enabled

[s55]

System hangs are usually one of:

1. Hardware issue
2. Kernel level / driver issue.

Since HandBrake doesn't run in kernel space that leaves driver or hardware issues being most likely

It's not uncommon to hear that "this only happens with HandBrake." HandBrake is a good stress test for systems, better in many cases, than actual stress tests as it exercises more of the system at once.

Given you've switched GPU, i'd tend to lean to Power Supply Issues or Memory issues next. (Temperature issues, unless extremely severe I wouldn't have thought would have exhibited in this form.

I'd be inclined to run a few passes of memtest86+ to rule out memory and have a hardware montior up to see if any voltages appear to be sagging overly when running HandBrake.

I'd also be inclined to see if you can reproduce the issue in Windows Safe Mode. That might point towards a driver issue on the system.

If you have any overclock, dial it back to stock.

[jmt333]

It's not uncommon to hear that "this only happens with HandBrake." HandBrake is a good stress test for systems, better in many cases, than actual stress tests as it exercises more of the system at once.

Fair. I have run a ton of stress tests, including simultaneously, for hours or days. It doesn't mean it's impossible that there's some underlying issue by any means, but I have beaten the hell out of this system trying to get it to hang up like this.

Given you've switched GPU, i'd tend to lean to Power Supply Issues or Memory issues next. (Temperature issues, unless extremely severe I wouldn't have thought would have exhibited in this form.

Temperature shouldn't do this, but I also have monitored temperature very closely and I am nowhere near redline (CPU tops out about 80 degrees, GPU tops out about 75 degrees, power delivery and chipset run hotter but still well within margins). I am not confident about much with this problem, but I am confident it isn't temperature.

PSU is possible, I suppose, but it would be a very bizarre failure mode. If the PSU was at fault, I'd expect the system to turn off rather than hang up. Power is still being delivered when this happens, as the power light remains illuminated and the fans keep spinning. I don't have a spare, higher-capacity PSU on hand but if we get nowhere else, I'll order one. The PSU is I have is a decent EVGA model (I didn't cheap out on the PSU - I learned that lesson some time ago lol). It is a bit small for the load (550 watt) but the problem also predates the GPU change. This still doesn't rule out power delivery problems, but the old GPU was very weak (<75W) and this problem still happened.

I'd be inclined to run a few passes of memtest86+ to rule out memory and have a hardware montior up to see if any voltages appear to be sagging overly when running HandBrake.

I have run Memtest86 exhaustively with no problems. I have not seen voltage problems but I also haven't recorded the data from hardware monitoring. I will do so and see if voltages start to fall in the recorded output once the system comes back up. This is a very good idea, thank you.

I'd also be inclined to see if you can reproduce the issue in Windows Safe Mode. That might point towards a driver issue on the system.

I'll try this, too. It will have to wait for the weekend, probably, but I'll give it a shot.

If you have any overclock, dial it back to stock.

Already done. I had some modest overclocks in place at the beginning and I have rolled everything back to stock in this regard.

Thanks for such a comprehensive reply, and I'll try out those things when I can.

[jmt333]

I got lucky with my overnight workload and was able to run both remaining tests of safe mode and close voltage/temperature assessment.

In normal mode (which is required to collect the data, since the tool installs a driver), I see some voltage fluctuation but it is tiny. The +12v rail used for CPU and GPU remained stable at +/- 0.024 volts. The +3.3v rail used for memory was noisier but fluctuates consistently between +3.285 and +3.305 (it looks like the VRM on that rail probably fluctuates up and down between those points) and those values are well within the ATX power delivery spec (+3.135 through +3.465). It doesn't look like there's voltage sag happening unless the data point did not get reported.

On the temperature front, CPU core temps peak at around 70 centigrade and the various core complex sensors report mid 70s, as high as 80 for brief moments. Total package temperature is higher, at high 70s or 80 for brief periods and one single spike up to 90 centigrade, which would have probably throttled briefly. GPU temps did not exceed 65 on any sensor.

In safe mode, which used the software (CPU) encoder instead of the GPU encoder (no drivers loaded in safe mode) and with process isolation disabled in Handbrake (no networking in safe mode), the system did hang up again as it does during normal operation. This probably rules out wonky drivers in the chipset or GPU and that's unfortunate because there also doesn't appear to be a power delivery or temperature problem and the memory checks out in Memtest86.

[jmt333]

I have done some more testing on this problem. I cannot seem to get the system to hang when doing transcoding using FFMPEG. I have also jumped to HandBrakeCLI for testing and it seems to crash less but I still did get a crash.

In an attempt to reproduce this issue outside of Handbrake and given the failure of this issue to reproduce using synthetic loads, I tried Blender and rendered a complex scene ("Barbershop" animation). Voila - I got a system hang-up that appears to be the same problem as I'm seeing in Handbrake.

So it definitely does look like hardware, which I initially though and questioned only when I couldn't get anything *but* Handbrake to crash. Now that I have gotten something else to crash, it looks like it isn't Handbrake.

I'll try to figure out where to go from here, and will update this thread if I find the answer. It isn't a Handbrake issue.