Ziggy

Wow, thanks for the quick response compyx! I've done several tests and it now works great with respect to the load/save dialogs. Great work! For quickload/quicksave, I think I agree with you. They are "throwaway" files which probably shouldn't be mixed with the snapshots saved via save dialog. quicksave files are definitely loaded/saved in the user profile dir on Windows...I tested that as well just now. I'm very happy with your fix! I think we can close this ticket now if you agree!

Also want to add that I'm using VICE 3.10.

Step 2 above should read: 2) Run "x64sc -eventsnapshotdir VICE_Snapshots" Step 7 above should read: 7) Load and save snapshot file dialog shows contents of current working dir instead of "VICE_Snapshots"

Load and Save Snapshot File Dialog Default Directory

I have run several tests with the newest official VICE 3.10 release and x64sc no longer crashes with the problem reported by this ticket. This ticket can be closed.

Hmm, I just tried the latest version of VICE (GTK3VICE-3.9-win64-r45709) released last week and it now works fine. I ran x64sc 40+ times and it never crashed! I just tried the official version 3.9 (GTK3VICE-3.9-win64) released back in December 2024 and it crashes every 5 to 10 runs. I've been trying VICE versions released at https://github.com/VICE-Team/svn-mirror/releases every once in a while this year and no luck...the x64sc crashes continued to occur. Last time I tried it was ~2 months ago maybe....

I've been trying newer versions of VICE and have the same intermittent crash as described above. The latest version I just tried (GTK3VICE-3.8-win64-r45265) will occasionally log 2 additional lines after the "Unit 8: RESET" log before crashing that I didn't see before. For example, on one run where it crashed, I saw the following after "Unit 8: RESET": Warning - Sync is 1149.860 ms behind VSync: Sync reset These 2 logs don't appear all of the time. Most of the time, I just see "Unit 8: RESET" and...

Researched a little more. As you said, this is a "heap corruption" issue. Several discussions I found from google searches indicate this is a memory corruption issue in the application (x64sc in this case) that just show up later in ntdll.dll (or something similar). The source of the problem is somewhere else in the application. A few years ago, I was a Software Engineer working on several large programs for Linux. We had to troubleshoot problems like this all the time. Now, on Linux we had access...