Skip to content

QWT-NG 4.3.10 (agent ab36aef)

Choose a tag to compare

View all tags
@arkenoi arkenoi released this 27 Aug 13:48
· 509 commits to main since this release
v4.3.10-agentab36aef
c47c2a0

The black-window release: the log now diagnoses it, and normal logs shrink ~40×

The persistent black-window report (forum 42717, posts 79/96 — thank you GWeck for the log)
turned out not to be diagnosable from any log the agent could produce: the per-window capture
engine (PrintWindow-based) logged nothing. A capture that fails five times and dies, and a
capture that "succeeds" but renders black (DirectComposition content the API cannot reach), both
looked exactly like healthy operation while dom0 showed a black window. We could not reproduce
the black window on 25H2 — plain, with OpenShell, or as an AppVM; Explorer renders correctly in
all three here — so this release makes the field log answer the question:

  • WCBLACK — warns when captures succeed but return ≥99 % near-black content, three in a
    row (validated live against a deliberately all-black window; no false positives on normal
    windows, real windows measure ≤4 % near-black).
  • WCDEAD — warns when a capture channel dies (5 consecutive failures, with the last error
    code). Previously this latch was silent forever.
  • A failed initial capture ("window starts black until the first successful capture") is now a
    visible warning instead of a debug line.

If you see the black window: upgrade to 4.3.10, reproduce, and post the gui-agent log — it
will now say explicitly which of the two failure modes your machine hits (or neither).

Logs are normal-user-sized now

A 15-minute log used to weigh 2.3 MB — 91 % of it per-frame performance telemetry, 7 % per-paint
tooltip traces. Both are now off by default and the log carries events, not the firehose
(same session ≈ 50 KB). Full diagnostics are one dom0 command away:

qvm-features <qube> service.gui-agent-debug 1

That single switch (read at agent start; unset it to go quiet again) enables everything a
diagnosis needs: per-frame QGAPERF telemetry, protocol/paint traces, and Debug-level logging.
Guest-local registry switches (PerfLog/PerfEveryN/ProtoTrace under the gui-agent key)
still exist for fine-grained control; the dom0 feature wins over them. The log itself tells
you this: it prints one QGAPERF off (enable ALL diagnostics from dom0: …) line.

Installer: template priming can no longer be skipped by a bad read

The netvm-free PV NIC priming gate read the qube's class from qubesdb once; an intermittent
misread made the installer skip priming on a real template — which is exactly the AppVM
restart-loop the priming exists to prevent. The read is now retried, and an unreadable class
primes anyway (fail closed — priming is transactional and harmless on non-templates).

Also new

  • guest/pwdiag.ps1 — a one-command in-guest diagnostic: lists every visible window and
    test-captures each the way the agent does (identity + black-ratio + PNG evidence).

Install

RPM in dom0, or the ISO/tarball inside the template; let the template shut down at the end.
In-place upgrade from any 4.3.x. Hand-created qube? qvm-features <qube> vmexec 1 and
qvm-prefs <qube> qrexec_timeout 1800 in dom0 (on the template; AppVMs inherit) — see the
README.

Assets 6
Loading