microsoft / microsoft/WindowsAppSDK

[Bug] SystemMediaTransportControls.GetForCurrentView throws “Invalid window handle” in WinUI 3

Open
#6,740 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area-External needs-triage
Dominant language
C++
Stars
4.7k
Forks
471
Avg merge
3d 13h
Merged PRs (30d)
28

Description

Describe the bug

Calling SystemMediaTransportControls.GetForCurrentView() from a WinUI 3 desktop application throws a COMException with 0x80070578 (Invalid window handle), even when the call is made on the UI thread after the main window has been created and activated.

The exception message suggests using WindowNative or InitializeWithWindow, but neither is applicable to this API. This makes the failure confusing, especially because GetForCurrentView() is discoverable from a WinUI 3 project.

Steps to reproduce the bug
  1. Create a packaged WinUI 3 desktop application.
  2. After the main window has been created and activated, run this code on the UI thread:
using Windows.Media.SystemMediaTransportControls;

var smtc = SystemMediaTransportControls.GetForCurrentView();
smtc.IsEnabled = true;
  1. Observe the exception.
Expected behavior

Either:

  • GetForCurrentView() should return a valid SystemMediaTransportControls instance for the active WinUI 3 window, or
  • the API/documentation should clearly state that it is not supported in WinUI 3 and provide the supported replacement.
    The exception should not suggest WindowNative or InitializeWithWindow when those mechanisms cannot initialize this API.
Actual behavior

The call throws:

System.Runtime.InteropServices.COMException:
Invalid window handle. (0x80070578)
Consider WindowNative, InitializeWithWindow
See https://aka.ms/cswinrt/interop#windows-sdk
Workaround

Creating a MediaPlayer and retrieving SMTC from that player works correctly:

using Windows.Media.Core;
using Windows.Media.SystemMediaTransportControls;

var mediaPlayer = new MediaPlayer
{
    AutoPlay = false,
    IsMuted = true
};


var smtc = mediaPlayer.SystemMediaTransportControls;
smtc.IsEnabled = true;

When audio is rendered through another pipeline such as AudioGraph, developers are forced to create an otherwise unnecessary muted MediaPlayer instance solely to obtain and own SystemMediaTransportControls for the Windows media session, metadata, lock-screen integration, and transport buttons.

Steps to reproduce the bug
Expected behavior

No response

Screenshots

No response

NuGet package version

2.4.1

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 24H2 LTSC (26100, June Update)

IDE

Visual Studio 2022-preview

Additional context
  • Target framework: net10.0-windows10.0.22621.0
  • .NET SDK: 10.0.400-preview.0.26322.102

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Begin with the WinUI 3 desktop reproduction using SystemMediaTransportControls.GetForCurrentView() after window activation, then compare the MediaPlayer.SystemMediaTransportControls workaround. Determine whether the API is supported in this scenario; done means the misleading exception is corrected or the unsupported status and supported replacement are clearly documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
api, desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.