View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001645||OpenMPT||General||public||2022-12-18 08:09||2023-04-17 10:50|
|Reporter||gremghost||Assigned To||Saga Musix|
|Product Version||OpenMPT 1.30.08.00 / libopenmpt 0.6.6 (upgrade first)|
|Summary||0001645: OpenMPT crashes when starting up the program|
Every time I try to open the program, it hangs for a second before getting labeled as "not responding" and then eventually crashing. I have tried looking for crash logs in %TEMP%, but it doesn't produce any. I've also tried downgrading and that still crashes.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||Yes and no|
|Tested code revision (in case you know it)|
Can you try to create a crash dump with ProcDump? Instructions are here: https://wiki.openmpt.org/Manual:_Frequently_Asked_Questions#OpenMPT_crashed_but_did_not_create_a_memory_dump
Absolutely. Here's the file from ProcDump.
The file appears to be missing. Note that full memory dumps are too big to attach here; can you provide a link to an external file host (Dropbox etc. is okay)?
Sorry about that! Here's the link to the file: https://www.dropbox.com/s/o1k0rlcmmws22pq/OpenMPT.exe_221219_011636.dmp?dl=0
It seems like a crash in Windows' zip-file component when trying to read the file "piescese.zip" as part of filling the instrument library. Obviously Windows' zip-file component should not be crashing but that's beyond our control. In fact, the crash itself is not in the zip file code but rather when attempting to open the file, from my understanding:
I'm not sure why the zip file is trying to be read (we are only interested in the file attributes, so I'm not sure why it tries to read the contents), or why the read goes through AcLayers.dll (which from my understanding is a library used for application compatbility with older applications that require certain Windows quirks to be emulated). Are you enforcing any sort of compatibility setting (e.g. emulating old Windows version) on OpenMPT?
I found a zip file with that name online (a font file) but it didn't crash OpenMPT here, even though I'm also on Windows 10 (latest update).
In fact there is no exception code associated with this memory dump, which makes it even more mysterious why the dump was created at all.
There's now an experimental workaround as of r18370 which avoids sending zip files to the link resolver. You can obtain an updated test build within a few hours from https://builds.openmpt.org/builds/
Can you please confirm that this problem no longer occurs in OpenMPT 1.30.09.00?
Due to lack of feedback I'll assume that the workaround in 1.30.09.00 fixed the problem.
|2022-12-18 08:09||gremghost||New Issue|
|2022-12-18 11:05||Saga Musix||Note Added: 0005428|
|2022-12-19 06:20||gremghost||Note Added: 0005429|
|2022-12-19 13:38||Saga Musix||Note Added: 0005430|
|2022-12-20 03:05||gremghost||Note Added: 0005431|
|2022-12-20 09:40||Saga Musix||Note Added: 0005432|
|2022-12-20 19:56||Saga Musix||Note Added: 0005435|
|2023-01-01 22:59||Saga Musix||Note Added: 0005445|
|2023-01-01 22:59||Saga Musix||Assigned To||=> Saga Musix|
|2023-01-01 22:59||Saga Musix||Status||new => assigned|
|2023-01-01 22:59||Saga Musix||Status||assigned => feedback|
|2023-01-08 14:35||Saga Musix||Note Added: 0005453|
|2023-01-08 14:35||Saga Musix||Priority||urgent => normal|
|2023-01-26 22:33||Saga Musix||Note Added: 0005510|
|2023-02-10 20:51||Saga Musix||Status||feedback => resolved|
|2023-02-10 20:51||Saga Musix||Resolution||open => fixed|
|2023-02-10 20:51||Saga Musix||Note Added: 0005545|