Skip to content

ERSS-FG + OptiScaler 0.10 RDNA2: three different crashes (Streamline deadlock / double D3D12 proxy / E_NOTIMPL) on Win10, Elden Ring #1070

Description

@yj8805

OptiScaler_Issue_logs.zip

Environment

  • OS: Windows 10 22H2 (Build 19045)
  • GPU: AMD RX 6700 XT (RDNA2)
  • Game: Elden Ring v1.16.2.0 (launched via me3 with --disable-arxan)
  • ERSS-FG: v4.14.1 (huutaiii), loaded as d3d12.dll + ERSS-FG.dll + ERSS2/bin/ (Streamline 2.11.1)
  • OptiScaler: 0.10.0.1 RDNA2 special build (Fsr4ForceModel=2 INT8)
  • Installation: Manual

Prior search: Searched existing OptiScaler Issues (keywords: ERSS, StreamlineSpoofing, RDNA2 Win10, Elden Ring, slInit). No similar report found. This combination appears to be unreported.

Did check the Wiki and Compatibility List. The Wiki page for Elden Ring (ERSS-FG) states "Last Tested Version 0.9" on W11 24H2 + RX 9070 XT (RDNA4) / Arc — none of our combination (0.10 + Win10 + RDNA2) has been tested.


Issue description

Unable to get OptiScaler working with ERSS-FG on Win10 + RDNA2 for Elden Ring. Tried all 3 supported injection filenames (dxgi.dll, version.dll, d3d12.dll), each crashes differently.

Attempt 1: OptiScaler as dxgi.dll, ERSS-FG as d3d12.dll

Result: slInit deadlock → crash before main menu

Root cause: OptiScaler (dxgi.dll, loaded earliest by the game's DXGI import) hooks Streamline's slInit immediately. ERSS-FG (d3d12.dll) calls slInit later → reentrant deadlock in sl.common.dll.

Evidence from ERSS2/sl.log:

pluginManager.cpp:705[loadPlugin] JSON exception resource deadlock would occur
→ all sl.*.dll plugins fail → "no plugins are found" → slInit failed 8

Evidence from OptiScaler.log:

StreamlineHooks::hookInterposer → hkslInit → Hooking slGetPluginFunction in sl.common
(all hooked BEFORE ERSS-FG calls slInit)

Attempted fixes (all failed): StreamlineSpoofing=false, FGInput=nofg, EnableDlssInputs=false

Attempt 2: OptiScaler as version.dll, ERSS-FG as d3d12.dll

Result: Assertion failed (baseRefCount == 0) → crash before main menu

Root cause: version.dll loads later than d3d12.dll, so OptiScaler's Streamline hooks miss the slInit window → no deadlock (improvement!). But OptiScaler's hkD3D12CreateDevice wraps ERSS-FG's already-existing Streamline D3D12 proxy → double proxy layer → IUnknown reference count mismatch → baseRefCount == 0 assertion.

Evidence from ERSS2/ERSS-FG.log:

Creating SL proxy D3D12 device  (on RX 6700 XT)
... Destroying Renderer ...
[ERROR] Assertion failed (baseRefCount == 0)
Adapter: 0x1414 0x8c "Microsoft Basic Render Driver" (WARP fallback)
[ERROR] Unhandled exception (0xc0000005) at ERSS-FG.dll+0x12e817

OptiScaler.log shows StreamlineHooks all successful (loaded sl.common/dlss_g/nis/pcl/reflex), initializePlugins OK, but hkD3D12CreateDevice fires on the already-proxied device.

Attempt 3: OptiScaler as d3d12.dll, ERSS-FG loader as d3d12-original.dll (OptiScaler chained-load via -original suffix)

Result: D3D12CreateDevice returned 0x80004001 (E_NOTIMPL) → crash

Root cause: OptiScaler(d3d12.dll) chain-loads ERSS-FG's loader as the "original system D3D12 library". But ERSS-FG's d3d12.dll is a hook/loader, not the real system D3D12.dll. When OptiScaler calls o_D3D12CreateDevice via the chained loader, the ERSS-FG hook stub returns E_NOTIMPL because it hasn't fully initialized its pipeline yet.

Evidence from OptiScaler.log:

LibraryLoadHooks::LoadLibraryCheckW d3d12.dll call, returning this dll!
hkD3D12CreateDevice Adapter: AMD Radeon RX 6700 XT
hkD3D12CreateDevice o_D3D12CreateDevice result: 80004001
D3D12CreateDevice failed with error code 80004001

Also, DxgiSpoofing was auto-disabled (log: DxgiSpoofing and DxgiVRAM is disabled, skipping hooking), causing OptiScaler to report fsr4: false, dlss: false for the RX 6700 XT.

Isolation confirmation

Pure ERSS-FG (no OptiScaler at all): ✅ Works perfectly.
Full clean log:

Hooking D3D12.dll early → Hooking DXGI.dll early → Loading Streamline
→ Creating SL proxy for IDXGIFactory interface
→ Creating SL proxy for D3D12 device interface
→ Creating ID3D12Device proxy → Creating upscaling pipeline
→ Creating descriptor heap → Initializing renderer

Home menu opens, FSR/FSR3 selectable. Zero errors. The only crash is eldenring.exe Scaleform::Render UI layer (unrelated).

Conclusion: The incompatibility is 100% between OptiScaler's D3D12 proxy/detour mechanism and ERSS-FG's Streamline/D3D12 hooks. No load order or filename can avoid it on Win10+RDNA2.


Key config (OptiScaler.ini, the last state used)

Fsr4ForceModel = 2
FsrAgilitySDKUpgrade = false
UEIntelAtomics = true
LoadCustomAmdxc64OnRdna2 = true
Dx12Upscaler = ffx
StreamlineSpoofing = false
FGInput = nofg
EnableDlssInputs = true

Questions / Request

  1. Is there any mode to disable OptiScaler's own D3D12 proxy (let ERSS-FG handle all D3D12 proxy creation) while keeping OptiScaler's upscaler conversion layer?
  2. Or a mode where OptiScaler attaches to an existing D3D12 proxy rather than creating its own?
  3. Or any specific OptiScaler.ini combination for this Win10 + RDNA2 + ERSS-FG + 0.10 scenario?

If none, I suggest documenting this combination as incompatible on the Wiki's Known Issues / ERSS-FG page.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingmastermaster branch

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions