Virtual Display Issues

Bug Symptoms

I am constantly having issues with the monitors after using Virtual Display. Frequently they just stay blank and won't come back on. If I hold win+p it will activate but only 1 monitor in the 1|2 mode. Powering off fixes the issue sometimes or powering off the monitors. But frequently it just requires a bunch of these actions until the monitors come back up.

Expected Behavior

The monitors come back up as they were before streaming.

Windows Version

22H2

Package

Windows - exe installer

GPU Type

AMD

GPU Model

RTX 3080

GPU Driver Version

617.42

Capture Method

None

Apps

Logs (Optional but Recommended)

No response

Screenshot (Optional)

Just to add that I'm also facing this issue.

I've noticed that it will change the project (win+p) setting to only second monitor around 5 seconds after the login.

But I'm never able to replicate it again, only after wait a day or so.

I have now a script (with the help of ai) to start recording long, task history and events for the first 60 seconds after starting so I can see what is causing this.

There are two workaround for this:

win+p and move with the arrow once up and there enter to change the project setting manually
create a task schedule with the following setting:

Trigger:
At log on
Specific user: YourUser
Delay task for: 30 seconds

Action:
C:\Windows\System32\DisplaySwitch.exe

Arguments:
/clone

today it happened the issue again.
I saw a CMD for vibeapollo and then the project settings changed.

The following is a text that AI prepared to better explain the situation:

My setup: Windows 11 25H2 (build 26200), AMD Radeon RX 6800, Vibepollo 2.0.0 (commit 8a8c4b0), legacy display helper engine. Physical DisplayPort monitor plus HDMI dummy (HDP-V104); desired desktop layout is Duplicate.

On 2026-10-10 (local time, UTC+1):

20:52:03: Task Scheduler launched VibepolloDisplayRestore at logon, running sunshine_display_helper.exe.

20:52:09: The helper logged that it was running in --restore mode and found a current session snapshot.

20:52:21: Its "Session restore (current) attempt Welcome to Vibepollo Discussions! #1" entry explicitly shows before_sig with both displays duplicated, but current_sig and baseline_sig containing only the HDMI dummy. It reports layout_match=true and match=true, promotes current to previous, and exits after confirming restoration.

20:52:33: My DisplaySwitch.exe /clone workaround ran and restored duplication.

Display IDs in the evidence:

{3de0d110-e344-5249-8328-dade10213cf1}: physical DisplayPort monitor.

{8d6b89dc-8b3a-5516-8a54-a962c1fe0bd0}: HDP-V104 HDMI dummy.

The golden snapshot contains both displays duplicated, while the session snapshot contains only the dummy. display_session_previous.json is the file available AFTER this boot's helper promoted current to previous; it is not a pre-boot copy of current.

Earlier that afternoon, at 14:20:58, the helper refreshed the current snapshot and registered VibepolloDisplayRestore. Its device enumeration showed only HDP-V104 available and the configured physical display unavailable. This appears to explain how a dummy-only session baseline remained pending for the next logon.

In a known-good startup captured on October 9, this restore task did not execute in the startup window. This fits the intermittent behavior.

Possible code issue to check: in this commit, legacy ServiceState::always_restore_from_golden starts false; the --restore branch constructs a fresh ServiceState without loading the configured golden preference before starting restore. The normal host configuration defaults dd_always_restore_from_golden to true, but that does not appear to reach this standalone boot-restore process. This is a source-based inference; the actual change to dummy-only is directly confirmed by the attached helper log.

Could boot recovery honor the golden-restore preference, so it does not replace an already-working duplicated desktop with a saved dummy-only session layout?

Attached: display-helper log, golden/session snapshots, relevant Task Scheduler events, and the afternoon log excerpt. User/machine names were redacted. No full ETL or pairing/credential files are included.

Vibepollo-579-evidence.zip

And this was the setting that I've just changed to see if it happens again or not

fix(display): Honor configured golden policy during boot recovery

fix(tests): build restore policy fixture with Boost targets

The new nightly 2.0.2-daily.d20261017.2 is available.

This includes a fix for boot recovery honoring the configured golden-snapshot preference. Please retest logging in with your duplicated physical-monitor and HDMI-dummy layout.

Please post your results here. If the issue persists, attach fresh exported logs or a crash bundle from this build.

I'll test with the latest version but I haven't had this issue come up since updating to 2.0.1. However, there are a few other odd bugs that I am having.

Thanks for reporting that this issue hasn't occurred since updating to 2.0.1. Closing this as resolved. Please open separate issues for the other bugs, and reopen this one with your version and updated logs if the original monitor-restoration problem returns.

Navigation Menu

Repository navigation

Virtual Display Issues #579

Bug Symptoms

Expected Behavior

Windows Version

Package

GPU Type

GPU Model

GPU Driver Version

Capture Method

Apps

Logs (Optional but Recommended)

Screenshot (Optional)

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Virtual Display Issues #579

Description

Bug Symptoms

Expected Behavior

Windows Version

Package

GPU Type

GPU Model

GPU Driver Version

Capture Method

Apps

Logs (Optional but Recommended)

Screenshot (Optional)

Activity

Santodan commented on Oct 10, 2026

Santodan commented on Oct 10, 2026

Nonary commented on Oct 18, 2026

max1c commented on Oct 18, 2026

Nonary commented on Nov 1, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions