qctools Version 7.3 for Windows is crashing or not responding

[glwhicks]

Hi all! AMIA was fantastic! Great to see the qctools presentations and meet everybody. I downloaded Version 7.3 for Windows before I left for Pittsburgh on our machines and was eager to get get started Qcing with my new found knowledge, but alas, most of the press files(.mkv) have caused the program to either crash or simply not respond. I did get one file to open. We use: Dell computers running Windows 7 Enterprise 64-bit Operating System, 16GB RAM, Intel(R) Xeon(R) CPU E5-1620 v3 @3.50GHz

[dericed]

Thanks Glenn. Can you run ffmpeg -i ON_YOUR_CRASHY_FILE.mkv and post the results here, so we can recreate this. Is there a particular point where it crashes (before graphing, when opening player, etc)?

[glwhicks]

I'll try running the ffmpeg tomorrow, but it crashes before anything comes up on the screen, so before graphing.

[dericed]

Also you could try opening QCTools, go to the preferences and deselect some of the filters, then open the file. Possible that the combination of filter and file is the issue.

[iwsundstrom]

Hi, this is Ian Sundstrom, working with Glenn at MDPI. I ran a .mkv that cannot open in QCTools through FFMPEG, and it completed without any errors. Here is a report log from running the file through FFMPEG:
ffmpeg-20161116-115854.zip
I also tested the file using the different filters in preferences, but the file still caused crashes. For the first time, I also began receiving error reports from QCTools when it crashed or froze (although this seems unrelated to changing the filters, as restoring them to the defaults still resulted in error reports). Here are a couple examples of them (from two separate crashes):


Let me know if you want me to try anything else out!

[dericed]

Extract of log:

ffmpeg started on 2016-11-16 at 11:58:54
Report written to "ffmpeg-20161116-115854.log"
Command line:
ffmpeg -report -i "E:\\20161110-VHS-Memnon_Archiving_Services_Inc\\MDPI_40000002189225.20161110-175707\\data\\MDPI_40000002189225_01_pres.mkv" "E:\\test\\2189225_out.mkv"
ffmpeg version N-82324-g872b358 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.0 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-libebur128 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-decklink --enable-zlib
  libavutil      55. 36.100 / 55. 36.100
  libavcodec     57. 66.101 / 57. 66.101
  libavformat    57. 57.100 / 57. 57.100
  libavdevice    57.  2.100 / 57.  2.100
  libavfilter     6. 66.100 /  6. 66.100
  libswscale      4.  3.100 /  4.  3.100
  libswresample   2.  4.100 /  2.  4.100
  libpostproc    54.  2.100 / 54.  2.100

[...]

Input #0, matroska,webm, from 'E:\20161110-VHS-Memnon_Archiving_Services_Inc\MDPI_40000002189225.20161110-175707\data\MDPI_40000002189225_01_pres.mkv':
  Metadata:
    title           : VIETNAM A TELEVISION HISTORY
    DATE_DIGITIZED  : 2016-11-03
    BARCODE         : 40000002189225
    DESCRIPTION     : Indiana University-Bloomington. Herman B Wells Library. DS558 .V48 1987 v.2. File use: Preservation Master. Original filename: MDPI_40000002189225_01_pres
    COMMENT         : File Created by Memnon Archiving Services
    ENCODER         : Lavf57.0.100
  Duration: 02:03:47.55, start: 0.000000, bitrate: 77859 kb/s
    Stream #0:0, 1, 1/1000: Video: ffv1 (FFV1 / 0x31564646), yuv422p10le, 720x486, SAR 9:10 DAR 4:3, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
    Metadata:
      ENCODER         : Lavc57.1.100 ffv1
      DURATION        : 02:03:47.553000000
    Stream #0:1, 1, 1/1000: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s (default)
    Metadata:
      ENCODER         : Lavc57.1.100 pcm_s24le
      DURATION        : 02:03:47.553000000
    Stream #0:2, 1, 1/1000: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s (default)
    Metadata:
      ENCODER         : Lavc57.1.100 pcm_s24le
      DURATION        : 02:03:47.553000000
    Stream #0:3, 1, 1/1000: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s (default)
    Metadata:
      ENCODER         : Lavc57.1.100 pcm_s24le
      DURATION        : 02:03:47.553000000
    Stream #0:4, 1, 1/1000: Audio: pcm_s24le, 48000 Hz, mono, s32 (24 bit), 1152 kb/s (default)
    Metadata:
      ENCODER         : Lavc57.1.100 pcm_s24le
      DURATION        : 02:03:47.553000000
Successfully opened the file.

[ElderOrb]

Crash is not reproducible on my Windows 10 x64. Is it possible to produce crash dump or provide me with sample video causing crash ?

[ElderOrb]

Here are the steps for producing crash dump:

1. Download procdump from here: https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
2. Extract into any folder you like
3. Launch cmd.exe, navigate to the procdump folder
4. From command line execute the following: procdump.exe -e -ma -w qctools.exe
5. Make qctools.exe to crash, dump should be created inside the procdump folder

[glwhicks]

Thanks for looking into this. Here's some additional information: The files we are QCing are 45Gb to 95Gb (1.5 hours to 4 hours in content length)in size, possibly making it difficult to provide you with a sample file, in addition to us not being permitted to share the files outside of our lab. More often than crashing, the program just won't respond. We've never been able to successfully load anything with a file size that is much larger then 40Gb. This has been consistent with our experience concerning large files we've encountered in the past with other formats, as well. We are now into a large run of VHS files, most of which are 2hrs or longer(60Gb-95Gb). We are unable to use QCTools to QC these files. It is our hope that in the near future QCTools will be able to accommodate larger file sizes. I'm not sure if theses two issues are related.

My associate, Ian, will run a crash dump on one of our offending files. Hopefully by the end of today.

Glenn Hicks
Quality Control Specialist
Indiana University-MDPI
[email protected]
(812)320-7410

---

From: elderorb [email protected]
Sent: Thursday, November 17, 2016 3:26 PM
To: bavc/qctools
Cc: Hicks, Glenn William; Author
Subject: Re: [bavc/qctools] qctools Version 7.3 for Windows is crashing or not responding (#218)

Crash is not reproducible on my Windows 10 x64. Is it possible to produce crash dump or provide me with sample video causing crash ?

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/218#issuecomment-261359715, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APlXikHfnOcMDj8HlF-T1XHcwWcFjPV7ks5q_Lh0gaJpZM4Kx18p.

[iwsundstrom]

Here's a procdump for a different file. The file I used for the FFMPEG log wouldn't cause QCTools to crash today (it would simply not respond to being dragged into the program), and thus couldn't produce a procdump, so I opted for one that was causing a crash.

Here is the file: https://www.slashtmp.iu.edu/files/download?FILE=isundstr%2F96274TJlbiI
The password is: qctools2016

[dericed]

This command provides a close sample to @iwsundstrom except I'm not exactly sure how to replicate the 1/1000 timebase that file uses.

ffmpeg -f lavfi -i mandelbrot=s=720x486:r=29.97 -f lavfi -i sine -f lavfi -i sine -f lavfi -i sine -f lavfi -i sine -pix_fmt yuv422p10le -c:v ffv1 -aspect 4/3 -c:a pcm_s24le -ar 48000 -map 0 -map 1 -map 2 -map 3 -map 4 -vf settb=expr=1/1000 -af asettb=expr=1/1000 -t 3 test.mkv

Increase -t 3 if you want a longer sample.

Also @glwhicks @iwsundstrom can you confirm what settings you have in your preferences (what filter and first/all tracks).

[dericed]

@glwhicks You could probably just cut the first 100 MB off an example to replicate the issue.

[iwsundstrom]

We usually only use signalstats and PSNR filters, however, when you suggested testing a variety of different ones, we did so and QCTools still always crashed.

[dericed]

ok, i was suspicious of the audio, but apparently you're not even using that.

[glwhicks]

I was wondering about that as well, Dave. However, we've never been able to see the audio graph populate with any video format. My theory is the .mkv format might be the issue.

The VHS files have four channels of audio, 2 linear and 2 hi-fi. Might that be causing some problems, perhaps? However, I have a 47Gb(1hr 2mins) UMatic file with only two channels of audio that doesn't respond either.

Glenn Hicks
Quality Control Specialist
Indiana University-MDPI
[email protected]
(812)320-7410

---

From: Dave Rice [email protected]
Sent: Thursday, November 17, 2016 4:23 PM
To: bavc/qctools
Cc: Hicks, Glenn William; Mention
Subject: Re: [bavc/qctools] qctools Version 7.3 for Windows is crashing or not responding (#218)

ok, i was suspicious of the audio, but apparently you're not even using that.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/218#issuecomment-261373651, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APlXihx_A91wcLJmFGGEByFkFUayldA5ks5q_MXFgaJpZM4Kx18p.

[ElderOrb]

Thank you for the dump provided, looking at this. Could you please also check if the latest qctools snapshot behaves in the same way?

[dericed]

@JeromeMartinez created a debug version of the Windows build at https://mediaarea.net/temp/QCTools_0.7.3.20161118_Windows_i386_WithDebugInfo.zip. This contains the exe and the corresponding pdb file. @glwhicks @iwsundstrom could you re-test with this version.

[glwhicks]

I just tried the debugged version and the first file I dropped into it crashed it. It was a 55Gb .mkv file

[metacynicv2]

I'll give it a test on our Windows machine today and see if I get the same
results.

On Mon, Nov 21, 2016 at 8:00 AM, glwhicks [email protected] wrote:

I just tried the debugged version and the first file I dropped into it
crashed it. It was a 55Gb .mkv file

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#218 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AI_8UXpvWAznx6IlPOE94wMKHCDp9ZXEks5rAcAXgaJpZM4Kx18p
.

Kelly Haydon | Preservationist
415.558.2158 http://415.558.2158 | [email protected]
[email protected] | @bavcpreserve https://twitter.com/BAVCPreserve

Archivists can use the power of archives to promote accountability, open
government, diversity, and social justice. In doing so, it is essential to
distinguish objectivity from neutrality. - Howard Zinn

[ElderOrb]

@glwhicks Could you please collect crash dump for debug build? Release dump didn't reveal any obvious reasons for crash..

[ElderOrb]

@JeromeMartinez it is possible to produce 64bit build for Windows? Just thinking this random crashes could be 'out of memory' exception.

[metacynicv2]

I am loading a 40gig ffv1/mkv video file into the debugged Windows build
and so far no crashing (though it is slow but that is probably my machine).
OS is Windows 7 Professional, 64 bit.

Audio seems to be loading normally.

Not sure if this is relevant, but I do have an MDPI qctools report that
doesn't work at all in the recent Windows build, the application doesn't
crash but the graphs do not load.

On Mon, Nov 21, 2016 at 1:47 PM, elderorb [email protected] wrote:

@JeromeMartinez https://github.com/JeromeMartinez it is possible to
produce 64bit build for Windows? Just thinking this random crashes could be
'out of memory' exception.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#218 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AI_8UYrKDfQOuaZEKzo5JwTrSgLYNHZAks5rAhGDgaJpZM4Kx18p
.

Kelly Haydon | Preservationist
415.558.2158 http://415.558.2158 | [email protected]
[email protected] | @bavcpreserve https://twitter.com/BAVCPreserve

Archivists can use the power of archives to promote accountability, open
government, diversity, and social justice. In doing so, it is essential to
distinguish objectivity from neutrality. - Howard Zinn

[JeromeMartinez]

@JeromeMartinez it is possible to produce 64bit build for Windows?

We already provide 64-bit builds, look at "Windows_x64" in the snapshots.
For example Windows 64-bit 20161116.

For official release, the Installer has actually only 32-bit version despite the "Universal" name, but the "64 bit only without installer" is the pure 64-bit version.

Just thinking this random crashes could be 'out of memory' exception.

As it is a the start of the parsing, and also a 0x00000004 memory access, I bet more on a NULL pointer not tested somewhere.

[ElderOrb]

As it is a the start of the parsing, and also a 0x00000004 memory access, I bet more on a NULL pointer not tested somewhere.

Could be... But so far I managed to reproduce crash only in two cases:

1. Out of memory with ~20 ~5Gb mkv files (32 bit version only). Crashed after several seconds after opening files.
2. Access violation on attempt to open incomplete mkv. But in this case qctools crashed nearly immediately on opening file.

[dericed]

@kellyhaydon can you share the mdpi xml?

[metacynicv2]

I'm not sure I can here - @glwhicks https://github.com/glwhicks?

But the file is in our shared "qctools 2.0" google doc.

On Mon, Nov 21, 2016 at 4:49 PM, Dave Rice [email protected] wrote:

@kellyhaydon https://github.com/kellyhaydon can you share the mdpi xml?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#218 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AI_8UeJFSLwZSm88PkyY6CJAKTZHa-XCks5rAjwHgaJpZM4Kx18p
.

Kelly Haydon | Preservationist
415.558.2158 http://415.558.2158 | [email protected]
[email protected] | @bavcpreserve https://twitter.com/BAVCPreserve

Support BAVC today. *
*www.bavc.org/donate https://bavc.org/donate

Archivists can use the power of archives to promote accountability, open
government, diversity, and social justice. In doing so, it is essential to
distinguish objectivity from neutrality. - Howard Zinn

[glwhicks]

My associate Ian, will be in tomorrow to provide the requested crashdump. In the meantime, here is the requested XML. In addition I'm providing the QCTools report generated by Memnon. Perhaps this might provide some insight:
https://slashtmp.iu.edu/files/download?FILE=glwhicks%2F46627HHrzl0
pw= MDPIXMLfile

https://slashtmp.iu.edu/files/download?FILE=glwhicks%2F15154X03p67
pw= MDPIQCToolsreport

[glwhicks]

To be clear, the provided XML and QCTools report are from a file that crashed the program

[dericed]

Does

I've never been able to get the audio graph to populate with a ffv1 file(ever!)

mean

I've never been able to get the audio graph to populate with a ffv1 file that has a neighboring qctools.xml.gz file(ever!)

?
If so then your xml.gz just wasn't created with any audio data.

[ElderOrb]

Just tried 32bit build under debugger - now I'm 100% sure this is out of memory. First qctools allocated 564029759 bytes for a buffer to extract xml.gz file, and then it tried to create std::string from buffer (which means allocation of at least 564029759 one more time) - and this time allocation failed.

@dericed & @JeromeMartinez what is the reason for not producing 64bit installers for windows?

[glwhicks]

Yes, Dave, correct. Never with a neighboring xml.gz file.
@ElderOrb, I'm not a code type person, might you be able to translate what you just said. I think I understand, but I'm not sure. Thanks!

[ElderOrb]

@glwhicks just try x64 version from here - https://mediaarea.net/download/snapshots/binary/qctools/20161204/ - should fix the issue

[glwhicks]

Okay! Thanks so much for all the great input!

[ElderOrb]

Welcome! but please keep in mind the link provided is not released version, but development snapshot.

[JeromeMartinez]

what is the reason for not producing 64bit installers for windows?

There is still some 32-bit Windows there (Microsoft did not "kill" 32-bit as Apple did for macOS, and there is unfortunately a 32-bit version of Windows 10), so I provide the default installer in 32-bit in order to be compatible with all versions of Windows. Providing several .exe is sometimes a source of confusion for end user who does not know what is 32 and 64-bit, so this is a policy to provide the 64-bit version only in an archive.
And this was not problematic up to now.
I could add a 64-bit installer beside the 32-bit one (remind that we have users who does not know what is the kind of OS version they have, so offering 2 version on the download page may be confusing), and/or a 32/64-bit installer but it would double the size of the .exe.
What would be your preference?

Edit: discussion moved to MediaArea/MediaArea-Utils#96

[iwsundstrom]

Unfortunately, I just ran the x64 version of QCTools and it crashed while trying to open the test file with it's xml.gz. Is there a debug version of x64 QCTools that I can use to send another crash report?

[ElderOrb]

https://www.google.com/url?q=https%3A%2F%2Fmediaarea.net%2Ftemp%2FQCTools_0.7.3.20161207_long_xml_load_error_223_Windows_x64_WithDebugInfo.zip&sa=D&sntz=1&usg=AFQjCNELQJ5CrD8JGu5mGvh99Cs7eD4msA

[iwsundstrom]

This version is giving me an error when I try to open it:

Any thoughts?

[iwsundstrom]

In addition, we just tested moving the xml.gz file out of the folder and opening our large test file. It reached completion and generated all the graphs without any problems. We then decided to test "Export->To .qctools.xml.gz" to create a new xml.gz file. Our plan was to close QCTools and open the test file with the freshly generated xml. However, QCTools crashed when we tried to do the export. Not sure if this is helpful, but thought we should pass it along.

[JeromeMartinez]

This version is giving me an error when I try to open it:
Any thoughts?

Due to a problem when we applied our patches for release to this branch.
New file: https://mediaarea.net/temp/QCTools_0.7.3.20161207_long_xml_load_error_223_fixed_Windows_x64_WithDebugInfo.zip

[iwsundstrom]

Great, thanks. Here's the crash dump produced with that version:
Link: https://slashtmp.iu.edu/files/download?FILE=isundstr%2F23516BNOIgr
pw: MDPICrashDump5

[ElderOrb]

Just checked version @JeromeMartinez provided - and managed to open MDPI_40000001519547_01_pres.mkv.qctools.xml.gz with no crash on Windows 10.

@iwsundstrom Did you use the same xml.gz file @glwhicks posted ? If different - could you please provide that file?

Also, just to clarify, was it crash on export or on import?

[JeromeMartinez]

With the build at #218 (comment), I have sometimes a "Out of memory! Please try 64bit build." message despite the fact I run the 64-bit version, or a crash, depending of how loaded (RAM usage) is my machine.
I propose an alternative patch for fixing this issue.

[iwsundstrom]

@ElderOrb Same file with xml.gz, and the crash is from an import with the x64 debug version provided by Jerome. The "export" story was just an additional note that I thought might be helpful.

[ElderOrb]

@iwsundstrom How much memory do you have on this machine? While switching to 64bit could help (just because it allows to use more than 4Gb), it will not help if you don't have enough memory or memory is heavily fragmented. QCTools definitely requires some optimizations and @JeromeMartinez already started optimizing xml parsing. So maybe makes sense to check his version if he can provide a link

[iwsundstrom]

@ElderOrb It has 16GB of RAM. I'm excited to test the optimized version as it does sound like XML parsing is problem.

[ElderOrb]

How much free memory do you have before opening xml.gz and after getting crash? Besides the lack of memory it might also be related to memory fragmentation, which is different story. Also, you have video file, correct? Which mean as the result of opening xml.gz thumbnails being generated and they also can consume a lot. Could you please make simple experiment and move/rename video file and then open xml.gz last 64bit debug version? This should remove influence of thumbnails and possibly resolve the crash

[iwsundstrom]

In regards to how much memory is used during a crash: Before I open a file I am using about 3.4 GB. During opening the memory builds up to about 9.8 GB used max, wavering up and down between there and lower. This is while opening the video file with the XML.gz beside it.

As for the test of just opening the XML.gz (without the video or thumbnails), that worked. The file successfully opened and populated the graphs, although QCTools was "Not Responding" for a short while.

I'm wondering if including some sort of loading or progress bar may be a good feature in the future, beyond resolving the crashes. It is not very user friendly to open large files and not be given feedback on loading progress.

[JeromeMartinez]

I'm wondering if including some sort of loading or progress bar may be a good feature in the future, beyond resolving the crashes. It is not very user friendly to open large files and not be given feedback on loading progress.

This is already the case when there is no sidecar .gz file (graph is populated in another thread), it could be implemented also for loading the .gz, the proposed patch is in this direction (there is some "hooks" for being able to display some info to the user), but having the progress bar has IMHO some impact in the workflow, it is more development time :(.

[ElderOrb]

We can leave importing in the UI thread and add progress bar (QApplication::processEvents trick). And I absolutely agree, during importing huge files progress bar is 'must have' thing

[JeromeMartinez]

New snapshot:
https://mediaarea.net/temp/QCTools_0.7.3.20161208_UncompressByChunks_Windows_i386_WithDebugInfo.zip

[JeromeMartinez]

We can leave importing in the UI thread and add progress bar (QApplication::processEvents trick).

I guess it is a good first step.
I was more thinking to have the .gz parsing in a separate thread, in order to let the user drag n drop more files, navigate in the software... As he does when a file is processed. 2nd step.

[iwsundstrom]

Sad to report that the new snapshot still crashes. Here's a crash dump:
Link: https://slashtmp.iu.edu/files/download?FILE=isundstr%2F51958E89DwA
Pw: MDPICrashDump6

[ElderOrb]

Based on what I see in the dump, this time 'access violation' happened inside 'ModifyOutput' function, which is used during video parsing, so this is not lack of memory but something different. Unfortunately I don't have that video (and don't even have such a big video right now), @dericed any help on generating such a long video with the same characteristics?

Also I noticed you still have application verifier enabled, could you please disable it (in very rare cases it might produce false positives) and see if application still crashes? Also just to exclude lack of memory (although as I said, it is highly unlikely this issue is related to allocations), would be interesting to see how x64 version will behave. But for this we need ask @JeromeMartinez to produce 64bit build from his branch

AVRF
Tid [0xdc8]
Frame [0x00]: QCTools!FFmpeg_Glue::ModifyOutput
Failure Bucketing

INVALID_POINTER_READ
Tid [0xdc8]
Frame [0x00]: QCTools!FFmpeg_Glue::ModifyOutput

BUGCHECK_STR: INVALID_POINTER_READ_AVRF

DEFAULT_BUCKET_ID: INVALID_POINTER_READ_AVRF

STACK_TEXT:
0027cbd8 01275696 QCTools!FFmpeg_Glue::ModifyOutput+0x66
0027cbf4 012755c7 QCTools!FFmpeg_Glue::AddOutput+0x67
0027cc2c 01286fb9 QCTools!FileInformation::FileInformation+0xed9
0027cd58 01292c00 QCTools!MainWindow::addFile+0xa0
0027cdd8 01290176 QCTools!MainWindow::dropEvent+0xd6
0027ce0c 0158a844 QCTools!QWidget::event+0x584
0027ce5c 016104da QCTools!QMainWindow::event+0x31a
0027ce7c 016053af QCTools!QApplicationPrivate::notify_helper+0xef
0027ce94 01604470 QCTools!QApplication::notify+0x11c0
0027cfe0 0130c181 QCTools!QCoreApplication::notifyInternal2+0xb1
0027d028 01655ff8 QCTools!QWidgetWindow::handleDropEvent+0x158
0027d098 016554de QCTools!QWidgetWindow::event+0x21e
0027d0cc 0160539a QCTools!QApplicationPrivate::notify_helper+0xda
0027d0e8 01604808 QCTools!QApplication::notify+0x1558
0027d234 0130c181 QCTools!QCoreApplication::notifyInternal2+0xb1
0027d27c 01434560 QCTools!QGuiApplicationPrivate::processDrop+0x60
0027d2d0 014e8d7d QCTools!QWindowSystemInterface::handleDrop+0x2d
0027d2f4 01792b87 QCTools!QWindowsOleDropTarget::Drop+0x1f7
0027d344 76a02d89 ole32!CPrivDragDrop::PrivDragDrop+0xcc
0027d378 762e5a4a rpcrt4!Invoke+0x2a
0027d3b8 763605f1 rpcrt4!NdrStubCall2+0x2ea
0027d7bc 76a0e7e6 ole32!CStdStubBuffer_Invoke+0xb6
0027d804 76a0e876 ole32!SyncStubInvoke+0x3c
0027d84c 76a0edd0 ole32!StubInvoke+0xb9
0027d898 769289eb ole32!CCtxComChnl::ContextInvoke+0xfa
0027d974 769288e0 ole32!MTAInvoke+0x1a
0027d990 769294b2 ole32!STAInvoke+0x46
0027d9bc 76a0eccd ole32!AppInvoke+0xab
0027d9f0 76a0eb41 ole32!ComInvokeWithLockAndIPID+0x372
0027dad4 76a0f1fd ole32!ComInvoke+0xc5
0027dafc 7692930f ole32!ThreadDispatch+0x23
0027db10 769292ce ole32!ThreadWndProc+0x161
0027db54 75f362fa user32!InternalCallWinProc+0x23
0027db80 75f36d3a user32!UserCallWinProcCheckWow+0x109
0027dbf8 75f377c4 user32!DispatchMessageWorker+0x3b5
0027dc58 75f3788a user32!DispatchMessageW+0xf
0027dc68 01362a9f QCTools!QEventDispatcherWin32::processEvents+0x40f
0027fa1c 02011e54 QCTools!QWindowsGuiEventDispatcher::processEvents+0x14
0027fa2c 01364349 QCTools!QEventLoop::exec+0x119
0027fa7c 0130b35d QCTools!QCoreApplication::exec+0x14d
0027fad4 0128e9d5 QCTools!main+0x165
0027fb78 02018174 QCTools!WinMain+0xe4
0027fbac 01f7c486 QCTools!__scrt_common_main_seh+0xf6
7efde008 ffffffff unknown!fillpattern+0x0
7efde00c 01180000 QCTools!_wpgmptr+0x0
7efde010 770c0200 ntdll!PebLdr+0x0
7efde014 0060f738 unknown!unknown+0x0

STACK_COMMAND: .ecxr ; kb ; dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; dps 27cbd8 ; kb

THREAD_SHA1_HASH_MOD_FUNC: 149eb2a0da52c8b38c064648615db142b8fd336c

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: b58a2edb0e3a82915bf0f8a0aee65193bc7c7531

THREAD_SHA1_HASH_MOD: 52ccbee68d27742fc5b25097be25e66065a90a48

FAULT_INSTR_CODE: 13c83

FAULTING_SOURCE_LINE: c:\programmation\build_7220\qctools_allinclusive\qctools\source\core\ffmpeg_glue.cpp

FAULTING_SOURCE_FILE: c:\programmation\build_7220\qctools_allinclusive\qctools\source\core\ffmpeg_glue.cpp

[iwsundstrom]

I disabled Application Verifier and was able to open the test file very quickly. I retried it multiple times (closing QCTools and opening it again) and it worked every time. I also tried using the snapshot to open other long videos that haven't worked with previous versions and was successful there to. It appears the issue has been fixed and that Application Verifier caused the previous crash! Thanks for working with us on this issue. We really appreciate it!

[dericed]

Closing for now as this seems resolved. Re-open if needed.