#1532·Apollo

Virtual Display creation failed, or cannot get created display name in time!

Author: thwysterCreated Jul 2, 2026Updated Sep 1, 2026

Description

Apollo consistently fails to create the SudoVDA virtual display and falls back to streaming the physical laptop panel instead. This happens on an Optimus (Intel iGPU + NVIDIA dGPU) laptop, even after a full clean reinstall of the SudoVDA driver.

Environment

  • Apollo version: 0.4.6
  • OS: Windows 11
  • GPU: Intel(R) UHD Graphics (iGPU) + NVIDIA GeForce RTX 3070 Laptop GPU (dGPU) - Optimus laptop
  • headless_mode = enabled
  • isolated_virtual_display_option = enabled
  • No adapter_name set (default)

Steps already tried

  1. Found and removed a conflicting third-party virtual display driver (mttvdd / MikeTheTech Virtual Display Driver) that was installed by mistake in an earlier troubleshooting session, then fully rebooted. This driver was crashing WUDFHost.exe with an access violation, which I originally suspected was blocking SudoVDA's interface from registering.
  2. After the reboot, the SudoVDA device (root\sudomaker\sudovda, oem235.inf) still showed ConfigManagerErrorCode = 22 (disabled) in Device Manager. Re-enabling it directly failed ("device not connected").
  3. Ran the official install.bat (via nefconc.exe --remove-device-node + --create-device-node + --install-driver) from drivers/sudovda as Administrator. This succeeded cleanly:
    Device and driver removed successfully
    Device node created successfully
    Driver installed successfully
    Device Manager now shows the device as Status = OK, ConfigManagerErrorCode = 0.
  4. Restarted ApolloService. Connected via Moonlight — the SudoVDA driver opens successfully (no silent failure), but Apollo logs:
    Info: Display mode for client [CLIENT] requested to [1920x1080x120]
    Warning: Virtual Display creation failed, or cannot get created display name in time!
    ...
    Info: Session resuming for app [Virtual Display].
    Info: CLIENT CONNECTED
    Debug:     Output Name       : \\.\DISPLAY1
    It falls back to streaming the physical built-in display (\\.\DISPLAY1) instead of the virtual one.
  5. Per the README guidance for dual-GPU laptops, tried setting adapter_name = NVIDIA GeForce RTX 3070 Laptop GPU in sunshine.conf with headless_mode = enabled. This made things significantly worse — Apollo failed to start any encoder at all on startup:
    Info: Trying encoder [nvenc]
    Error: Failed to locate an output device
    ...
    Info: Encoder [nvenc] failed
    Info: Trying encoder [quicksync]
    Error: Failed to locate an output device
    ...
    Fatal: Unable to find display or encoder during startup.
    Fatal: Please ensure your manually chosen GPU and monitor are connected and powered on.
    Info: Creating a temporary virtual display to probe for encoders...
    ... (same failures for all encoders: nvenc, quicksync, amdvce, software)
    Error: Video failed to find working encoder: allow probing but failed
    Reverted adapter_name immediately, which restored normal (physical-display-fallback) operation.

What I'd like help with

  • Confirming whether this is the same root cause as #1531 (virtual display created but never appears in QDC_ONLY_ACTIVE_PATHS before the polling timeout), and whether there's a known workaround for Optimus (iGPU+dGPU) laptops specifically.
  • Any additional diagnostics (registry keys, driver verbose logging, etc.) that would help pinpoint why the display never becomes "active" in the CCD topology in time.

Happy to provide more verbose logs / pnputil output if useful — didn't want to dump a huge raw log here since it contains client-identifying info (device names, EDID) that I'd like to redact first.