Handbrake Crash on Intel board if GPU is turned off

[mam]

Please detail your question or problem in as much detail as possible:
For many years I have used a computer with AMD Processor, no problems. Now that it broke down, I've bought a mainboard for Intel processors and filled in an I7-6700k running @ 4,5Ghz.

Usinge the same windows 10 as before, Handbrake instantly crashed when I tried to open a new input file. (this occured on ALL Versions from 0.95 on to the current 1.0.1)

Already getting frustrated, I've noticed that if I turned on the Intel GPU in bios and installed a driver for it in Windows, Handbrake worked again!
So it became clear that Handbrake is somehow using the GPU, even if it shows "quicksync is not installed on this computer" and the appropriate switches in the preferences are turned off and greyed out.

So I am wondering, if this is a Bug, or a Feature?

[rollin_eng]

Could you please post your logs, instructions can be found here:

viewtopic.php?f=6&t=31236

[Woodstock]

You have a lot of system-level unknowns in your question.

When you installed the Intel board, did you reinstall Windows from scratch, or just reboot and let Windows figure things out?

Without the system crash reports, though, it's pretty much impossible to say what was going on.

[mam]

here is you log (which pretty much shows NOTHING):
---------------------------------------------------
[18:56:32] hb_init: starting libhb thread
[18:56:32] hb_init: starting libhb thread
[18:56:32] hb_init: starting libhb thread
[18:56:32] hb_init: starting libhb thread
[18:57:03] hb_init: starting libhb thread

# Starting Scan ...

[18:57:03] CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
[18:57:03] - Intel microarchitecture Skylake
[18:57:03] - logical processor count: 8

*CRASH*
---------------------------------------------------
This can be reproduced instantly, just disable the intel video card in either bios or in windows devices. Then fire up HP and open a file. It will instantly crash. Reactivating the video card lets it run flawlessly again.

About the windows: I've tested both, on one computer I just used on the old W10 installation from the AMD Board before, on the other one I did a fresh install.
Handbrake tested was 0.95. 1.0.0 and 1.0.1. Its always the same, you try to open a file and instead scannig it HB crashes instantly.

Related windows errors for this crash:
Name der fehlerhaften Anwendung: Handbrake.exe, Version: 1.0.1.0, Zeitstempel: 0x58658028
Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 10.0.14393.479, Zeitstempel: 0x582588e6
Ausnahmecode: 0xe0434352
Fehleroffset: 0x0000000000017788
ID des fehlerhaften Prozesses: 0x14a4
Startzeit der fehlerhaften Anwendung: 0x01d2677d0b920211
Pfad der fehlerhaften Anwendung: C:\Program Files\Handbrake\Handbrake.exe
Pfad des fehlerhaften Moduls: C:\Windows\System32\KERNELBASE.dll
Berichtskennung: 5fc650ef-c157-4391-8fe2-8dbb3e343db7
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:


And, if you want more details:

Anwendung: Handbrake.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.AccessViolationException
bei HandBrake.ApplicationServices.Interop.HbLib.HBFunctions.hb_scan(IntPtr, IntPtr, Int32, Int32, Int32, UInt64)
bei HandBrake.ApplicationServices.Interop.HandBrakeInstance.StartScan(System.String, Int32, System.TimeSpan, Int32)
bei HandBrakeWPF.Services.Scan.LibScan.ScanSource(System.Object, Int32, Int32, HandBrake.ApplicationServices.Model.HBConfiguration)
bei HandBrakeWPF.ViewModels.MainViewModel.StartScan(System.String, Int32)
bei HandBrakeWPF.ViewModels.MainViewModel.FileScan()

Ausnahmeinformationen: System.Reflection.TargetInvocationException
bei System.RuntimeMethodHandle.InvokeMethod(System.Object, System.Object[], System.Signature, Boolean)
bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(System.Object, System.Object[], System.Object[])
bei System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
bei Caliburn.Micro.ActionMessage+<>c.<.cctor>b__31_0(Caliburn.Micro.ActionExecutionContext)
bei Caliburn.Micro.ActionMessage.Invoke(System.Object)
bei System.Windows.Interactivity.TriggerBase.InvokeActions(System.Object)
bei System.Windows.EventRoute.InvokeHandlersImpl(System.Object, System.Windows.RoutedEventArgs, Boolean)
bei System.Windows.UIElement.RaiseEventImpl(System.Windows.DependencyObject, System.Windows.RoutedEventArgs)
bei System.Windows.Controls.Primitives.ButtonBase.OnClick()
bei System.Windows.Controls.Button.OnClick()
bei System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(System.Windows.Input.MouseButtonEventArgs)
bei System.Windows.RoutedEventArgs.InvokeHandler(System.Delegate, System.Object)
bei System.Windows.RoutedEventHandlerInfo.InvokeHandler(System.Object, System.Windows.RoutedEventArgs)
bei System.Windows.EventRoute.InvokeHandlersImpl(System.Object, System.Windows.RoutedEventArgs, Boolean)
bei System.Windows.UIElement.ReRaiseEventAs(System.Windows.DependencyObject, System.Windows.RoutedEventArgs, System.Windows.RoutedEvent)
bei System.Windows.UIElement.OnMouseUpThunk(System.Object, System.Windows.Input.MouseButtonEventArgs)
bei System.Windows.RoutedEventArgs.InvokeHandler(System.Delegate, System.Object)
bei System.Windows.RoutedEventHandlerInfo.InvokeHandler(System.Object, System.Windows.RoutedEventArgs)
bei System.Windows.EventRoute.InvokeHandlersImpl(System.Object, System.Windows.RoutedEventArgs, Boolean)
bei System.Windows.UIElement.RaiseEventImpl(System.Windows.DependencyObject, System.Windows.RoutedEventArgs)
bei System.Windows.UIElement.RaiseTrustedEvent(System.Windows.RoutedEventArgs)
bei System.Windows.Input.InputManager.ProcessStagingArea()
bei System.Windows.Input.InputManager.ProcessInput(System.Windows.Input.InputEventArgs)
bei System.Windows.Input.InputProviderSite.ReportInput(System.Windows.Input.InputReport)
bei System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr, System.Windows.Input.InputMode, Int32, System.Windows.Input.RawMouseActions, Int32, Int32, Int32)
bei System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr, MS.Internal.Interop.WindowMessage, IntPtr, IntPtr, Boolean ByRef)
bei System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
bei MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
bei MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
bei System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
bei MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
bei MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
bei System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
bei System.Windows.Application.RunDispatcher(System.Object)
bei System.Windows.Application.RunInternal(System.Windows.Window)
bei HandBrakeWPF.App.Main()

I agree, its not nice from me to disable the card, I just wanted to save some °C so I can let run the CPU a bit faster...

Maybe this is not really an error, some compiler settings that activate special instructions if HB finds a Skylake?

[s55]

Looks more like a system level crash that's taking out HandBrake with it. The GPU probe code is probably invoking something in the system/drivers that's not behaving. I've not seen this issue myself with onboard disabled so I'd lean to buggy driver.

[mam]

Looks more like a system level crash that's taking out HandBrake with it. The GPU probe code is probably invoking something in the system/drivers that's not behaving. I've not seen this issue myself with onboard disabled so I'd lean to buggy driver.

No, sorry. This also occurs if the Videocard is turned off in Bios, Windows fresh install (never ever installed a driver for this card).

My guess is more a fault in HB which finds a Skylake CPU and does not even think that that part could be turned off. Instead it tries to use the device and fails miserably (of cource).

Btw, here is the same log like before but with the GPU/Driver enabled. Of course, this works.:


[20:20:33] hb_init: starting libhb thread
[20:20:33] hb_init: starting libhb thread
[20:20:33] hb_init: starting libhb thread
[20:20:33] hb_init: starting libhb thread
[20:20:45] hb_init: starting libhb thread

# Starting Scan ...

[20:20:45] CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
[20:20:45] - Intel microarchitecture Skylake
[20:20:45] - logical processor count: 8
[20:20:45] OpenCL device #1: Intel(R) Corporation Intel(R) HD Graphics 530
[20:20:45] - OpenCL version: 2.0
[20:20:45] - driver version: 21.20.16.4494
[20:20:45] - device type: GPU
[20:20:45] - supported: YES
[20:20:45] OpenCL device #2: Advanced Micro Devices, Inc. Tahiti
[20:20:45] - OpenCL version: 1.2 AMD-APP (2236.10)
[20:20:45] - driver version: 2236.10
[20:20:45] - device type: GPU
[20:20:45] - supported: YES
[20:20:45] Intel Quick Sync Video support: yes
[20:20:45] - Intel Media SDK hardware: API 1.19 (minimum: 1.3)
[20:20:45] - H.264 encoder: yes
[20:20:45] - preferred implementation: hardware (any)
[20:20:45] - H.265 encoder: yes
[20:20:45] - preferred implementation: hardware (any)
[20:20:45] hb_scan: path=D:\Incoming\Great British Railway Journeys 8x04.ts, title_index=0
udfread ERROR: ECMA 167 Volume Recognition failed
src/libbluray/disc/disc.c:274: failed opening UDF image D:\Incoming\Great British Railway Journeys 8x04.ts
src/libbluray/disc/disc.c:352: error opening file BDMV\index.bdmv
src/libbluray/disc/disc.c:352: error opening file BDMV\BACKUP\index.bdmv
[20:20:45] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 5.0.1
libdvdread: Encrypted DVD support unavailable.
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed
libdvdread: Can't open file VIDEO_TS.IFO.
libdvdnav: vm: failed to read VIDEO_TS.IFO
[20:20:45] dvd: not a dvd - trying as a stream/file instead
[20:20:45] file is MPEG Transport Stream with 188 byte packets offset 0 bytes
[20:20:45] Found the following PIDS
[20:20:45] Video PIDS :
[20:20:45] 0x157c type H.264 (0x1b) (PCR)
[20:20:45] Audio PIDS :
[20:20:45] 0x157d type AC3 (0x81)
[20:20:45] Subtitle PIDS :
[20:20:45] Other PIDS :
[20:20:45] stream id 0x157d (type 0x81 substream 0x0) audio 0x157d
[20:20:45] scan: decoding previews for title 1
[20:20:45] file is MPEG Transport Stream with 188 byte packets offset 0 bytes
[20:20:45] scan: audio 0x157d: ac3, rate=48000Hz, bitrate=192000 English (AC3) (2.0 ch)
[20:20:48] stream: 65 good frames, 0 errors (0%)
[20:20:48] scan: 10 previews, 1920x1080, 25.000 fps, autocrop = 0/0/0/0, aspect 16:9, PAR 1:1
[20:20:48] scan: supported video decoders: avcodec qsv
[20:20:48] libhb: scan thread found 1 valid title(s)

# Scan Finished ...

[s55]

It's not doing anything with the GPU during startup. It's simply asking the system, what are your capabilities. The system is crashing or returning garbage data to us.

Remember, by activating the Intel GPU, HandBrake may be working because the OpenCL detention will be using their copy of the library, not the AMD one.

As I said in the past, we may add an option to outright disable all this functionality as it's not uncommon to see driver crashes with this. Usually not with drivers direct with Intel or AMD. Normally it's drivers from OEM's that cause the most problems as they tend to be cut down to the bare minimums to function.

[mam]

>It's not doing anything with the GPU during startup. It's simply asking the system, what are your capabilities. The system is crashing or returning garbage data to us.

Pardon me, can you please try to explain, how a system that has not the slightest knowledge of a device, nor has ever seen a driver for it, may crash here ???

Or pls tell me what system call you are using to ask for the caps, I will then do some testing myself.

Or is there a debug version somewhere which I could download and run (and see more where its crashing and what its doing) ?

[mam]

Addon: made me a debug version myself (but have no linux to create a debug of hb.dll).

it crashes in Handbrake Application Services line # 225 calling

HBFunctions.hb_scan(this.hbHandle, pathPtr, titleIndex, previewCount, 1, (ulong)(minDuration.TotalSeconds * 90000));

so could someone provide me with a debuggable hb.dll, that I can dig deeper?

[s55]

I'm not talking about QuickSync here. I'm talking about OpenCL with both the Intel and AMD GPU's support.

I suspect it's more likely the OpenCL calls are failing as that's where we've seen problems in the past. Activating the Intel Driver may be fixing it because it's using a different OpenCL.dll file.

We are not even seeing the OpenCL info printed in the log when only the AMD part is enabled in your system. That suggests (I can't confirm without debugging), that its the OpenCL calls, *NOT* the QuickSync ones, that are failing.

We've seen a number of instances in the past where making a call to any cl* (i.e clGetDeviceInfo) methods in the OpenCL.dll crashes out.

I could be wrong, but the only way you'll find out for sure, is to following the compile guide in handbrake.fr/docs. and add --debug=max then run HandBrakeCLI.exe with GDB and get a backtrace from it. That'll pinpoint the crash for sure.

[s55]

HBFunctions.hb_scan(this.hbHandle, pathPtr, titleIndex, previewCount, 1, (ulong)(minDuration.TotalSeconds * 90000));

This is a transition into native code.


https://handbrake.fr/docs/en/1.0.0/deve ... ndows.html

Note, since your on Windows 10, if your on the anniversary edition, you can enable the Ubuntu bash Terminal, and compile from there.

Just add --debug=max to the ./configure call and it'll give you a rather large hb.dll (500MB region) and HandBrakeCLI.

You'll need to use GDB. I don't think you'll get far with Visual Studio as it's a native crash.

gdb HandBrakeCLI.exe

when it launches

run -i testFile.mkv -o test.mp4

when it crashes,

type "bt"

grab the output and post it here.

I suspect, it'll be somewhere in your OpenCL.c. in our source code that we see a crash.

[s55]

Infact, even easier than debugging,

https://github.com/HandBrake/HandBrake/ ... /hb.c#L632

Commenting out that line, does it fix or move the problem?

Few lines below, is the Print QSV call as well. (note, configure needs --enable-qsv for that code to be present)

[mam]

will have to wait until tomorrow. Just got that ubuntu installed, but that can only use local drives, so i have to move the whole visual compiler stuff & source away from my homedir... (if this sounds complicated, you've got it).

"easier than debugging" does not help me yet unless I have not compiled the hb.dll yet...

(btw, now that I've almost have it up and running already, where can I look for the audio stuff, so I can build in my rules ? )))
(just kidding, the look into the sources so far made me humble, C# was invented AFTER my retirement, that will take some time to catch up, but the plain C++ stuff in hb.dll looks fine to me -)))) )

Good night for now, older people need their beauty sleep...

[s55]

Fair enough. I do appreciate you taking the time to investigate as it's not something I've seen in a while and can't immediately reproduce.

I was digging though the C# code. It calls. hb_qsv_available to initialise some UI widgets correctly in preferences. So, given we know the app launches when you had the Intel GPU disabled but crashed during scan, that suggests that the QSV API calls are not the source of the crash also.

I'll put money on it being that damned OpenCL detection again.

I'm thinking about adding a new param to the hb_scan call so we can simply have a preference in the app to disable it completely when we get a failure.

[mam]

> I do appreciate you taking the time to investigate as it's not something I've seen in a while and can't immediately reproduce.
My former job include finding bugs in other people's code, so this is not really new to me.
Its just always the frustrating startup phase until you found out how to navigate and how to compile. And Handbrake does not look like an easy candidate for getting into it... But now its creating its mingw stuff already, we will see.

> I'll put money on it being that damned OpenCL detection again.
Not beeing british betting is not really something I do. But I still think you are wrong, simply because it worked on the AMD box before with the same card and same driver. It would be logical if the program would start to choke when it gets the 2nd card, but its the opposite, if brakes if there is no card/driver..

Hmm, this mingw stuff is taking quite long... does it fill my precious SSDs ? ))
uh, oooh... hmpf... downloading all the stuff as source and crosscompiling it... this can take a while... I should consider breakfast in between...

[mam]

too bad...
The build of the mingw stuff failed (repeated it 2 times, same failure) without any error

first of all, your manual is not complete, I had to add halve a dozen more packages before the built began. But even then it failed, the only hint I found in the logs was a missing "makeinfo" but with the comment that it is optional. The comment turned out to be a lie, so after installing texinfo package also the build is now running....

(but thats why I am a Linux hater, there are not 2 distributions that come with the same packages preinstalled. Always you have to search for different paths, programs and so on. Wasted lifetime. I stick to my beloved BSD which is the same for over 40yrs now )) )


in case you want to update your manual, these are still missing packages:

bison
flex
g++
pax
texinfo

(continued later on, have to go fridge-filling before...)

[mam]

yeah, we all know: just try to solve a small problem and you open pandora's box and many many horror clowns jump out of the box and directly into your face...

Add "automake" to the missing list before. Ubuntu only comes with autotools-1.14, your makefile wants 1.15 for automake and aclocal.
Could not find them, so some symlinks had to do for now..

redoing from start...

[mam]

no, sorry, this wont work. I give up! (for now )) ) (naah not really, but..)

there are serious problems with the build of the mingw tools. Out of the (clean) box it breaks at gmp 6.1.0 where configure should have linked a header file.

its in "gmp", the file "gmp-mparams.h"

I will copy it manually and see how I can continue the build...

[s55]

Well damn, after a bunch of Blue Screens caused by AMD's bloody drivers, I finally got my system booted without Intel Graphics enabled, and getting the same crash where it prints CPU but stops short of getting to the OpenCL and Qsv Output.

I'm going to make some changes to test my theory now.

[mam]

good to here. after "only 14hrs" today I just mananged to compile the toolchain successfully (had to update 2 packages, the versions from your source did not make it through the compiler).

I'm going to compile a debug hb.dll now (crossing my fingers, another 20hrs to go?)

[s55]

hmm, I havn't tried recently as I already have a toolchain setup, but I have very little difficutly getting the ubuntu shell on windows to build it. That said, it was pre automake 1.15 etc so htere maybe some issues now.

It's probably a lot easier on a recent Ubuntu 16 shell rahter than the 14LTS that windows uses.

[s55]

Also interesting that commenting out https://github.com/HandBrake/HandBrake/ ... /hb.c#L632 seems to allow it to actually start scanning the source, but it crashes later on.

[s55]

Huh, I had to comment out both the OpenCL AND QSV code.

Edit: Scratch that, Just the QSV code. Seems your right. What's interesting though, is if you comment out the OpenCL code, we actually get considerabally more log output. That's really odd but fair enough.

Right, I think I can fix this.

[s55]

Quick Fix:

/* Print QSV info here so that it's in all scan and encode logs */
if (hb_qsv_available()){
hb_qsv_info_print();
}

Wrap the info_print in a call to check if it's available. Need to dig into why the hell the print methods is failing as well.


EDIT: So, I guess the native crash is killing the GUI before it can fully process the incoming log data, as the first thing the info_print does is // is QSV available and usable?
hb_log("Intel Quick Sync Video support: %s",
hb_qsv_available() ? "yes": "no");

which we are not seeing.

[s55]

@mam -> Hopefully this fixes it: https://github.com/HandBrake/HandBrake/ ... 64b01afdb3

So, will be available in tomorrows nightly, or you can do a git pull to grab that fix and test.