Scores saved in unexpected location if saved after MuseScore crashes and restores session

• Sep 30, 2015 - 09:30
Reported version
S3 - Major

I was working on a smaller, orchestral piece, making wonderful progress, when MuseScore crashed. I opened the app again, and was greeted with the "restore previous session" message, and I clicked yes, opening the score I was working on. Everything was fine. I did notice that the title of the score I was working on was not the title I had given it, rather, what seemed like a Windows file location. I worked on the score for several more hours, before accidentally hitting Control+W closing the score. Luckily, I had saved. The thing is, I can not find the score I had been working on anywhere. I found an older version that was not the score I was working on, and 8-9 hours of work were seemingly lost. I really don't know what to do, and very much hope that there is something I can do. The piece I was working on was really important to me, and all my work seems to have just, vanished. Any help would be EXTREMELY appreciated.


Sorry for posting in this in the wrong place. I'll make sure not to do this again.

I actually managed to find the piece in the Windows roaming data after looking up all the .mscz files like you suggested. I was really worried I had lost my work.

Thank you SO much!

Title Unable to Locate Score After MuseScore Crashes and Restores Session Easier method to locate score after MuseScore crashes and restores session
Status (old) closed active

I think asking for a better way to handle this is very much a legitimate feature request. Why can't MuseScore simply remember the original location with the original file name?

I'm qualifying this as "Major" because many users will never find those mis-saved files without help from here; I've also designated it a "bug" rather than a feature request, because in behaving like this, the program is ignoring a specific default parameter set in it's not doing what it is supposed to.

For additional discussion on this problem, see and

Note that I'm running 2.0.1 but the same thing appears to happen in all 2.0 versions.

Title Easier method to locate score after MuseScore crashes and restores session Scores lost if saved after MuseScore crashes and restores session

I feel for you and your trials and travails. Something's got to be done. As a very weak interim measure, we've got a new Handbook page about this (, but I look forward to the day that that page can be deleted.

This appears to be becoming a more and more frequent occurrance, and as Zack says, something's got to be done. Zack and I have collaborated on a page for the Handbook to try to help users find their files, but what's really needed is a patch consistent with all 2.0.x versions that would allow users to update their stable versions.

No one has yet taken this on (I would if I were competent, but I'm not), but I am wondering if anyone who IS competent--Jojo, Marc, or Nicolas, perhaps?--could at least take a look at the code and evaluate how complex the issue is. That would make a start towards some sort of solution.

I just had the exact same problem, I'm not sure how to fix it. I saved my new score that I was working on every few measures (because I'm paranoid about losing them), but I closed and reopened musescore and opened the file. It had somehow made another file, in a different key, with different instruments. The file that I had been working on only had a couple measures of work from the very, very beginning. Can you help?

You don't mention a crash in your description, so I'm not sure this is the same at all. Anyhow, to get help using MuseScore, it is better to ask on the Support forum, where many more people will see and be able to offer suggestions. When you do so, be sure to say what version of MuseScore and what OS, and attach the score you are having trouble with. Most likely, you simply opened a different file than the one you saved, and the one you saved is sitting there waiting for you in another folder.

Title Scores lost if saved after MuseScore crashes and restores session Scores saved in unexpected location if saved after MuseScore crashes and restores session

I agree the original issue should be addressed, though - there is no reason we should default to saving in such unexpected places when restoring after a crash.

I'm looking at this, and want to verify a couple of things.

First, I am wondering: is this Windows only? Do users on macOS or Linux see the same thing?

Second, I find that if the score is not "dirty" (has not been modified since last save) and/or there is no auto-save version, there is no problem. That is, if a crash occurs while a score is not dirty and/or has no auto-save yet, then on restore, the file name and location is normal. The problem only occurs when restoring from the auto-save.

Finally, on Windows 10, for scores that were dirty and have auto-save files, the file name comes up a _Users_Marc_Documents_MuseScore2_Scores_test.mscz (or whatever), and if I choose to save, the file actually goes to:

C:\Users\marc\AppData\Local\VirtualStore\Program Files (x86)\MuseScore 2\bin

I believe this is because MuseScore is *trying* to save to:

C:\Program Files (x86)\MuseScore2\bin

but that folder is write protected, so Windows uses the VirtualStore instead. I assume we are trying to write to that folder because that is the folder we are running in, at least when starting from the program icon using default settings. Probably it would be a different folder if I started MuseScore differently.

If I'm not mistaken, this can be traced to the following line:…

which is the line that replaces "/" with "_" in filenames. I get why sometimes this might be a good idea. I suspect it is not a good idea *here*, though. Simply skipping that line fixes the problem. According to git blame, this was done to fix #22904: Anything after dot in part name doesn't appear. My sense is we probably want to keep this function as is for general use, but for this specific case - setting the file name for scores restored from a session file - we should skip the "sanitizing".

If I'm right about this, then the problem first occurred back in October 2014. And as far as I can tell, the same problem would exist on macOS and Linux.

Ah, sorry, our posts crossed. Thanks for the confirmation. A bit embarrassed it's taken this long for me to investigate when the fix turned out to be so simple. Probably could have saved a lot of people some major frustration over the past couple of years. But like I said, better late than never.

EDIT: to be clear, my "better late than never" comment was me kicking myself, not criticizing anyone else. I just realized the post crossing might have made it look like I was addressing Isaac. Definitely not so!