Random crash on close or video change

[ajgelado]

About 25% of times, when advancing to the next video or closing MPC, it crashes and generates a crash report. It happens both with versions 1.8.19 and 2.2.1. It doesn't happen with the last stable "classic" version, 1.7.13. Other video players don't show the problem, and it happens with files of different formats and encodings, so it doesn't look like it is caused by a codec or driver. Anyway, I have tried different renderers, both with DX9 and DX11, and nothing solves the problem.

This is one of the crash reports uploaded to Doctor Dump: https://drdump.com/UploadedReport.aspx?DumpID=129078898

And this is the information from the About dialog:

MPC-HC (64-bit)
---------------

Build information:
    Version:            2.2.1 (30fc3853b)
    Build date:         Apr 10 2024

LAV Filters:
    LAV Splitter:       0.79.2.0
    LAV Video:          0.79.2.0
    LAV Audio:          0.79.2.0
    FFmpeg compiler:    MinGW-w64 GCC 13.2.0

Operating system:
    Name:               Windows 10 (Build 22H2)
    Version:            10.0.19045 (64-bit)

Hardware:
    CPU:                Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz
    GPU:                Intel(R) UHD Graphics 630 (driver version: 26.20.100.7642)
    Monitor:            \\.\DISPLAY1 - BenQ GL940 (Digital) [1366x768 32-bit 96 DPI] - [Actual]

Text:
    Scale Factor:       1.000000
    Ansi Codepage:      1252

[adipose]

igdml64 is part of the intel graphics driver. Can you check your graphics driver?

UHD 630 I believe is Kaby Lake which is 7th gen Intel. See here:

https://www.intel.com/content/www/us/en/download/776137/intel-7th-10th-gen-processor-graphics-windows.html

[clsid2]

Does it also happen if you disable the seekbar preview?

[clsid2]

Update your graphics driver.

You can currently the only person with this specific crash on DrDump.

[ajgelado]

Does it also happen if you disable the seekbar preview?

Disabling it apparently solves the problem. Thank you! I hadn't thought about it.

Anyway, the preview is very useful when navigating large videos, and the problem (bug?) is still there, so I'd be glad to help you pinpoint the cause.

Update your graphics driver.

As far as I can see, I already have the latest version.

You can currently the only person with this specific crash on DrDump.

There has been over 80 reports on v2.2.1 (currently, 82). I just upgraded to that version yesterday (May 24th, for the record), but most of the crashes are older (many dating up to May 18th), and thus they can't be mine. So I'd say there are more people with the same problem. See https://drdump.com/DumpGroup.aspx?DumpGroupID=2633031.

I seem to recall that two weeks ago, when the crashes started happening (around May 10th), I received a message from MPC telling me to disable video decoding acceleration. It all started happening out of the blue, without installing or updating anything, and I had a reboot planned for a few days later, so I chose to wait and see. Unfortunately, I didn't record the message's contents.

After the reboot on Patch Tuesday (May 14th), the crashes stopped happening. But after a few quiet days, they reappeared two days ago (and without the video acceleration message). All that time, up until yesterday, I have been running v1.8.19. And no, during the reboot, no new drivers were installed. In fact, I haven't been offered updates to any drivers in the last months.

[ajgelado]

I have been thinking... The dump refers DX9 even when I instruct the renderer to use DX11, the crashes disappear when the seek bar preview is disabled, and the crashes are always when closing MPC or switching to a new video. So I think we can say that this is related to the thumbnail generation, probably while freeing resources. Could it be a race condition hit while freeing a buffer used by the preview? Maybe some update to a shared DLL slightly changed the order in which something is processed and made this bug surface. I have seen that happen in the past. It's a shot in the dark, as I haven't looked at MPC's code, so I could be wrong...

In fact, while writing this I decided to look at the stack of one fo the crashes, and found this:

mpc_hc64!CFGManagerCapture::`vector deleting destructor'+0x14
mpc_hc64!CUnknown::NonDelegatingRelease+0x26
mpc_hc64!CMainFrame::ReleasePreviewGraph+0x14b

This looks a lot like what I had in my mind.

[clsid2]

Seekbar preview uses EVR-CP as renderer. That can not and will not be changed.

The crash is in the Intel driver and I see absolutely no evidence at all that this is a bug in the player.

[clsid2]

You are not using latest driver.

31.0.101.2127 https://www.intel.com/content/www/us/en/download/776137/intel-7th-10th-gen-processor-graphics-windows.html

[ajgelado]

Windows Update does not offer a newer version of the driver. In my experience, drivers provided by Windows Update (and curated by them) tend to be way more stable than manufacturer's ones, which often favor performance over stability. And, as I said, MPC has worked without trouble with this driver for months. So something else must be causing it.

Anyway, I'll try to remember to update the driver on next Patch Tuesday and tell you how it goes. I hope the manufacturer's driver does not cause any other problems...

[adipose]

Windows does not reliably update graphics drivers, and you don't have to wait for patch Tuesday to update them.

I remember a long time ago Nvidia was telling people not to use the WHQL version for some cards because it caused crashing. WHQL is not a magic bullet.

[ajgelado]

I beg to differ. I have been using several flavours of NT for the last 30 years, and I can assure you that roughly 90-95% of times I see a bluescreen on somebody's computer (customers, friends, relatives...), it's a faulty driver (the remaining being hardware problems). Drivers from WHQL greatly decrease the probability of a bluescreen, up to the point that hardware failures become almost the sole cause. In my PCs, in fact, I haven't seen a driver-caused bluescreen for decades!

The PC in which I'm having the problems is used for development, both of web and desktop apps. Among many other things, it runs 24/7 a web server which hosts development and QA versions of my customer's webs. Yes, it could be rebooted any time. But it causes downtime, so I batch with the Patch Tuesday's night all non-essential reboots. Also, that's the reason why I'm so reluctant to upgrade drivers: it's safer to just use a different video player than to risk replacing a driver which does not cause stops. Specially if that's a "what if" scenario on a machine used for work.

[adipose]

WHQL drivers crash all the time. Case in point, the driver you have currently installed.

But anyway, 101 that I linked is WHQL certified.

[adipose]

https://community.intel.com/t5/Graphics/Intel-UHD-630-video-driver-breaks-winows-10-toolbar-transparency/m-p/1212386#M90117

I found this old thread where Intel opines that build 7642 is not an official build but a Microsoft or OEM modified build. That was in 2020 and version 27 had already been released.

I have an older Intel box so I will see if I can possibly reproduce the issue on 26.x.

[clsid2]

BSoDs are so rare because the newer driver model in Win10/11 allows to restart the driver when it crashes. Heck, Windows even has a keyboard shortcut to manually restart the driver (Win+Ctrl+Shift+B).

These 88 crashes are all from same userid (which must be yours): https://drdump.com/DumpGroup.aspx?DumpGroupID=2633031 Plus 442 more (starting in March): https://drdump.com/DumpGroup.aspx?DumpGroupID=2583085

There are similar dumps from a few other users. But given the tiny amount of affected users, it must be very specific circumstances in which problem occurs. Perhaps driver is simply in a bad state. One thing is certain, it is not the fault of the player.

Disable "fast startup" in the Windows power settings and reboot to get a proper fresh boot with clean state for all drivers.

[ajgelado]

The user ID in those crash reports must be mangled. I have not experienced crashes in MPC before this month, and I have not had v2.2.1 installed until Friday afternoon, that is, May 24th. It's completely impossible those crash reports are mine. Also, 442 crashes for the same user in just a couple of months? It would make an average of several crashes a day. If a piece of software crashes so frequently, you either solve the problem or switch to another one.

Anyway, I do love MPC. You do a great job with it. It's simple to use, flexible and customizable and (up until two weeks ago) rock solid. As a developer, I do know all the work which goes into making an usable product. I use MPC in all my computers, and recommend it to friends and relatives. Of course, I'd like to continue using it (currently, with video preview disabled, it works for me). And I'd love to contribute to it, or at the very least, help improve it. If it weren't so important for me, I wouldn't use all this time.

[adipose]

If the crash is new can you confirm the last good version?

Lots of builds including dev builds.

[clsid2]

Even ancient versions have the issue: https://drdump.com/Problem.aspx?ProblemID=188100 https://drdump.com/Problem.aspx?ProblemID=361824

[adipose]

On 6/26/21 we switched to using EVR-CP for preview.

Next build was 1.9.14.

According to @ajgelado 1.8.19 was broken. That doesn't seem to be an actual build but maybe he means 1.9.19.

[clsid2]

The problem is not specific to preview. It also happens with regular playback and vanilla EVR. Links above are for builds as old as 1.7.9.

Don't waste your time on what is clearly a driver bug.

[adipose]

Oh good point. Forgot about regular use of EVR-CP.

[ajgelado]

If the crash is new can you confirm the last good version?

I have found it happens in 1.9.18 (sorry, I swapped "8" and "9") and 2.2.1. The last known good version is 1.7.13, the last one prior to the fork, which I tested running a portable. In 2.2.1, the problem disappears disabling the preview. I haven't done the test in 1.9.18 because I no longer have it installed.

[clsid2]

What exactly are you playing? The crash dump indicates that you are using capture.

[ajgelado]

I'm playing MP4 files downloaded from sites using third party tools. As far as I know, they are fairly standard MP4 files, encoded in H264. AFAIK, the only unusual thing on them is that they have fewer keyframes than usual, which decreases file size, makes seeking slow, and may put more strain in the seek preview.

Edit: these are the contents of the MediaInfo tab on the Properties dialog on one of the files:

General
Complete name                  : <redacted>
Format                         : MPEG-4
Format profile                 : Base Media
Codec ID                       : isom (isom/iso2/avc1/mp41)
File size                      : 328 MiB
Duration                       : 57 min 9 s
Overall bit rate mode          : Variable
Overall bit rate               : 803 kb/s
Frame rate                     : 30.000 FPS
Writing application            : Lavf57.71.100

Video
ID                             : 1
Format                         : AVC
Format/Info                    : Advanced Video Codec
Format profile                 : High@L3.2
Format settings                : CABAC / 4 Ref Frames
Format settings, CABAC         : Yes
Format settings, Reference fra : 4 frames
Codec ID                       : avc1
Codec ID/Info                  : Advanced Video Coding
Duration                       : 57 min 9 s
Bit rate                       : 700 kb/s
Width                          : 1 280 pixels
Height                         : 720 pixels
Display aspect ratio           : 16:9
Frame rate mode                : Variable
Frame rate                     : 30.000 FPS
Minimum frame rate             : 29.762 FPS
Maximum frame rate             : 30.242 FPS
Color space                    : YUV
Chroma subsampling             : 4:2:0
Bit depth                      : 8 bits
Scan type                      : Progressive
Bits/(Pixel*Frame)             : 0.025
Stream size                    : 286 MiB (87%)
Writing library                : x264 core 152 r2854 e9a5903
Encoding settings              : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x133 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=700 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Codec configuration box        : avcC

Audio
ID                             : 2
Format                         : AAC LC
Format/Info                    : Advanced Audio Codec Low Complexity
Codec ID                       : mp4a-40-2
Duration                       : 57 min 9 s
Bit rate mode                  : Variable
Bit rate                       : 96.0 kb/s
Maximum bit rate               : 128 kb/s
Channel(s)                     : 2 channels
Channel layout                 : L R
Sampling rate                  : 44.1 kHz
Frame rate                     : 43.066 FPS (1024 SPF)
Compression mode               : Lossy
Stream size                    : 39.4 MiB (12%)
Default                        : Yes
Alternate group                : 1

[adipose]

If you use EVR-CP as your primary output can you crash it with seek preview disabled?

[ajgelado]

I have been using EVR-CP all the time. Except for the tests last Friday, when I tested other renderers and tried to switch between DX9 and DX11, of course. But I wrote down the settings I changed and reverted them after the tests, returning to EVR-CP.

I can confirm that with seek preview disabled, EVR-CP works perfectly with my current setup (including Intel drivers version 26.20).

This is getting stranger with each turn...

[adipose]

Well let us know how it goes with updated drivers.

[clsid2]

Try 1.9.14 which uses vanilla EVR instead of EVR-CP for preview (since 1.9.15).

With preview disabled you might need to use multiple player instances to trigger the problem.

Given that the problem only started two weeks ago, any other changes to the system besides a Windows update?

[ajgelado]

That's another thing that puzzles me. Before the crashes started (about May 10-12th), there hadn't been any changes to the system since April's Patch Tuesday (April 9th), almost a month before. I don't remember installing anything more than small utilities (unzipped manually, so I know they contain no system components), and I certainly didn't reboot between April 10th and May 14th.

And that buggers me. MPC 1.9.18 and Intel drivers v26 have been working for months without problem, and then started failing out of the blue. Even for a hidden bug to surface, something has to change. But I can not remember anything changing around those dates, nor there isn't anything in my notes.

Tonight I'll try to open several instances of MPC so I can trigger the bug.

[clsid2]

Are you running any other apps at same time that use the GPU? Like browsers, Discord, games, crypto stuff?

Also try restart driver (Win+Ctrl+Shift+B) without having to reboot.

[adipose]

Since you don't want to go through Intel for the driver, see below.

https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=2652d2e6-635e-4560-a062-ca0faa80e54a#PackageDetails

Hardware id for UHD 630 is 9bc8 per here.

Windows update catalog shows the latest driver they have is 31.x released 11/2023. Are you sure there is no driver update in optional updates?

[ajgelado]

No, the updated driver does not show in Windows Update, even under the optional updates section. I checked that before saying there was no update available, and have re-checked it now.

Device Manager on my computer shows the device ID is 3E91. The Intel page lists that as one of the several IDs for UHD 630 (another one being the one you cite, 9BC8). But the Windows Update page lists a completely different set of IDs, of which 9BC8 is the only one in common with Intel's page, and which does not include the one in my system, 3E91. That explains why it doesn't show on Windows Update.

I have been trying to trigger the crash by opening several instances of MPC, but so far I haven't been able to. And now I'm not getting the crash on close, either. A couple of days ago I restarted the driver with Win+Ctrl+Shift+B. It must have something to do with it: after the reboot on May 14th, the crashes stopped for a while, and returned after a week or so.

It's not that I don't want to update the driver. As I said before, I try to avoid unnecessary reboots, and tend to defer updates to system software on Patch Tuesday.

[adipose]

There are a lot of packages that match 630. Thanks for your ID. Here's the update for that one:

https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=c0b5b330-cfd4-4138-8042-cc2f7fe44a74#PackageDetails

This one refers to 3E91. 31.0.101.2115, release 11/2022.

[clsid2]

If crash occurs again after a while, see if restarting the driver fixes it again for a period. Driver bug could be something like a resource leak that only causes problems after long or frequent use.

[ajgelado]

Thanks for the link. It's strange that it doesn't show on Windows Update.

I'll stay on v26 for the moment and see if I can trigger the crash, and on which circumstances it happens, or if restarting the driver indeed solves it (as it seems).

[adipose]

I'll stay on v26 for the moment and see if I can trigger the crash, and on which circumstances it happens, or if restarting the driver indeed solves it (as it seems).

But patch Tuesday..... ;) Oh, I guess that's the 11th.

[ajgelado]

Yes, on June 11th, I'll update to v31. Anyway, I'll keep you informed on what I see, be it crashes with v26 before the 11th, or the results of updating to v31 after that.

[ajgelado]

A few days ago MPC has started crashing again. But it hasn't been until today that I have had time to stress-test it. All the tests I have done and that I'm reporting here are with Intel UHD v26 and MPC v2.2.1. You won't see the crash reports in Dr. Dump because I have disabled crash reporting in order to speed up the tests: with crash reporting enabled, every time MPC crashes, the default browser gets the focus and opens the crash report page, making me close the tab an minimize it before noting down of the crash and launching MPC again. This can be quite cumbersome when I'm getting several crashes every minute. But, as the crashes are easily reproducible, I can generate reports easily if you need them.

These are the test results:

With video previews enabled, MPC crashes on average one in 7 times I advance to the next video. It has never crashed on the first advance, and in a couple of runs it has taken more than 20 advances, but most times it crashes in the second to fourth one.

If I disable video previews, it does not crash at all, or at least I haven't been able to make it crash after advancing to the next file 100 times (yes, I have prepared a directory with a lot of videos to test it).

Changing the video renderer to MPC's default one (which disables EVR), but leaving video previews enabled does not stop the crashes. Sorry for not being more specific. MPC shows in Spanish, where the renderer I used for this test is labelled as "Renderizador de vídeo de MPC", which would translate into English as "MPC video renderer". It is the first one in the list.

So far, this is what we expected. But here is when it get weird.

If I enable video preview, close and reopen MPC, and then, while a video is playing, I deactivate video preview, the crash happens even with video preview disabled.

And if I disable video preview, reboot MPC, and with a video playing, I enable video preview again, it does not crash at all.

Thus, the crash seems to be related not to the status of video previews at the time of the crash, but with its status when MPC was started.

[clsid2]

Disabling preview during playback just hides it. Enabling it during playback does nothing until player restart.

The crash is outside of player code. I can not fix it.

[ajgelado]

Enabling it during playback does nothing until player restart.

It is logical. But what surprises me is that it does not crash if video previews are activated after MPC has been opened. Also, note that all the tests where MPC has crashed has been done with the enhanced EVR renderer (except for the ones where I explicitly changed it), so I'd say it has little to do with the video preview using EVR.

I wish I had time to take a look at the code base. Diving into a project you haven't worked with can take a lot of time, time I currently don't have...

[clsid2]

Enabling the option does not activate it until the player is restarted. So it is not active!

I have already said several times that this is not a fault in the player. Looking at the code base is pointless...

Go submit a bug report to Microsoft or Intel.