In spite of using source control, sometimes it’s still possible to lose work due to the quirks of computers. At least you can mitigate this and only suffer losing a few hours of work, but still, when those few hours were a stroke of genius, the likes of which cannot be reproduced, you can’t help but shed a tear when all is lost. But fear not, here are 4 techniques that you can try to recover your code with before crying.
Lately I’ve used VirtualBox to run Windows 8.1 on my Mac Book Air under Mavericks. My Parallels license expired and I wanted to check out the alternatives. So far it’s been a pleasure to use but recently I’ve experienced it falling over, taking OSX down with it. I’ve probably seen the Grey Screen of Death twice over the last 6 years of using a Mac but have seen it twice in the last week.
It’s generally not a problem, just a minor inconvenience, until last night. Just as I’m about to wrap up for the day after making some great progress, everything comes crashing down. Once everything is back up and running, I couldn’t open one of my .cs files. Visual Studio would launch Notepad.exe which would display a seemingly empty file, although I could still make text selections:
However Explorer reported the file as being 30Kb…
This gave me hope, the data is still there! It’s probably just a case of a dodgy character somewhere in the file as a result of the crash. What does Notepad++ say?
Ok this is looking really bad. Back to Visual Studio, right-click the file in Solution Explorer -> Open With… -> Binary Editor.
Oh dear. This doesn’t look good. Apparently it’s a common problem and most likely due the crash occurring whilst that file was being written to on the disk, although in the 10 years that I’ve been working with Visual Studio this is the first time I’ve experienced it. There’s not much one can do to guard against this, other than diagnosing and fixing the cause for Virtualbox crashing, but that’s a whole new problem.
No point crying over spilt milk, let’s just get this fixed! First thing’s first, do not attempt to build your project again as we may need to use the output of the last build to recover your files!
Solution 1 – Decompile
If you search around the web for ‘Visual Studio corrupted file’, this is most likely the first solution you’ll find and is often touted as the only solution. Whilst it’s a perfectly practical solution and perhaps your only option, for me it’s a last resort for the following reasons:
- All comments and regions are removed.
- The code structure will have been lost.
- Depending on your build configuration, some optimisation may have taken place.
- Doesn’t really help if the code has been obfuscated.
I’m sure you’ll agree it’s better than nothing. If you don’t have any assemblies or you want to try to restore the file to its original awesomeness, continue on.
Solution 2 – AutoRecovery
If you have AutoRecovery enabled, you might be lucky enough to find a backup of the file. Chances are that Visual Studio would’ve prompted you to restore the corrupted file when launching it after the crash. Anyway it’s still worth checking the backup folder for your project, in:
%USERPROFILE%DocumentsVisual Studio [Version]Backup Files[Solution Name]
No dice for me, this directory was empty for me, on to the next solution.
Solution 3 – CHKDSK
Depending on the particulars of the corruption, trusty old chkdsk might help. It might be wise to attempt Solution 4 first to minimise the chances of any data being overwritten.
From an elevated command prompt execute:
You’ll receive a message that the drive is locked and the operation will need to be performed on the next restart. Just say ok and restart your machine. Depending on your setup, it could take a while for this to run so be patient.
This was the solution that worked for me and allowed me to recover the full content of my file! I used the free recovery software Recuva. Either use this or whatever you prefer, although instructions here are for Recuva.
Whilst Recuva is primarily for recovering deleted files and this isn’t technically a deleted file, we’re facing a similar challenge. The file is corrupt and pointing to the wrong clusters on the HDD, thus when we load our file it’s loading garbage instead of the correct content.
My first process was:
- Launched Recuva and used the Wizard to scan the folder containing my source files. After a few minutes it showed me an empty results window. Not looking good…
- Click on the ‘Options…’ button in the top right hand corner of the window.
- In the ‘Actions’ tab select the following:
- Hit the ‘Ok’ button.
At this point Recuva started updating the results view, but it still remained empty! Sad face. In a last-ditch effort I quit Recuva, navigated to the source directory in Explorer, right-click, ‘Scan for deleted files’.
Some more dialogs popped up, scanning the drive again until boom, a results view that displayed the contents of the folder, including all the sub-directories. This looks good!
I scrolled down to the file in question and read across the row: ‘Not deleted, Not overwritten’ etc. On the right of the screen there’s a tabbed preview pane. There was no preview available, the ‘Info’ tab looked normal but the ‘Header’ tab was where the magic was!
Right click the file in the results pane, ‘Recover Highlighted…’, save to desktop and bingo, fully recovered file. Thanks Recuva!
If you’re ever unlucky to encounter this issue, probably just as you’re about to pack up to go home or preparing for a big tech demo at an investor pitch, one of these solutions will get you unstuck.
If you have any other tips, share them in the comments and I’ll add them to the post.
Edit: Reader ‘bizh’ provided an additional step to Solution 4 if it doesn’t work out fully. I haven’t tested this so proceed at your own risk:
If Recuva is empty, you can delete the corrupted file and then run Recuva. In that case Recuva will definitely find the file and recover the clean version of it