Bug How to Fix CRC Mismatch

Without knowing your project setup and workflow it's difficult to advise something more concrete.

A workaround: There are options to disable CRC checking in the Content Packing & Loading schema of a given AddressableAssetGroup. You can set it to be completely disabled, or to only disable it when loading cached AssetBundles. That should at least give you a path forward if nothing else.

A couple of questions/thoughts:

• Are you building/re-building any of these bundles using different versions of Unity? This shouldn't be a problem anymore but there were issues in the past.
• Are you loading asset bundles that have been built using the project on a different machine? We've seen this type of issue arise in the past.
• If you're hosting remote bundles, make sure that you've uploaded all the newly built bundles, catalog.json and catalog.hash files that were generated for remote content. This is really only likely to cause your issue after doing a content update but it could be worth double checking.

You mention trying to clear the cache with no success. If you're not already, try using the

Code (CSharp):

1.  public static AsyncOperationHandle<bool> ClearDependencyCacheAsync(object key, bool autoReleaseHandle)

version of the method. Once it's finished check the bool result and make sure it isn't false, indicating the cache couldn't be cleared for some reason.

If you want to affect the AssetBundle cache directly, try

Code (CSharp):

1. Caching.ClearCache()

. It is the "nuclear" option. The method also returns a bool that indicates if the operation was successful. If it isn't successful it's possible that some of the bundles in that cache are loaded.

 

I'm glad you got it to work! I did ask one of our build engineers and they said upgrading to Win 11 could cause CRC mismatches depending on what type of assets you're using. Not saying that's what caused your issue, but just for anyone else that's in a similar situation.

1. I'm not sure if you mean the AssetBundles or catalog when you say "resulting file". Typically hash changes only come from changes in the assets. If changing an asset isn't an option, you might try going into the AddressableAssetSettings and turning on Unique Bundles IDs. Even with unchanged assets, the first build after turning this on should result in newly hashed AssetBundles. I don't believe it forces new hashes _every_ time.

2. So, there actually should be logic in place that forces as least one retry when a cached asset bundle can't be loaded. I just took a look at the code and it might be that there's a bug in that if your Retry Count is greater than 0 (which is very confusing, but it looks like the cached bundle only gets cleared if your Retry Count is 0. Otherwise the retries are attempted but the invalid bundle is still cached so it just keeps trying to load that).

That doesn't help you in the moment, however. You can try checking the `OperationException.Message` on the AsyncOperationHandle and parse it for "CRC Mismatch". Then, if that message is detected, you should be able to clear the cache and re-download.

If you're uploading a new remote catalog, make sure you're also uploading the corresponding .hash file alongside it. If the catalog changes, but that hash files doesn't, the new catalog won't get downloaded (which contains the crc data for the asset bundles). If you are uploading a new catalog, with it's hash file, and new AssetBundles, and the catalog hash isn't changing (ie the value in the .hash file is unchanged) but the AssetBundles are different, then this sounds like a bug in the build.