UE 5.8.x Resume Loop — Workaround v3.3: Stale ManifestHash (Possible Root Cause)
Final investigation update — October 30, 2026
Confirmed case: Unreal Engine 5.8.3 → 5.8.4
Platform: Windows 11
Result: The persistent Resume loop was resolved. Epic Games Launcher now displays Launch.
Important: This post describes a confirmed workaround for a specific installation state. The internal root cause has not been conclusively established and requires investigation by Epic. This should not be treated as a universal fix for every UE 5.8.x Resume loop.
1. Summary
After extensive investigation of a persistent Resume loop in Epic Games Launcher (EGL), I was finally able to narrow the issue down to one particular metadata field:
ManifestHash
Earlier troubleshooting, including the v2 workaround, focused on recovering the installation from incomplete or inconsistent update states.
However, the problem kept returning.
The successful v3.3 experiment took a different approach.
Instead of modifying EOSH registration, revision counters, pending manifests, or plugin metadata, I cleared exactly one stale ManifestHash value in the live EGL .item file.
Before:
"ManifestHash": "7824ea53198b0f36a0a291bb3ee11f563912056d"
After:
"ManifestHash": ""
Following this change, Epic Games Launcher correctly prepared the EOSH pending transaction, completed the update from UE 5.8.3 to UE 5.8.4, and displayed Launch instead of returning to Resume.
No Unreal Engine binaries, EOSH revisions, installed manifests, or plugin registrations were manually modified.
This is the central finding of the investigation.
2. The original problem
The affected installation was registered as:
5.8.3-58210709+++UE5+Release-5.8-Windows
The intended update was:
5.8.4-58902052+++UE5+Release-5.8-Windows
Epic Games Launcher repeatedly attempted the update but eventually returned to Resume.
The observed failing update sequence was approximately:
UE 5.8.3 installed
|
v
EGL selects UE 5.8.4 update
|
v
CommunityPortalPatcher / BPS
|
v
Patch activity completes
|
v
EOSH remains Installed 5.8.3
|
v
EOSH pending remains empty
|
v
EGL returns to Resume
An important detail is that the logs did show a manifest commit callback.
Therefore, I would not describe the problem simply as a missing callback.
The more significant observation was that the expected EOSH pending → installed transaction did not occur.
The patching process and the registered installation state were not progressing together as expected.
3. What changed between workaround v2 and v3.3?
The earlier v2 approach concentrated on the consequences of the unsuccessful update.
It involved examining and recovering inconsistent installation states and leftover update artifacts.
That was useful for understanding the behavior, but it did not permanently resolve the recurring Resume loop in my installation.
The v3.3 investigation instead focused on identifying what might be triggering the incorrect update path.
The key difference was the live .item field:
ManifestHash
In the affected installation, the field contained a non-empty value even though the installation had been returned to a stable UE 5.8.3 state.
A separate successfully updated installation provided a useful comparison.
This led to the hypothesis that the stale hash might influence how EGL selects or prepares the update transaction.
Rather than changing multiple metadata sources, I tested this hypothesis by changing only that field.
The result was successful.
4. Original installation metadata
The affected installation used the following Installation ID:
D1AC6C594CBE88D6B55411CFA033E4CE
The corresponding EGL metadata file was:
C:\ProgramData\Epic\EpicGamesLauncher\Data\Manifests\
D1AC6C594CBE88D6B55411CFA033E4CE.item
The related EOSH installation record was located under:
C:\ProgramData\Epic\EpicOnlineServicesShared\
InstallHelper\InstalledItems\
Verified state before the successful patch
| Metadata |
Value |
| EGL version |
UE 5.8.3 |
| Incomplete installation |
False |
| ManifestHash |
7824ea53198b0f36a0a291bb3ee11f563912056d |
| EOSH state |
Installed |
| EOSH current version |
UE 5.8.3 |
| EOSH pending version |
Empty |
| EGL item revision |
08DECBF173004248000000000000002E |
| EOSH revision |
08DECBF173004248000000000000002E |
| Global revision |
46 |
| Active pending files |
None |
| Active BPS directory |
None |
The original installed manifest SHA256 was:
65619BCDBC675EC4CE4C9D349B7CAAA7DA3F281A2085A2D0070533C0893BD06A
The expected target manifest SHA256 for UE 5.8.4 was:
4AEA3C5963D3C44B26EC4D8A9D62F492F5FDE13E5479D1D186CA946DBC1F692E
These fingerprints were used to distinguish the original stable installation from the intended target update.
5. The controlled one-field experiment
Before applying the patch, I verified that the installation was in a stable state.
The installed version and EOSH version agreed.
The .item and .egi revisions matched.
No active EOSH pending transaction, pending .item, pending manifest, or BPS operation remained.
The original metadata was backed up.
I then made the following change in the live EGL .item file:
- "ManifestHash": "7824ea53198b0f36a0a291bb3ee11f563912056d"
+ "ManifestHash": ""
The modification was byte-preserving apart from removing the 40-character hash value.
No other .item properties were modified.
SHA256 verification
Original .item:
86161597EB248A44F5D57C8B9FFA11EC0717562D1FBF2AFFB6DEB24773269F57
After the one-field patch:
86704755844536D28731F553CA93ADD779725D2E516E61D08CC2527427D693E4
The resulting file remained valid JSON.
Importantly, the following files and values were not manually modified:
- EOSH
.egi installation records
Revision.json
LauncherInstalled.dat
EoshRevision
- Installed manifests
- Unreal Engine binaries
- Plugin registrations
After this single change, I restarted EGL and initiated the update.
6. Successful EOSH transaction
This time, the launcher followed a different and successful sequence.
Before Update
EOSH current = 5.8.3
EOSH pending = empty
EOSH revision = ...002E
Global = 46
During Update
EOSH current = 5.8.3
EOSH pending = 5.8.4
EOSH revision = ...002F
Global = 47
The pending target manifest matched the expected UE 5.8.4 SHA256:
4AEA3C5963D3C44B26EC4D8A9D62F492F5FDE13E5479D1D186CA946DBC1F692E
After Update
EOSH state = Installed
EOSH current = 5.8.4
EOSH pending = empty
EOSH revision = ...0030
Global = 48
EGL UI = Launch
The completed installation also matched the expected target manifest SHA256.
The physical engine build reported:
CL 58902052
No active pending transaction or BPS artifacts remained.
The original Resume loop was resolved, and the existing plugin entries were preserved.
This confirmed that the one-field change was sufficient to unblock the update in my installation.
7. Possible root cause
Based on these observations, my current hypothesis is:
A stale, non-empty ManifestHash in the live EGL installation record may influence the update path selected by Epic Games Launcher, preventing the expected EOSH pending transaction from being prepared or completed.
The observed behavior supports the following possible sequence:
STALE ManifestHash
|
v
EGL selects update path
|
v
CommunityPortalPatcher / BPS
|
v
No corresponding EOSH pending transition
|
v
Resume loop
After clearing the field:
ManifestHash = ""
|
v
EGL Update
|
v
EOSH prepares pending 5.8.4
|
v
Patch / installation process
|
v
EOSH finalizes Installed 5.8.4
|
v
Launch
There is a strong experimental indication that this field was involved in triggering the failure.
However, I cannot confirm the internal EGL/EOSH decision logic.
I also cannot conclude that every non-empty ManifestHash is invalid or stale.
The exact root cause and appropriate permanent fix need to be established by Epic’s engineers.
8. Workaround v3.3 — final PowerShell script
After confirming the successful real-world update, I developed a simplified public workaround based directly on the one-field experiment.
Attachment:
UE58_ResumeFix_v3_3_Final.zip (4.6 KB)
Included script:
UE58_ResumeFix_v3_3_Final.ps1
SHA256 checksum (PowerShell script, not ZIP archive):
4CE95BACB6F807DF87C20E54FC8B3EE9B8F81AE5CC1C67C0686C79A192A0CF45
To verify the integrity of the extracted script, run:
Get-FileHash .\UE58_ResumeFix_v3_3_Final.ps1 -Algorithm SHA256
The resulting SHA256 hash should match the value above exactly.
If the checksum does not match, do not execute the script.
The script is provided as an unofficial community workaround. Please review its contents before running it.
The final version deliberately focuses on the original successful intervention rather than attempting to repair or manage every possible EGL/EOSH state.
Available modes
Audit
Performs read-only checks of the installed version, EOSH state, revisions, pending artifacts, ManifestHash, and installed manifest.
Apply
Creates backups and clears the specific stale ManifestHash, but only when the installation matches the confirmed fingerprint and passes the safety checks.
Verify
Confirms that the patched .item remains valid and that EOSH and installed-manifest metadata have not changed unexpectedly before starting the update.
Usage
Extract the ZIP and inspect the PowerShell script before executing it.
Open PowerShell in the directory containing the extracted .ps1 file.
Step 1 — Audit
.\UE58_ResumeFix_v3_3_Final.ps1 `
-Mode Audit `
-InstallRoot "G:\Epic_Games\UE_5.8"
Replace G:\Epic_Games\UE_5.8 with your actual installation path.
Only continue if the script reports:
READY_FOR_PATCH
If it reports one of the following, do not force the patch:
HEALTHY / NOT_APPLICABLE
UNTESTED_FINGERPRINT
UNSAFE_STATE
Step 2 — Apply
Completely close Epic Games Launcher and EpicWebHelper.
.\UE58_ResumeFix_v3_3_Final.ps1 `
-Mode Apply `
-InstallRoot "G:\Epic_Games\UE_5.8"
A successful operation should report:
ONE_FIELD_PATCH_APPLIED
The script also displays the backup directory.
Keep the backup.
Step 3 — Verify
Restart Epic Games Launcher, but do not click Update yet.
Run:
.\UE58_ResumeFix_v3_3_Final.ps1 `
-Mode Verify `
-InstallRoot "G:\Epic_Games\UE_5.8"
Only continue if the result is:
PATCH_ACCEPTED
You may then attempt the normal Update operation inside EGL.
If verification fails, stop and investigate the metadata state instead of repeatedly attempting modifications.
Important limitations
This workaround intentionally recognizes only the specific UE 5.8.3 state established during my investigation.
A different version, manifest fingerprint, or ManifestHash may cause the script to refuse the operation.
That is expected behavior.
The script does not attempt to clear arbitrary hashes, modify EOSH records, force revision changes, or manipulate active update transactions.
It also does not automatically restore metadata after a transaction has started.
9. Validation and negative testing
To validate the public workaround, I used an authentic snapshot of the original UE 5.8.3 metadata, preserved before the successful repair on October 29, 2026.
This included:
<InstallationID>.item.before
<InstallationID>.egi.before
Revision.json.before
LauncherInstalled.dat.before
state.json
The snapshot confirmed the original UE 5.8.3 version, the stale hash, matching EOSH revisions, and the empty pending state.
I then tested the actual Apply and Verify logic from the simplified final RC2 script in an isolated fixture.
Positive tests
| Test |
Result |
| PowerShell syntax |
PASS |
| Audit on healthy UE 5.8.4 installation |
HEALTHY / NOT_APPLICABLE |
| Prepare original UE 5.8.3 fixture |
FIXTURE_READY |
| Apply one-field patch |
ONE_FIELD_PATCH_APPLIED |
| Independent SHA256 comparison |
BYTE_IDENTICAL_PATCH_CONFIRMED |
| Verify patched metadata |
PATCH_ACCEPTED |
The isolated Apply operation generated exactly the same SHA256 as the original successful real-world experiment:
86704755844536D28731F553CA93ADD779725D2E516E61D08CC2527427D693E4
This establishes that the tested implementation reproduced the same byte-level .item modification.
Negative tests
I also tested three unsafe scenarios.
N1 — Active EOSH pending
APPLY_REFUSED
Result: PASS
The script refused to apply the patch.
The relevant .item and .egi files remained unchanged.
N2 — Revision mismatch
APPLY_REFUSED
Result: PASS
The script detected inconsistent revisions and refused the patch.
The relevant files remained unchanged.
N3 — EOSH changed after Apply
VERIFY_FAILED - DO NOT UPDATE
Result: PASS
After a successful isolated Apply, I deliberately modified the test EOSH revision.
Verify correctly rejected the changed installation state.
Overall test results
FINAL RC2 POSITIVE TESTS: PASS
N1 Active pending: PASS
N2 Revision mismatch: PASS
N3 EOSH changed: PASS
ALL NEGATIVE TESTS PASSED
Testing limitation: The isolated end-to-end test used authentic EGL/EOSH metadata, but the original physical UE 5.8.3 manifest SHA256 was simulated from its previously recorded value because that manifest was not included in the snapshot.
The real UE 5.8.3 → 5.8.4 update was completed earlier using the same one-field patch mechanism, not by running this exact final public script against the live installation.
These are separate validation results and should not be confused.
10. Manual examination for advanced users
For experienced users who understand EGL/EOSH metadata and its associated risks, the one-field change can also be investigated manually if the script refuses to proceed.
However, this should only be considered when the installation matches the specific conditions documented above.
The relevant live EGL metadata file is located at:
C:\ProgramData\Epic\EpicGamesLauncher\Data\Manifests\<InstallationID>.item
In my confirmed case, the relevant value was:
Before:
"ManifestHash": "7824ea53198b0f36a0a291bb3ee11f563912056d"
After:
"ManifestHash": ""
Important: Do not clear arbitrary non-empty ManifestHash values.
A different value may be legitimate or may indicate a different installation state.
Before considering a manual experiment:
- Completely close Epic Games Launcher and EpicWebHelper.
- Confirm that the installed version and EOSH version agree.
- Confirm that
.item and .egi revisions agree.
- Ensure there is no active EOSH pending transaction.
- Ensure no pending
.item, pending installed manifest, or BPS operation remains.
- Back up the original
.item and relevant metadata.
- Preserve the original file encoding and all unrelated properties.
Do not manually modify:
EOSH .egi
Revision.json
EoshRevision
LauncherInstalled.dat
Plugin registrations
If the installation does not match the documented fingerprint, the safest approach is to preserve the logs and metadata for Epic rather than force the workaround.
Also, do not restore old metadata after EGL has already started a new update transaction.
11. Additional observation: LauncherInstalled.dat
One interesting detail remained after the successful update.
The live .item, EOSH record, installed manifest, and physical engine build all indicated UE 5.8.4.
EGL displayed:
Launch
However, LauncherInstalled.dat still reported:
5.8.3-58210709+++UE5+Release-5.8-Windows
This discrepancy did not prevent the installation from working.
I intentionally left the file unchanged.
It may be useful for Epic to investigate which metadata source is authoritative during installation preparation, commit, and finalization.
12. Final update from my side
With Epic moving toward the new Beta Launcher, I intend this to be my final update to this thread for now.
Over the course of the investigation, the issue has been narrowed down considerably.
What initially appeared to be an endless Resume loop was traced through patch activity, EOSH installation-state transitions, manifest fingerprints, and revision changes.
Eventually, a specific stale ManifestHash value was identified, and removing that value alone allowed the update to complete successfully.
I hope these findings provide the Epic team with a useful starting point to reproduce the behavior, inspect the relevant launcher state-management logic, and implement an appropriate permanent fix.
The exact internal root cause still needs to be confirmed by Epic.
13. A personal closing note
I also want to clarify something about why I spent so much time investigating this.
It was never about proving that I know better than Epic’s engineers or anyone else here.
I’m a bit of a perfectionist by nature, and when something doesn’t work as expected, my curiosity rarely lets me leave it unexplained. I enjoy following the evidence, testing different possibilities, and trying to understand what is really happening beneath the surface.
I suppose you could say that once a problem catches my attention, it has a hard time escaping without revealing at least a few of its secrets. 
What started as a frustrating launcher issue gradually became a genuinely interesting technical investigation.
Beyond satisfying my own curiosity, I wanted to contribute something useful toward improving Unreal Engine and its surrounding tools.
I believe many developers here share that same passion. We build with this engine, encounter challenges, investigate them, and sometimes discover something worth sharing with the community.
If these findings help Epic identify the underlying issue, or save another developer from going through the same troubleshooting process, then every hour spent investigating was worthwhile.
Thanks to everyone who followed this investigation, and to the Epic team for taking a look.
Happy developing!