fix(wgc): tell "no outputs" apart from "outputs could not be read"

DXGI_ERROR_NOT_CURRENTLY_AVAILABLE is not the end of an enumeration. It is what
EnumOutputs answers a process in session 0, and it means the outputs were never
inspected rather than that the adapter has none. Both were being folded into the
same FAILED() test, so a machine we could not look at reported exactly what a
machine with an active virtual display reports: monitorAdapter null.

That value is one this diagnostic tells its readers to act on -- the briefing
sent to an operator said null meant a purely virtual display. It would have sent
them down the wrong path, and it is the same class of defect this PR was opened
to fix for the descriptions: an ambiguity that reads as a finding.

The event now carries monitorLookup: ok, no-output-claims-it, or unavailable, so
the absence of a monitor adapter is never reported without saying whether anyone
actually looked. The stderr dump says outputs=unavailable rather than
outputs=none for the same reason.

Unreachable from the app, which spawns the helper from the user's session -- but
the helper is run standalone by hand during exactly this investigation, and that
is where session 0 gets reached.

Author: EtienneLescot

electron/native/README.md

@@ -91,7 +91,7 @@ Frame input path: the helper feeds the encoder from the GPU when it can. On that
 
 The helper reports the outcome through the `encoder-selection` stdout event (`video` is `default`, `software-preferred`, or `software-fallback`; `videoInput` is `dxgi-nv12` or `cpu-rgb32`; `container` is `fragmented-mp4` or `mp4`; all three report what the encoder settled on rather than what was asked for). On the GPU path the helper also prints one `[frame-drops] gpu_bridge_contended=<n>` line to stderr at stop: a frame the bridge was too busy to take is skipped rather than failing the recording, and a large count there is the first thing to look at in a report about missing frames. When the app sees `software-fallback` — the default encoder failed and the helper switched on its own — it shows a small dismissible notice in the recording HUD with a "Don't show again" option, because software encoding can raise CPU usage. An explicit `software-preferred` selection shows no notice, and the event stays available for diagnostics either way.
 
-At startup the helper also emits `capture-adapter`, naming the GPU its D3D device landed on and the one actually driving the captured display, each with its LUID, plus one `[adapters]` line per enumerated adapter on stderr. `createD3DDevice` asks for the *default* adapter and nothing checks that it is the one driving the display; when they differ every frame crosses an adapter boundary before the caller touches it. The LUIDs are there because the descriptions are not enough to tell: an IddCx virtual display driver renders through the physical GPU and inherits its description string while being a separate DXGI adapter, so the configuration this diagnostic exists to catch is precisely the one where both names are identical and only the LUIDs differ (measured: `NVIDIA Quadro RTX 4000` at LUID `0:24084` driving the display, the same string at `0:12889146` for the virtual adapter).
+At startup the helper also emits `capture-adapter`, naming the GPU its D3D device landed on and the one actually driving the captured display, each with its LUID, plus one `[adapters]` line per enumerated adapter on stderr. `createD3DDevice` asks for the *default* adapter and nothing checks that it is the one driving the display; when they differ every frame crosses an adapter boundary before the caller touches it. The LUIDs are there because the descriptions are not enough to tell: an IddCx virtual display driver renders through the physical GPU and inherits its description string while being a separate DXGI adapter, so the configuration this diagnostic exists to catch is precisely the one where both names are identical and only the LUIDs differ (measured: `NVIDIA Quadro RTX 4000` at LUID `0:24084` driving the display, the same string at `0:12889146` for the virtual adapter). `monitorLookup` says which of three things happened: `ok`, `no-output-claims-it` (the enumeration finished and nothing owns the captured monitor, which is what an active virtual display looks like), or `unavailable` (`EnumOutputs` refused, as it does in session 0 — the outputs were never inspected, so the absence means nothing about the hardware).
 
 Encoder diagnostic on final sink-writer failure: when the final sink-writer attempt fails (`MFCreateSinkWriterFromMediaSink` on the fragmented container, `MFCreateSinkWriterFromURL` on the plain one; the message names which), the helper logs the registered H.264 video encoder MFT count (via `MFTEnumEx`), the registered AAC encoder count when audio was requested, and the hex HRESULT. If no H.264 encoder is registered, it additionally emits the four-bullet actionable error (missing Media Feature Pack / GPU driver registration / empty `HKLM:\SOFTWARE\Microsoft\Windows Media Foundation\Transforms` / reboot). If an H.264 encoder IS registered but the sink writer still failed, it logs a hint pointing at invalid output path, missing MP4 mux, or GPU driver incompatibility. There is still no fail-fast pre-flight gate because `MFTEnumEx` and the sink writer can disagree about which H.264 encoders are available in non-interactive / Session 0 contexts.
 

electron/native/wgc-capture/src/main.cpp

@@ -246,22 +246,38 @@ void reportCaptureAdapters(ID3D11Device* device, HMONITOR targetMonitor) {
     std::string monitorAdapterLuid;
     bool monitorAdapterFound = false;
     bool sameAdapter = false;
-    // Both loops end on FAILED(), not on DXGI_ERROR_NOT_FOUND specifically.
+    // Set when EnumOutputs says the outputs could not be looked at, rather than
+    // that there are none. The two are different answers and the event reports
+    // them differently -- see the comment on the inner loop.
+    bool enumerationUnavailable = false;
+    // The loops end on FAILED(), not on DXGI_ERROR_NOT_FOUND specifically.
     // NOT_FOUND is itself a failure code, so one test covers the normal end of
     // the enumeration and every other way it can stop -- and the other ways are
-    // what matter here. EnumOutputs returns DXGI_ERROR_NOT_CURRENTLY_AVAILABLE
-    // to a process in session 0, and neither call fills its out-pointer when it
-    // fails. Testing only for NOT_FOUND left a null ComPtr to be dereferenced on
-    // the next line, which would take down a recording from inside the one
-    // function in this file that promises never to.
+    // what matter here: neither call fills its out-pointer when it fails, so
+    // testing only for NOT_FOUND left a null ComPtr to be dereferenced on the
+    // next line, taking down a recording from inside the one function in this
+    // file that promises never to.
     for (UINT adapterIndex = 0;; ++adapterIndex) {
         Microsoft::WRL::ComPtr<IDXGIAdapter1> adapter;
         if (FAILED(factory->EnumAdapters1(adapterIndex, &adapter)) || !adapter) {
             break;
         }
         for (UINT outputIndex = 0;; ++outputIndex) {
             Microsoft::WRL::ComPtr<IDXGIOutput> output;
-            if (FAILED(adapter->EnumOutputs(outputIndex, &output)) || !output) {
+            // NOT_CURRENTLY_AVAILABLE is the exception to the rule above, and it
+            // has to be told apart: it is what EnumOutputs answers a process in
+            // session 0, and it means the outputs could not be inspected rather
+            // than that the adapter has none. Collapsing the two would report
+            // "no adapter claims this monitor" for a machine we never got to
+            // look at -- and that is a value this diagnostic tells its readers
+            // to interpret as an active virtual display. Same class of lie as
+            // the identical descriptions this event was just fixed for.
+            const HRESULT outputHr = adapter->EnumOutputs(outputIndex, &output);
+            if (outputHr == DXGI_ERROR_NOT_CURRENTLY_AVAILABLE) {
+                enumerationUnavailable = true;
+                break;
+            }
+            if (FAILED(outputHr) || !output) {
                 break;
             }
             DXGI_OUTPUT_DESC outputDesc{};
@@ -303,12 +319,19 @@ void reportCaptureAdapters(ID3D11Device* device, HMONITOR targetMonitor) {
               << formatLuid(deviceDesc.AdapterLuid) << "\",\"monitorAdapter\":";
     if (monitorAdapterFound) {
         std::cout << "\"" << jsonEscape(wideToUtf8(monitorAdapterName)) << "\",\"monitorLuid\":\""
-                  << monitorAdapterLuid << "\",\"sameAdapter\":" << (sameAdapter ? "true" : "false");
+                  << monitorAdapterLuid << "\",\"monitorLookup\":\"ok\",\"sameAdapter\":"
+                  << (sameAdapter ? "true" : "false");
+    } else if (enumerationUnavailable) {
+        // Session 0: the outputs were never inspected. Reported as its own
+        // state so nobody reads it as a finding about the hardware.
+        std::cout << "null,\"monitorLuid\":null,\"monitorLookup\":\"unavailable\",\"sameAdapter\":null";
     } else {
-        // No output claims this monitor: it is driven by something DXGI does not
-        // enumerate, which on the machines in #252 means a virtual display
-        // adapter. Worth seeing in a report in its own right.
-        std::cout << "null,\"monitorLuid\":null,\"sameAdapter\":null";
+        // The enumeration completed and no output claims this monitor: it is
+        // driven by something DXGI does not enumerate, which on the machines in
+        // #252 would mean a virtual display adapter. Worth seeing in its own
+        // right -- but only distinguishable from the case above because that
+        // one is now labelled.
+        std::cout << "null,\"monitorLuid\":null,\"monitorLookup\":\"no-output-claims-it\",\"sameAdapter\":null";
     }
     std::cout << "}" << std::endl;
 
@@ -328,9 +351,15 @@ void reportCaptureAdapters(ID3D11Device* device, HMONITOR targetMonitor) {
         std::cerr << "[adapters] " << adapterIndex << " luid=" << formatLuid(desc.AdapterLuid)
                   << " \"" << wideToUtf8(desc.Description) << "\"";
         UINT outputCount = 0;
+        bool outputsUnavailable = false;
         for (UINT outputIndex = 0;; ++outputIndex) {
             Microsoft::WRL::ComPtr<IDXGIOutput> output;
-            if (FAILED(adapter->EnumOutputs(outputIndex, &output)) || !output) {
+            const HRESULT outputHr = adapter->EnumOutputs(outputIndex, &output);
+            if (outputHr == DXGI_ERROR_NOT_CURRENTLY_AVAILABLE) {
+                outputsUnavailable = true;
+                break;
+            }
+            if (FAILED(outputHr) || !output) {
                 break;
             }
             DXGI_OUTPUT_DESC outputDesc{};
@@ -340,7 +369,10 @@ void reportCaptureAdapters(ID3D11Device* device, HMONITOR targetMonitor) {
             }
             ++outputCount;
         }
-        if (outputCount == 0) {
+        if (outputsUnavailable) {
+            // Not the same as none: session 0 refuses the question entirely.
+            std::cerr << " outputs=unavailable";
+        } else if (outputCount == 0) {
             std::cerr << " outputs=none";
         }
         std::cerr << std::endl;