View Issue Details

IDProjectCategoryView StatusLast Update
0000419madVRbugpublic2018-01-14 15:34
Reporterkanade Assigned Tomadshi  
PriorityimmediateSeveritycrashReproducibilityrandom
Status closedResolutionno change required 
PlatformWindowsOSWindows 7 Ultimate 64bit SP1OS Version6.1.7601
Summary0000419: madVR crashes or even result in BSoD while using the latest AMD drivers
DescriptionWhenever I play or pause any videos of any formats, at random moment, I either get:
- Screen freezing for couple of seconds and then getting madVR crash/bug report dialog
- Screen freezing for couple of seconds and then getting BSoD

This has only happened on the latest AMD Crimson drivers starting from 16.5.1. FYI, the current driver is 16.7.2.

Except for 15.12, I haven't specifically tried testing drivers below 16.5.1. I did however tested every single drivers released from 16.5.1 and onward, and they all resulted in crashes/BSoD.

Steps To Reproduce1) Start playing any video
2) At random moment, madVR crashes/experience BSoD on either during playback or paused
Additional InformationI've attached a .txt file (inside .zip) of bug report as I wasn't able to send it from the dialog option.

FYI, here's the list of drivers which I've tried:
- 16.5.1
- 16.5.2
- 16.5.2.1
- 16.5.3
- 16.6.1
- 16.6.2
- 16.7.1
Regardless of what Potplayer builds or LAV versions that I use, all of these drivers resulted in madVR crashing/BSoD while playing or pausing any type of videos.

As mentioned in the description, 15.12 was the only driver where I didn't experience any crash problems with. I wasn't able to confirm with other older drivers (i.e. below 16.5.1) though I suspect they will also cause the same problem.

Ultimately, regarding to when the problem actually happens, it is completely random as I'm not able to work out a pattern. It could happen straight away or it could happen after several hours of playback. It could also happen during when I pause the video. It's just pure random as there are no noticeable pattern.

I also tried using your madvr fix called "madVR9019amdFix.rar" a few weeks back yet, it still didn't fix the problem.


TagsNo tags attached.
madVR Version0.90.21
Media Player (with version info)Potplayer 64bit (1.6.60136)
Splitter (with version info)LAV Splitter (0.68.1.25-git)
Decoder (with version info)LAV Video Decoder (0.68.1.25-git)
DecodingSoftware
Deinterlacingauto mode
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modeall modes
GPU ManufacturerAMD
GPU ModelAMD Radeon R9 390
GPU Driver Version16.7.2

Activities

kanade

2016-07-12 23:40

reporter  

madshi

2016-07-12 23:45

administrator   ~0001386

For some reason the crash occurs during NNEDI3 scaling. Is it possible that you're running out of GPU RAM? Does lowering the size of the GPU queue help?

If all else fails it might make sense to temporarily disable NNEDI3 to double check whether the problem is really related to that or not.

kanade

2016-07-13 00:09

reporter   ~0001387

Thank you for the reply.

Is that so? No, my card has 8GB of RAM which, it barely uses any of it.
I've just checked with GPU-Z and I'm not seeing full usage of GPU RAM while playing the videos.

I've just disabled NNEDI3 for both chroma and image doubling.

I'll report back if I experience the problem again.

ggxtreme

2016-07-14 08:54

reporter   ~0001388

Last edited: 2016-07-14 08:55

I've been having the same issue for a while, I originally reported it to AMD figuring they mucked up something OpenCL-related in their newer drivers and just stuck to Catalyst 15.11.1 Beta.

I can confirm the issue occurred for me when using NNEDI3 scaling but not the other scaling methods I tried. I can also confirm that the issue does not occur with pre-16.x Catalyst drivers, but has occurred with every 16.x Crimson driver I've tested.

I have an R9 390X.

madshi

2016-07-14 09:49

administrator   ~0001389

That's really disappointing... ;-(

kanade

2016-07-15 06:16

reporter  

kanade

2016-07-15 06:16

reporter  

kanade

2016-07-15 06:19

reporter   ~0001390

This is bad.

I've just tested with super-xbr and lancoz for both chroma upscaling and image doubling, yet madVR still crashes. This time, it seems to crash while I pause the video not during the playback.

Just to be make sure, I also tried lowering the GPU queue size one notch at a time yet, it still crashes on any values (from 8 to 4).

I've attached two more bug report while using super-xbr and lancoz respectively.

Argh this is driving me crazy...

madshi

2016-07-15 09:04

administrator   ~0001391

These two crashes are in error diffusion. It seems to me as if at some point suddenly some Direct3D texture can't be allocated or is freed from outside of madVR or something like that. Possible explanations:

1) Running out of GPU RAM.
2) A bug in madVR. But why do most people not seem to have this problem?
3) A GPU driver issue. Have you tried different GPU driver versions?
4) Maybe some 3rd party component (DirectShow filter or hook dll) screwing things up? E.g. some GPU overclocking or monitoring or OSD tool?

Probably disabling error diffusion would get rid of these crashes.

ggxtreme

2016-07-15 15:17

reporter   ~0001392

Last edited: 2016-07-16 02:27

I remember the crash dump specifically mentioning OpenCL.dll, amdocl.dll and/or amdocl64.dll. I have been testing with the latest AMD APP SDK installed as well, although trying to use the APP SDK OpenCl version with the newer 16.x drivers results in total loss of OpenCl detection when checked with gpu-Z and causes madVR to revert to using non-OpenCl settings. Are you using –cl-std in your build options by any chance?

I will retest with driver verifier running to see if I can produce a reliable crash dump. I don't know if it's that others aren't having the issue or if there aren't many people running the R9 3XX + NNEDI3 combination. I also had the same issue testing with an R9 280X (Crimson 16.x BSoD, Catalyst 15.x works fine). I tried MPC-HC and MPC-BE for good measure.

The BSoD doesn't happen every single time for me, I can open the same file over and over again without issue but on the first/second/eighth/etc. time I will get the BSoD.

Edit: Possible workaround? http://forums.guru3d.com/showpost.php?p=5277469&postcount=9

kanade

2016-07-16 22:58

reporter   ~0001395

With error diffusion off (using random dithering instead), I still experience the "crash" but this time it's a bit different.

Instead of freezing for a few seconds and then getting madVR crash dialog, I didn't get any crash dialog at all as I only got "display driver stop responding and has recovered" notification from the taskbar.
To be more specific:
- Freezes for a few second
- Unfreezes and then I get the notification from the taskbar
- Potplayer/madVR didn't crash at all
- Able to resume the video however the screen is pitch black
- I can hear the audio though

As a result, I wasn't able to obtain crash reports.

Just to go over your points:
1) Like I've said before, I'm not running out of GPU RAM. So I can probably cross this one off
2) According to ggxtreme and other AMD R9 users, it seems to happen on AMD only
3) Apart from 15.12, I haven't tried drivers below 16.5.1. Though I'm pretty sure I'd get the same result.
4) No overclocking or any 3rd party components which might hinder madVR being used at the moment

@ggxtreme
Sorry, I don't know what "–cl-std" is. I do know for a fact that the new OpenCL version being used by the current crimson drivers is screwing up madVR big time.

Have you tried that solution from the link you've provided?

I'm eager to try it though I actually use the "video tab" from Crimson which, I'm not sure if I should go on or not.

I could set the options in the video tab first before replacing those files. Though the user mentions specifically that one should "reboot straight into safe mode" after the installation of crimson driver.

madshi

2016-07-16 23:20

administrator   ~0001396

You get this driver crash even with both NNEDI3 and error diffusion disabled? Can only imagine that this is some sort of driver bug. Don't know what else it could be, unfortunately.

ggxtreme

2016-07-17 06:51

reporter   ~0001397

The -cl-std question was directed at madshi based on something I read about AMD changing OpenCL version detection requirements in their newer packages.

I've never experienced a crash with NNEDI3 disabled. I'm currently redoing my PC for Windows 10, so I'll be able to test once I'm done with that.

madshi

2016-07-17 10:02

administrator   ~0001398

I don't know what –cl-std is, either.

kanade

2016-07-22 10:39

reporter   ~0001403

Hmm, so there's nothing we could do except for changing the card to Nvidia?

Also, if you're still here ggxtreme, have you tried testing that possible solution above?

madshi

2016-07-22 10:45

administrator   ~0001404

Well, it's not that NVidia GPUs run perfectly, either, but at least there's no blue screen. There are sometimes problems with NNEDI3 not working, either, though.

Weird thing is it works all fine for many AMD and NVidia users. Just some have problems, not sure why.

ggxtreme

2016-07-25 07:15

reporter   ~0001409

Sorry for the delay, I ran into some other issues getting Windows 10 stable. I should be able to fully test things tomorrow and report back.

ggxtreme

2016-07-25 22:18

reporter   ~0001410

Last edited: 2016-07-25 22:21

Well I tested a bit using the latest version of madVR on my new Windows 10 install using the latest 16.7.2 Crimson hotfix drivers, and it hasn't crashed for me yet. Actually, it's behaving a bit differently.

I should mention that I have MPC-BE set to automatically change my display resolution and refresh rate based on the source. It is similar to the madVR functionality that does the same thing, which I also tried with the same results (but I like the delay option in MPC-BE). So normally opening a file goes like this: open file->flicker on resolution change->video plays

With NNEDI3 enabled, sometimes this would happen instead: open file->flicker->no signal->(delay)->flicker->Windows Error Report/BSoD/black screen/still no signal. Even before the actual crash, it was obviously different than a successful launch and I could tell if it was going to crash or not.

Well now when I play videos, occasionally I still get the pre-crash behavior, only now it's recovering and playing the file. Even though it's not crashing now, the behavior is still odd, as in the same file might play once normally (open file->flicker->video plays), but sometimes it does something like: open file->flicker->MPC-BE logo->flicker->black screen->flicker->no signal->(delay)->flicker->video starts playing. Almost like something happened, but it recovered and simply tried again.

Unfortunately, I can't provide my own crash log unless it does actually crash for me again. So maybe not very helpful for those having the issue. But the crash dump from this post is very similar to what I used to get when the issue occurred: https://www.svp-team.com/forum/viewtopic.php?pid=56067#p56067

Since I was also on Windows 7 Ultimate 64-bit, perhaps there is an AMD driver issue that does not present itself with Windows 10. Or maybe it was something else all along, like an unrelated driver conflict.

kanade

2016-08-10 13:47

reporter   ~0001422

Sorry for the late reply ggxtreme, and thanks for your feedback. I really appreciate it.

With that being said, I guess this is it. I just tried using the latest driver and the crash/freeze is still present.
Replacing OpenCL files with the older version seems to work in exchange for buggy UI for Crimson Radeon settings.

It looks like a permanent solution is to either:
- Stay on working older drivers which doesn't produce this problem, in exchange for not being able to play the latest games
- Use latest driver with older openCL files, but causes all sorts of bugs within Radeon settings

Regardless what I choose, I'm on the losing sides.

Madshi, I might be asking for impossible here but I'm just curious, are you planning to release some sort of "fix" in the future for this problem? Or have you decided to close this problem for good?

madshi

2016-08-10 14:24

administrator   ~0001423

One user recently notified me that with the latest AMD drivers, when you switch between 64bit and 32bit media players, there's a problem, but if you don't, everything's fine.

madVR creates the OpenCL kernels only once (per driver version) and stores them in the registry. It seems with the latest AMD drivers if you try to use OpenCL kernels compiled in 64bit in a 32bit media player, there's a crash.

So try cleaning out the registry, then stick to one media player bitdepth, and maybe that helps working around the problem for now?

I'm planning to separate OpenCL kernels into 32bit vs 64bit in a future version.

Interestingly, older AMD drivers, and NVidia and Intel drivers have no problem reusing the same OpenCL compiled kernels in both bitdepths.

kanade

2016-08-11 20:24

reporter   ~0001436

I've been only using 64bit potplayer for the last year or so. Though I did use 32bits few years ago. This was when potplayer didn't have 64bit player available so yeah... It was only a year ago when they started to release 64bit version.

Regarding to OpenCL kernels, just to clarify: you're talking about AMD drivers correct? In other words, it creates kernels once per drivers that I've installed for the last couple of months? And this wasn't the problem on older AMD drivers as it has no problems using the same kernels?

All in all, exactly what registry do I need to clean it out? I tried searching regedit and I'm lost as to which one I need to look for.

madshi

2016-08-11 21:20

administrator   ~0001437

With the latest madVR build the OpenCL kernel is now saved separately between 32bit or 64bit. No need to cleanup the registry. Does it help?

kanade

2016-08-22 18:48

reporter  

kanade

2016-08-22 18:52

reporter   ~0001448

After testing the new version for a while, it seems to work fine until today where I've just encountered the crash. I attached the bug report.

FYI, I'm currently using the latest AMD driver (16.8.2) and, NNEDI3 for both chroma and image doubling.

madshi

2016-08-22 19:00

administrator   ~0001449

Looks like a crash during NNEDI3 chroma upscaling. Can't say much more about it, unfortunately.

kanade

2016-08-22 20:03

reporter  

kanade

2016-08-22 20:03

reporter   ~0001450

This one as well? This time, I was using super-xbr for both scalings.

madshi

2016-08-22 20:15

administrator   ~0001451

That one seems to crash during error diffusion.

kanade

2016-08-22 20:27

reporter   ~0001452

Jesus Christ, so they weren't even related to openCL?

I'll change it to random dithering and see how it goes...

madshi

2016-08-22 20:36

administrator   ~0001453

I already told you about the error diffusion crashes in comment 1391.

The first crash from today was in NNEDI3 upscaling, though, as I said. Maybe both OpenCL (NNEDI3) and DirectCompute (OpenCL) are unstable? It's also possible that DirectCompute might make NNEDI3 unstable, I don't know...

kanade

2016-10-03 20:48

reporter   ~0001471

Just an update: it seems to only freeze/crash when I pause the video during playback.

If I just let the video play continuously, it seems to work fine without any issues.

Any ideas why this might be the case? I'm still using AMD 16.7.3 and madVR 0.90.24 and I'm not sure if the problem will happen on the latest beta drivers.

PaulCoddington

2016-10-23 11:24

reporter   ~0001473

I'm seeing an issue that may be related, as I recently lost video playback in JRiver Media Center for no apparent reason (possibly the Anniversary Update for Windows 10 and/or the latest AMD driver update would be about the right timing).

Symptoms: 1) Playback of video gives black screen with sound only, and JRiver crashes when attempting to halt playback (windowed and full screen). 2) Less aggressive settings (madVR defaults) allows video to play, but right-click context menu causes screen to go black or freeze (as in point one, same crash). Context menu is incomplete as well - no plugins section.

I found, however, that if I keep all my usual settings and simply click the option to use "Direct3D 11 for Presentation", the problem goes away and everything works fine again.

[In the course of troubleshooting I also copied the latest version of madVR into the JRiver plugins folder as JRiver turned out to be a little behind.]

Hope this helps.

huhn

2016-10-23 14:47

reporter   ~0001474

DX9 present in advanced is broken in AMD driver for about a month now.

kanade

2016-10-23 22:04

reporter   ~0001475

Last edited: 2016-10-23 22:06

@PaulCoddington
Thanks for the info Paul. I'll try enabling "Direct3D 11 for Presentation" and see how it goes. I never thought of using Direct 11 instead of 9 for video playback. Did you also enabled "present a frame for every VSync" as well?

@huhn
I'm guessing this is unrelated to my current problem? Because it began ever since the introduction of Crimson drivers.

huhn

2016-10-24 09:02

reporter   ~0001476

no i don't think so. but DX9 windowed present in advance isn't working for every AMD user.

madshi

2018-01-14 15:34

administrator   ~0002041

Since these are all driver issues and not madVR's fault, and since NNEDI3 was recently completely replaced by NGU Anti-Aliasing, I'm going to close this bug report.

Issue History

Date Modified Username Field Change
2016-07-12 23:40 kanade New Issue
2016-07-12 23:40 kanade File Added: madVR crash bug text.zip
2016-07-12 23:45 madshi Note Added: 0001386
2016-07-13 00:09 kanade Note Added: 0001387
2016-07-14 08:54 ggxtreme Note Added: 0001388
2016-07-14 08:55 ggxtreme Note Edited: 0001388
2016-07-14 09:49 madshi Note Added: 0001389
2016-07-15 06:16 kanade File Added: madVR crash report (super-xbr).zip
2016-07-15 06:16 kanade File Added: madVR crash report (lancoz).zip
2016-07-15 06:19 kanade Note Added: 0001390
2016-07-15 09:04 madshi Note Added: 0001391
2016-07-15 15:17 ggxtreme Note Added: 0001392
2016-07-15 15:19 ggxtreme Note Edited: 0001392
2016-07-15 15:21 ggxtreme Note Edited: 0001392
2016-07-15 15:27 ggxtreme Note Edited: 0001392
2016-07-15 15:30 ggxtreme Note Edited: 0001392
2016-07-16 02:27 ggxtreme Note Edited: 0001392
2016-07-16 22:58 kanade Note Added: 0001395
2016-07-16 23:20 madshi Note Added: 0001396
2016-07-17 06:51 ggxtreme Note Added: 0001397
2016-07-17 10:02 madshi Note Added: 0001398
2016-07-22 10:39 kanade Note Added: 0001403
2016-07-22 10:45 madshi Note Added: 0001404
2016-07-25 07:15 ggxtreme Note Added: 0001409
2016-07-25 22:18 ggxtreme Note Added: 0001410
2016-07-25 22:20 ggxtreme Note Edited: 0001410
2016-07-25 22:21 ggxtreme Note Edited: 0001410
2016-08-10 13:47 kanade Note Added: 0001422
2016-08-10 14:24 madshi Note Added: 0001423
2016-08-11 20:24 kanade Note Added: 0001436
2016-08-11 21:20 madshi Note Added: 0001437
2016-08-22 18:48 kanade File Added: madVR crash on 0.90.24.zip
2016-08-22 18:52 kanade Note Added: 0001448
2016-08-22 19:00 madshi Note Added: 0001449
2016-08-22 20:03 kanade File Added: super-xbr (0.90.24).zip
2016-08-22 20:03 kanade Note Added: 0001450
2016-08-22 20:15 madshi Note Added: 0001451
2016-08-22 20:27 kanade Note Added: 0001452
2016-08-22 20:36 madshi Note Added: 0001453
2016-10-03 20:48 kanade Note Added: 0001471
2016-10-23 11:24 PaulCoddington Note Added: 0001473
2016-10-23 14:47 huhn Note Added: 0001474
2016-10-23 22:04 kanade Note Added: 0001475
2016-10-23 22:06 kanade Note Edited: 0001475
2016-10-24 09:02 huhn Note Added: 0001476
2018-01-14 15:34 madshi Note Added: 0002041
2018-01-14 15:34 madshi Status new => closed
2018-01-14 15:34 madshi Assigned To => madshi
2018-01-14 15:34 madshi Resolution open => no change required