Windows does not wake up after streaming from Moonlight to Sunshine on an application with an command

[CrendKing]

Is there an existing issue for this?

• I have searched the existing issues

Is your issue described in the documentation?

• I have read the documentation

Is your issue present in the nightly release?

• This issue is present in the nightly release

Describe the Bug

Base line

Install Sunshine as a Windows service and make it auto start. After booting, use Start menu to sleep. Wake it up with mouse, behave normal.

Minimum reproducible steps

1. Start Sunshine as Windows service.
2. Create an application in Sunshine.
3. Give it a command. The executable could be anything that terminates by itself, but the smallest could be a program that just sleeps a few seconds then exit. Something like

int main(int argc, char **argv) {
    std::this_thread::sleep_for(5s);
    return 0;
}

4. Uncheck "Continue streaming if the application exits quickly" to make sure Sunshine ends the stream when the command finishes.
5. Start a stream. After the command finishes, make sure the Sunshine tray icon no longer shows the "Play" icon.
6. Use Start menu to sleep.
7. Wake it up with mouse. It's now in a weird state that 1) the screen is off; 2) doesn't respond to any input from keyboard and mouse; 3) doesn't respond to any network request like a ping. The only thing left is to force reboot.

Other tests

It seems the trigger must include a command being in the Sunshine application, and the command terminates itself.

1. Stream the "Desktop" application, which can last infinite. Make the client quit the stream. The sleep can be waken up.
2. Stream the "Test" application. After it terminates by itself, restart Sunshine. Sleep can wake.
3. Stream the "Test" application, but instead of waiting for it to terminate by itself, make the client quit the stream. Sleep can wake.
4. Start sunshine.exe directly instead of a Windows service and repeat the steps above. Sleep can wake.

Expected Behavior

Regardless if there is a command in the application, or if client quits or not, the host should be able to sleep then wake afterwards.

Additional Context

There is a similar (and probably related) issue at #1809. But the trigger seems different. Also, I use WIFI.

Host Operating System

Windows

Operating System Version

Windows 11 23H2

Architecture

64 bit

Sunshine commit or version

0.21.0 and tested in nightly. I verified that earlier versions (such as 0.20.0) does not have the problem.

Package

Windows - Scoop (Third Party)
Nightly (29a1b15, Portable)

GPU Type

Nvidia

GPU Model

RTX 2070 Super

GPU Driver/Mesa Version

546.17

Capture Method (Linux Only)

No response

Config

<Empty>

Apps

{
    "env": {
        "PATH": "$(PATH)"
    },
    "apps": [
        {
            "name": "Desktop",
            "image-path": "desktop.png"
        },
        {
            "name": "Test",
            "output": "",
            "cmd": "<path>\test.exe",
            "exclude-global-prep-cmd": "false",
            "elevated": "false",
            "auto-detach": "false",
            "image-path": ""
        }
    ]
}

Relevant log output

There is no outstanding log. The last line is just the standard "Process Terminated" line.

[CrendKing]

I took some time to redo some tests. I found that the current system state, such as what other processes are running or how they affect the video driver state, could affect the test result of the method above, so I recommend to do a system reboot before testing.

I tested many nightly CI builds from the GitHub Action, and even the earliest non-expired build, https://github.com/LizardByte/Sunshine/actions/runs/6041792681, has the issue. Again, v0.20.0 is fine. So the issue must be introduced between 31e8b79 and a3eec98.

I currently do not have a MinGW environment to further bisect the root cause. Can someone help?

[ReenigneArcher]

Nightly builds are available here: https://github.com/LizardByte/Sunshine/releases/tag/nightly-dev

[CrendKing]

Thanks. But I need nightly builds BEFORE Aug 31. Or more precisely, all nightly builds SINCE v0.20.0 to bisect the root cause. Do you guys somehow archive historical nightly builds?

[ReenigneArcher]

We only keep artifacts for 90 days.

[CrendKing]

Thought so. Looks like the only way is to build myself. Gonna take a while... Would anyone be interested to a fix if I can find the culprit commit?

[ReenigneArcher]

Yes, it would be helpful if you can track down a specific commit that is causing the issue.

[CrendKing]

Found it. I think it's 11aedf5. I don't know enough about Sunshine to see why though.

FYI, in order to build with the current MinGW, I have to backport some commits. Specifically, f3a257b1 and cgutman/enet@880e41f. I verified these wouldn't change the outcome of the issue.

[ReenigneArcher]

@cgutman I didn't see anything obvious in that commit which could cause this. Any Idea?

[LizardByte-bot]

It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!

[CrendKing]

Still waiting for a proper fix. Is anyone interested in taking this?

[CrendKing]

As of v0.23.1, I can no longer reproduce the issue. Maybe it's fixed?