It's just the QT5Core.dll that is of interest.  The other hangs were likely due to network or simply my impatience.  I manually closed the program a few times when the round and round it goes was going round and round 8-).

Thanks for the details. I'll try to reproduce this.

From the log files / error reporting file I cannot fully see the cause. The .wer file contains multiple events for the python process. Some are BEX64 related to Qt5Core.dll. Those indicate a buffer overflow, which indicates some issue with Qt5 and would cause an immediate closing of the application.

But there are also multiple AppHangXProcB1, which usually indicates the UI being unresponsive. But in these cases there should be an actual message to the user with a choice to close the application or keep it running. Did this happen?

A semi-reliable way to reproduce this is as follows:

Open picard with the file browser pane active.  Drag some directories over to unclustered, then use the "cluster" button to cluster the files.  Now scan one of the clusters that seems to be a single disc.  If the scan matches a multi disc release, then all of the tracks' metadata are downloaded to the results pane.  When the release is expanded in the results pane, you'll see that only a few tracks have associated local files.  Now drag the release disc (top level) back to the clustered area of the middle pane.  This has resulted in a crash 2 of 2 times this morning.

Similarly, dragging the release back to the unclustered area of the middle pane and clicking the cluster button results in the same crash.  Always in QT5Core.dll at the previously logged address..  This has resulted in a crash an additional 2 of 2 times this morning.

I'm working with Kurt Sanderling's Berlin Philharmonic set of Shotakovich Symphonies.  Sometimes a particular cluster will match with a single disc release, and those work fine.  There are a couple of of these recordings that appeared on the release "Great Russian Recordings", which is a compilation of other releases.  In this case about 80+ tracks get downloaded, with only a few tracks matched to the files I'm scanning.  Dragging the entire release back to the unscanned pane results in the crash via one of the two above routes.

Okay, Picard has crashed several more times over the weekend.  It always has the same error and fault syndrome as has been previously attached.

Ive had at least two crashes while trying to move files back to the clustered pane from the looked up disc matches.  Both time there were tracks in the looked up window that did not have any file from the set I was working on.  In other words, Picard had matched the wrong release(es).  I was attempting to move the tracks out of the incorrect disks to try a browser lookup, but I didn't get that far, as Picard crashed in the QT5 module while the operation was pending.

I've attached the last several lines from the console log when Picard is run with --debug from command prompt.

Here is the application log:

Faulting application name: picard.exe, version: 2.8.0.170, time stamp: 0x61062592
Faulting module name: Qt5Core.dll, version: 5.15.2.0, time stamp: 0x5fa4dd3b
Exception code: 0xc0000409
Fault offset: 0x00000000000204e8
Faulting process id: 0x4068
Faulting application start time: 0x01d82e79e1604954
Faulting application path: C:\Program Files\MusicBrainz Picard\picard.exe
Faulting module path: C:\Program Files\MusicBrainz Picard\Qt5Core.dll
Report Id: e2cc3fc5-f27c-46fb-9ce8-d776c846e513
Faulting package full name: 
Faulting package-relative application ID: 

Fault bucket 1438069893887726854, type 5
Event Name: BEX64
Response: Not available
Cab Id: 0

Problem signature:
P1: picard.exe
P2: 2.8.0.170
P3: 61062592
P4: Qt5Core.dll
P5: 5.15.2.0
P6: 5fa4dd3b
P7: 00000000000204e8
P8: c0000409
P9: 0000000000000007
P10: 

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERDE2A.tmp.dmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERE148.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERE188.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERE195.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERE1C5.tmp.txt

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_picard.exe_58759995ea56a3494737f3911b49451adfe2acc5_b937d617_42b6b5b8-6da6-4861-bd88-5dab7f8cfa03

Analysis symbol: 
Rechecking for solution: 0
Report Id: e2cc3fc5-f27c-46fb-9ce8-d776c846e513
Report Status: 268435456
Hashed bucket: a9b264ae5f613b9263f50cf3035c9506
Cab Guid: 0

I've also attached the Report.wer.

I will try your suggestion to see if I can get debug info next time it happens.  I would not call it reproducible at will.  I had a third crash after running only several short discs, scanning them one at a time.  After a couple of hours of loading and saving and then removing the finished set, I scanned something with maybe 15 tracks, and as it seemed to be loading the disc info, the window closed without a peep.

Where will I find the debug file after the crash? (my luck is it won't crash with the debug enabled 8-()

Is the crash always reproducible? Could you run picard.exe from a Windows command prompt (ideally with the "--debug" parameter) and trigger the crash? That should yield some error output hopefully revealing the crash cause.