one of our games see specific users crashing 100% when opening .pak files (error is “Corrupt pak index detected” on pakchunk8 or pakchunk9).
At first we suspected the Oodle SDK issue with specific intel CPU but even after patching our game with the latest SDK 2.9.14 those players are still unable to launch the game.
Our game is built with several .pak compressed and encrypted using native Crypto plugin. We’re using a classic EncryptionKey + 16 SecondaryEncryptionKeys (1 per .pak) and the following encryption settings :
bEncryptPakIniFiles=True
bEncryptPakIndex=True
bEncryptUAssetFiles=True
bEncryptAllAssetFiles=False
SigningPublicExponent=
SigningModulus=
SigningPrivateExponent=
bEnablePakSigning=False
One of the users sent me his log with LogPakFile to VeryVerbose:
Initializing PakPlatformFile
Reading toc: ../../../[REDACTED]/Content/Paks/global.utoc
Toc loaded : ../../../[REDACTED]/Content/Paks/global.utoc, Id=ffffffffffffffff, Order=0, EntryCount=1, SignatureHash=0000000000000000000000000000000000000000
Mounting container '../../../[REDACTED]/Content/Paks/global.utoc' in location slot 0
Initialized I/O dispatcher file backend. Mounted the global container: ../../../[REDACTED]/Content/Paks/global.utoc
Found Pak file ../../../[REDACTED]/Content/Paks/pakchunk9-Windows.pak attempting to mount.
Mounting pak file ../../../[REDACTED]/Content/Paks/pakchunk9-Windows.pak.
Corrupt pak PrimaryIndex detected!
Filename: ../../../[REDACTED]/Content/Paks/pakchunk9-Windows.pak
Encrypted: 1
Total Size: 3426
Index Offset: 2949
Index Size: 144
Stored Index Hash: DAB033405A0966FE52FECF7C80C80DFE49B05F89
Computed Index Hash: 85103F26F7B264BEA29CCA5FF7A3B544D75F8621
I’m not sure what could be done on my side to allow those users to play; any hint may be a great help.
Should i just set “bEncryptPakIndex=False” and pray it doesn’t crash later on ?
I went ahead and delivered a build with bEncryptPakIndex=False to one of our user, he’s now able to read 15 .pak but the last one now errors on decompression.
> LogCompression: Error: FCompression::UncompressMemory - Failed to uncompress memory (1520/5845) from address 00000218CD618010 using format Oodle, this may indicate the asset is corrupt!
So this may still be some issue related to Oodle compression.
The issue you are referring to is with the CPUs which are broken. The decompression failure is just one of the symptoms for the problem. The SDK 2.9.14 update is detecting the CPUs that are known to potentially be problematic and uses different code paths that do not use the known part of the CPU that break.
Based on recent findings, it appears that the following steps can be used by consumers to validate if their CPU must be replaced:
1. Check BIOS/microcode version — ensure the August 2024 microcode is applied
2. Run CPU stress tests OCCT to detect instability
3. In BIOS, switch to Intel Default Settings / disable any MCE overrides
4. If the CPU is already degraded, the only fix is replacement
Thanks a lot for the quick answer; hardware issue was the conclusion i ended to after trying ZLib compression and it ended up with a similar error on the same pak file.
> LogCompression: Warning: appUncompressMemoryZLIB failed: Error: Z_DATA_ERROR, input data was corrupted or incomplete! (incorrect header check)
I’ll give a last try building without compression for users having this issue to see if they can play by trading disk space for stability.
