QWT-NG 4.3.6 (agent 048d2ad)

Superseded by 4.3.7 — install that instead. 4.3.6 stops the shutdown loop but leaves the
PV drivers' per-boot reboot request answered by a modal "Xen PV Storage Host Adapter needs to
restart" dialog on every AppVM start, with the xenbus_monitor service wedged behind it. Do NOT
click Yes (it reboots the qube; the demand returns next boot). 4.3.7 removes the dialog entirely.

Fixes the AppVM that shuts down a few seconds after starting

If an AppVM created from your Windows template dies shortly after start — on Windows 10 or 11 — this
release fixes it. Install into the template, let the template shut down, and AppVMs on it work.
No rebuild needed.

What was wrong. The installer sets xenbus_monitor\Parameters\AutoReboot=1 so that the install
itself can reboot silently rather than hanging on the PV drivers' modal "needs to restart to complete
installation" prompt. That value was then left at 1 in the finished template.

An AppVM's system disk is volatile — discarded at every shutdown. So the PV driver install
re-runs on every boot, asks for a reboot on every boot, and with AutoReboot=1 it silently gets one.
The guest reboots in a loop until Qubes gives up and halts the qube.

The installer now resets AutoReboot to 0 as its final act and reads the value back, so the template
ships with it off. Silent reboots still happen during the install, which is the only place they
were ever wanted.

Verified on an AppVM built from a template upgraded in place to this package: stays up (t+360 s
and beyond) with zero reboots initiated, where the same test on 4.3.4 died at t+90 s.
(Correction 2026-08-25: this originally said "zero reboot requests logged" and "a pristine
Windows image" — both wrong. The request is re-filed on every AppVM boot and surfaces as the
dialog described above, and the verification template carried an earlier QWT-NG build. See the
4.3.7 notes for the full mechanism.)

Also in this release

• Logs survive an AppVM reboot. LogDir moved to the qube's private volume. An AppVM's C: is
  volatile, so until now the log covering a boot-time failure was gone before anyone could read it.
• Stock network-setup.exe replaced by a native service reading qubesdb directly. First working
  traffic at ~13–17 s from qube start, and the mid-boot outage is gone — the old tool ran twice per
  boot and its second run deleted an address it had already configured correctly.
• PV NIC unplug latch armed before the template ships, so an AppVM completes its NIC install in
  one boot (this was 4.3.4's fix; it is real, it was simply not the cause of the shutdown loop).
• No stale network identity in the image — no DHCP lease, NetworkList profile or DHCPv6 DUID left
  over from installation, and DHCP off on the PV NIC. Qubes configures guests statically from
  qubesdb, exactly as for Linux qubes.

Install

RPM in dom0, or the ISO/tarball inside the template. Install into the template, not an AppVM, and
let the template shut down at the end.

Do not run the Qubes updater inside a Windows AppVM: finish updates in the template and let it reboot
itself, or the AppVM will retry forever against its volatile root.