Since yesterday, I've not been able to open MP3Tag - either on 3.08 or 3.08d (the latest dev build). The error log is empty, and I don't see any explicit error in the normal log as well.
After trying to open MP3Tag from the explorer context menu or through the start menu - nothing happens. A process is spawned with the name of Mp3tag.exe in the task manager too, but the memory used by it varies, so my assumption is it's running somewhere.
Any help would be much appreciated, especially as it was working fine till a day before. My Windows 10 version is the 21-09 update of Windows 10 20H2, 19042.1202.
EDIT - It opened, but around ~30 mins later, and then when I closed it and tried to open again it's still stuck in the task manager. I have no idea what's happening in the background.
as that did not generate any further helpful feedback from the OP's side, perhaps you can either try the suggested remedies or shed some more light on the circumstances.
I don't know what fixed this, but some things that I tried that might have fixed the issue -
Installing yet another update that popped up for Windows 10 - KB5005565
Restarting my PC
Deleting the MP3Tag folder for v3.08 (using Lockhunter), and installing v3.08d
Another thing I noted was that the folder I failed to open was around ~400 MB, and it had 28 files, not all of them FLAC files - it had cue/m3u/sfv/log files as well. So this also might be a performance-related issue. I keep my Windows Defender manually disabled, and I don't use any antivirus (I just run a bimonthly scan using Malwarebytes) so I'm pretty sure an anti-virus slowing MP3Tag down is not an issue.
But in any case, I think this thread can be closed. Thanks for the help @poster and @ohrenkino!
The problem goes away upon reboot and then spontaneously reappears after enough system uptime has passed. I'll try to get back to you when it happens again.
What has changed in comparison to the times it did not happen?
Which of all the suggested measures mentioned in this and the linked thread besides the process explorer have you applied so far?
The starting incident was that only the splashscreen showed, and then crashed. After that, it refused to start again, just sitting in the background, running like described by OP.
First thing I did was uninstall and grab the newest version in case it had been fixed there. Didn't help, same issue. Then I tried running as administrator, and running in Win7 compatibility mode.
I have not restarted or updated Windows, in case that will temporarily resolve this, as I'm looking for a diagnosis to help get this fixed.
This is usually where I would download the codebase, do a debug build and check to see what it's waiting for all this time. But I can't seem to find a link to the code anywhere, so I suppose this isn't open source?
Though now I think something happened like for OP in the first forum post you linked, where after returning to my computer a few hours later, it has opened. Whatever those threads were stuck waiting for has occurred after a while.
Closed and ran it again, and got this:
Retry pops up the same window again, and Switch To closes that pop-up and brings up the Windows start menu. If I now try to start mp3tag again, we're back to the original problem, but now the exe has graduated to being listed among the Apps in Task Manager, instead of among the Background Processes.
Before we go back and forth:
Save the data folder somewhere safe.
Uninstall MP3tag completely.
Check the registry and the file system for any remains (except the saved data folder) and delete them all.
Install MP3tag again and see if it runs - then close it.
If so, overwrite the new data folder with the saved data folder.
Start MP3tag again and see if it still runs.
I've analyzed the minidump (thanks for that!) and it hangs at SHGetFileInfo where I request the icon images for the enabled file types from the system.
This now can have plenty of explanations: I've re-read the documentation on this shell function again and it explicitly states in the remarks section to call this from a background thread, because it might otherwise block the UI.
I'm hesitant to re-implement the icon fetching code based on this guess, because it worked fine for hundreds of thousands of people over the years. From my understanding, the blocking also only occurs when the requested file might be not available or on a slow drive (e.g., a network share). This is not the case here, because I'm passing SHGFI_USEFILEATTRIBUTES which doesn't access the file system at all.
Another option would be that the system ran out of handles to be used to create the image list, or something completely different.
That would make absolutely perfect sense. For many many years my Windows laptop has had problems with thumbnails and file icons not loading, and I remember having to use something other than mp3tag there. Sometime early this year my desktop (Where this occurred) started having the same issue. And I don't think I have used mp3tag on here since before that started happening.
I think the remark authors are dead on the money. Hanging on anything requested via a Microsoft-thing is dangerous business. The remedy, as you probably have concluded too, is to not require those icons before starting, via having a timeout on requesting them and falling back to some default, and/or cashing them to your own files between runs to minimize interaction with Microsoft cruft.
Anyway, happy the minidump helped, and thanks for actually looking into this! Certainly satisfies my curiosity as to why this happens.
