Decryption errors during the regeneration of a master key are highly unlikely. I've never seen one of these occurring naturally so far (we caused these errors manually for testing), so a discussion on their topic has a slim chance of being useful in practice. However, I also know this topic isn't covered anywhere else in the detail I'll cover it here, and while writing an answer to a question about it, I realized I was actually writing an entire topic, not just an answer. So I've decided to write my answer as a new post that can serve as reference in case anyone will ever need this information or is just curious about the details.
I'll discuss each master key separately.
Service Master Key
The entitites encrypted by the SMK are credential secrets, linked server login passwords, and DbMKs. DbMKs always have an additional encryption by a password, so, unless that password is forgotten, the key cannot be lost - even if the SMK encryption is corrupted. For the other two entities, if the SMK is changed and errors occur while attempting to decrypt them with the current key, then if FORCE is specified, the errors will be ignored and a new key will be regenerated anyway; this new key will naturally not be able to access the entities for which errors were encountered earlier, so they are likely lost - this is the reason why the error messages mention the possibility of data loss.
The FORCE option is an option for unblocking the regeneration or reload of the SMK and for ignoring any decryption errors that occur during the process. Without FORCE, decryption errors will abort the LOAD or ALTER REGENERATE operations. With FORCE, decryption errors are ignored and the processing of the entities for which the error was hit is skipped (no attempt will be made to reencrypt them with the new key because they can't be decrypted using the current key). FORCE is a last-resort option. Do not use it for your initial attempts to regenerate or load a master key!!! Don't panic - try to identify the cause of the decryption errors.
There are three possible errors that can occur when decrypting an entity with the SMK:
(1) the entity may be corrupted, so it cannot be decrypted by any key
(2) the SMK may be corrupted, so it cannot decrypt the entity
(3) the SMK may not be the correct key
If you suspect (1), the corrective action should be to fix the entity. For a credential secret or linked server login password, try resetting the information. For a DbMK, reload the DbMK from a backup. Barring other errors, this should fix the issue, so you can perform the operation without resorting to FORCE 🙂
If (2) is the case, which you could verify by attempting to encrypt with the SMK, for example, by generating a DbMK in a new test database (a failure should occur while encrypting the key if the SMK is corrupted), then the only solution is to restore the SMK from a backup. For this scenario, you need to use the FORCE parameter, because the current key cannot decrypt anything, so you cannot proceed otherwise.
It might not be immediately obvious how you could have (3), but this can be reached if while attempting to resolve (2), you load the wrong SMK backup. In this case, the key would be valid (i.e., not corrupted), but it would not match any of the encryptions. The solution for this scenario is again to load the proper backup and the FORCE option needs to be used here as well.
Database Master Key
The DbMK encrypts certificate and asymmetric key private keys. These do not have other encryptions, so if there are issues with their DbMK encryption, they are unusable.
The same three classes of errors can occur for the DbMK as for the SMK, and the way to deal with these errors is similar. For (1), the private key should be restored from a backup. For the asymmetric keys, if the key was generated in SQL Server, the only solution is to restore the entire database from a backup. For (2), one quick way to verify whether the DbMK is valid or not is to create a new test certificate (a failure should occur while encrypting the private key if the DbMK is corrupted). (3) is the same as for SMK.
One important thing to note from this discussion is the importance of backups. The solutions rely on having backups available that allow the administrator to restore the keys to their original state. Without backups, corruption will lead to data loss.
As a final advice, you should create a backup of the entire system before attempting to fix the issues, to ensure that you can always revert your actions.