I'm running Windows 11 with an RTX 5080 and three possible displays: a physical monitor identified as `AUS274D`, a case-mounted display identified as `RTK409A`, and a Virtual Display Driver identified as `MTT1337`. I want a PowerShell script launched by Task Scheduler to use the monitor connection as a boot-time switch: when the physical monitor is connected, it should become the primary display and the virtual display should be disabled; when the physical monitor is absent, the virtual display should become primary and the physical displays should be disabled. I'm currently exporting monitor information with MultiMonitorTool, checking the Short Monitor ID, and then using its enable, disable, and SetPrimary commands. How reliable is that detection while Windows and the NVIDIA driver are still enumerating displays at startup? Would WMI, CIM, EDID data, the registry, or the Windows Display Configuration API be more dependable? Are there timing issues at logon that I should account for, and can a scheduled task run early enough to apply the desired layout without manual interaction?
4 Answers
You can start with Plug and Play monitor enumeration through PowerShell, for example querying `Win32_PnPEntity` and filtering for devices whose PnP class is `Monitor`. It may be sufficient for detecting whether the physical panel is present, although you should still account for the fact that enumeration can briefly lag during startup.
A logon-triggered scheduled task is the practical place to run this. PowerShell and the normal display APIs aren’t available before Windows has booted, and a service in Session 0 may not be able to manipulate the interactive user’s display configuration reliably. Even tasks that start early can race the NVIDIA driver and display enumeration, so add a short delay or retry loop and wait until the expected monitor IDs or EDID data appear before applying the layout. The fact that a script runs after boot doesn’t necessarily mean it must wait until after the desktop is visible; Task Scheduler can be configured to start before user logon, but the display APIs still need an interactive session and initialized graphics driver.
A dummy HDMI or DisplayPort adapter is another option. It presents a consistent EDID to Windows, so the system always sees a physical-style display instead of changing between a connected monitor and a virtual one. That can avoid some of the detection and layout changes, though it’s less useful if you specifically need the real monitor’s connection state to control the result.
The virtual display is already working well, so I’m mainly trying to make the automatic selection reliable rather than replace it with a dummy adapter.
Windows often remembers display layouts for different physical connection states, so it may automatically restore the previous configuration when the monitor is connected or disconnected. If you still want explicit control, a display-configuration PowerShell module can expose active status, primary status, display IDs, and EDID information such as serial numbers. You can then select the matching display and call a command such as `Set-DisplayPrimary` after checking which one is active. This is generally cleaner than relying only on a short monitor ID from an external utility, but you’ll still need to verify whether the module can activate a disabled virtual display and extend the desktop to another panel.
That approach looks cleaner. The important remaining question is whether it can enable a VDD that starts inactive or disconnected, rather than only changing the primary display among monitors Windows has already activated.
I initially considered a Session 0 service to act before the login screen, but Task Scheduler can run before logon, so that may be unnecessary over-engineering. I’m testing the scheduled-task approach with the existing PowerShell proof of concept.