Unreal Engine Crash

Satisfactory: Fixing Unreal Engine Crashes

Since the upgrade to **Unreal Engine 5** in Update 8 (and 1.0), Satisfactory has become significantly more demanding on hardware. Crashes typically occur due to Video Memory (VRAM) issues, DirectX 12 incompatibility, or corrupted mod files. This comprehensive guide covers all common crash types, diagnostic steps, and solutions for both clients and servers.

Common Error Codes & Solutions

Client-Side Crash Fixes

Force DirectX 11 (Most Common)

UE5 defaults to DirectX 12, which can be unstable on older graphics cards (GTX 10 series, some RTX cards) and can cause crashes. Forcing DX11 provides stability for many players:

1. Right-click Satisfactory in your Steam library.
2. Go to Properties -> General.
3. In Launch Options, type: -dx11
4. Launch the game and test stability.

Alternative: Vulkan (Linux)

• Linux Users: Try -vulkan launch option for potentially better performance and stability
• GPU Support: Requires Vulkan-compatible graphics driver
• When to Use: Try Vulkan if DX11 doesn't solve crashes or improves performance

Graphics Settings Optimization

• Lower Settings: Reduce Texture Quality, Shadows, and View Distance to decrease VRAM usage
• Disable Lumen: Global Illumination is very demanding. Disable if experiencing VRAM crashes.
• Resolution Scale: Use 85-90% render scale if at 1080p or higher
• Effects Quality: Set to Medium or Low to reduce GPU load
• Test One Change at a Time: Modify one setting at a time to identify what helps

Forcing a Server Log Check

If your **Dedicated Server** is crashing, you need to log file:

• Path: /.config/Epic/FactoryGame/Saved/Logs/FactoryGame.log
• Look for the phrase "Error:" or "Critical:".
• If you see UNetConnection::Tick errors, it is likely a network bandwidth issue. Increase your Network Quality setting.

Server-Side Crash Analysis

While clients experience graphics crashes, server crashes typically have different causes:

• Save Corruption: Damaged or corrupted save files prevent server startup.
• Memory Issues: Insufficient RAM for save file size or player count causes crashes.
• Mod Conflicts: Server-side mods incompatible with game version or each other.
• Configuration Errors: Invalid server settings or corrupt configuration files.
• Performance Load: Server overwhelmed by player count or factory complexity.

Server Log Analysis

Detailed analysis of server crash logs reveals specific failure points:

• Log Location: /.config/Epic/FactoryGame/Saved/Logs/FactoryGame.log
• Error Patterns: Repeated errors indicate underlying problems.
• Critical Errors: "Fatal" or "Critical" messages indicate severe issues requiring immediate attention.
• Performance Warnings: Warnings about simulation lag or memory pressure.
• Load Failures: Mod loading failures or missing dependencies.
• Network Errors: Connection issues between server and clients.

Save File Integrity

Most server crashes are save-file related. Understanding save file integrity is crucial:

• File Size: Extremely large saves (>1GB) can cause loading crashes.
• Corruption: Incomplete saves or damaged file structures.
• Complexity: Massive factories with thousands of machines stress save system.
• Modded Content: Excessive modded buildings or items can corrupt saves.

Memory Management

Proper memory configuration prevents many crash types:

• System RAM: Ensure adequate system RAM for server and player count.
• Page File Size: Adjust Virtual Memory (VMem) to handle larger saves.
• Process Priority: Set Satisfactory to High priority in task manager.
• Background Apps: Close unnecessary applications to free memory.
• Memory Cleanup: Restart server regularly to clear memory leaks.

Mod Stability

Mods are a common source of server instability:

• Version Matching: Ensure all mods updated to same version.
• Dependencies: Verify all mod dependencies are installed correctly.
• Load Order: Some mods require specific load order.
• Conflicts: Disable mods causing server-side issues.
• Testing: Test mods in single player before server deployment.

EXCEPTION_ACCESS_VIOLATION root cause flowchart (refreshed 2026-05)

EXCEPTION_ACCESS_VIOLATION is the most common Satisfactory crash signature reported in 2026. It's a generic Windows error code meaning the game tried to read memory it shouldn't, which has many possible causes. Walk through these in order; stop when one applies.

Step 1: Verify game files

This catches roughly 40% of EXCEPTION_ACCESS_VIOLATION reports. Steam → right-click Satisfactory → Properties → Installed Files → Verify integrity. Wait 5-15 minutes. If files were corrupted, the verify will redownload them. Test stability afterwards.

Step 2: Update GPU drivers (client-side only)

Then 30% of remaining cases. NVIDIA drivers in particular shipped at least one bad release in 2025 that crashed UE5 games on factory-scale objects. Always run the latest "Game Ready" driver. If the latest driver introduced the crash, roll back to the previous version using DDU (Display Driver Uninstaller) for a clean uninstall.

Step 3: Test in offline / vanilla mode

If the crash only happens on a specific server or with a specific mod set, eliminate variables:

• Disconnect from the server. Launch single-player. Crash? It's client-side. No crash? It's interaction with the server.
• Disable all mods. Launch single-player. Crash gone? A mod is the cause; re-enable mods one by one until it returns.
• Try a different world. Crash gone? Save corruption; restore from a backup older than the crash started.

Step 4: Memory and page file

Satisfactory 1.0+ can use 12-18 GB of RAM on a late-game factory. If your system has 16 GB and you have a browser + Discord running, Windows will start swapping aggressively. Symptoms: micro-stutters that escalate to crash within 10-20 minutes of play.

• Close all background apps that aren't needed for the session.
• Increase Windows page file: Control Panel → System → Advanced system settings → Performance → Settings → Advanced → Virtual Memory. Set initial 8192 MB / max 16384 MB on the SSD with the most free space.
• If you have 32 GB+ RAM, this step is usually not the cause.

Step 5: XMP / DOCP / BIOS overclock (rare but real)

If memory in your system is running at an XMP profile (above JEDEC base clock), Satisfactory's UE5 build can occasionally trip access violations from marginal RAM behavior. Test by disabling XMP in BIOS, booting Windows, launching the game. If stability improves, your XMP profile is marginal; try a slower XMP profile or upgrade your RAM kit.

Step 6: Mod referencing deleted assets

If you removed a mod from your installation but its references are still in the save file, loading the world can crash on first asset lookup. Either reinstall the missing mod (easiest) or use SCIM (Satisfactory Calculator Interactive Map) to remove the modded entities from the save before launching again. See our SCIM guide.

Step 7: Server-side EXCEPTION_ACCESS_VIOLATION

If the access violation is happening on the dedicated server (not the client), the diagnostic flow changes:

1. Check FactoryGame.log for the line above the crash. Mod names appearing there = mod-side cause.
2. Try launching the server with no save (empty world). If it starts clean, your save is the cause. Restore from backup.
3. If empty-world also crashes, the game binary may be corrupted. Reinstall via SteamCMD.
4. If reinstall doesn't help, check disk health: chkdsk on Windows, fsck on Linux. Bad sectors can corrupt the engine .pak files in ways verify won't catch.

The locomotive-delete crash in 1.2.2.0

If you hit EXCEPTION_ACCESS_VIOLATION specifically when dismantling a train locomotive, this is a known Coffee Stain bug introduced in v1.2.2.0 Build 488068. See the dedicated locomotive crash workaround page for the safe demolition pattern that avoids it.

Keep the factory growing. Host your Satisfactory server with Supercraft and benefit from our automated crash detection and auto-restart systems.