CRC is common, cryptographic hash is frequent but less common. Also the individual components being loaded should validate their data, and when they detect an out-of-range value some proper response should be taken.
For example, I spent the last two years working on The Sims where DLC could be installed, removed, upgraded, or downgraded between saves. If the file was detected as corrupt we would notify the user and not load the file. When an object is loaded but has out-of-bounds values we don't load the customized data and reset to defaults instead. When something in use was uninstalled between play sessions, such as furniture, we would replace it will a default fallback and provide notice to the user that objects were being replaced. Sometimes when there was no good option for replacement (because nothing like it exists in base game) we would go with party balloons for a replacement object.
Most consoles and handhelds specify minimum standards for detecting and dealing with the files, including guidelines for recovery or mandatory deletion of invalid files.
As for solutions, one I have seen used occasionally is a two-of-three storage system. It is robust and occasionally used for cartridge-based memory, but few studios used it because it slightly raised the cost of goods. Basically you have three slots and two versions. You start with an old version (denoted by lowercase) and replace with a new version (denoted by uppercase) writing out [Abc] then [ABc] and then [ABC]. If there is a catastrophic error, such as a read error or a cartridge pulled when writing, you always have at least one complete file that is valid. During the first write you can recover the original save. During the second write you can recover either the newer or older save, and during the final write you can recover either of the new saves. You can then use one slot for a "quicksave" system if you are fine with less redundancy.
Edited by frob, 10 March 2014 - 04:00 PM.