diff --git a/.github/workflows/package.yml b/.github/workflows/package.yml
index fd0ffe18..d8cb9e1a 100644
--- a/.github/workflows/package.yml
+++ b/.github/workflows/package.yml
@@ -575,27 +575,11 @@ jobs:
     # No fork guard here: this workflow only triggers on tag pushes and
     # workflow_dispatch, both of which need write access to this repo.
     runs-on: [self-hosted, linux, x64, lab-2204]
-    # This runner sets no locale, and two tools in this job read one. icotool
-    # says so outright - "icotool: cannot set locale: No such file or
-    # directory" - and WiX then refuses a plainly relative Directory/@Name:
-    #
-    #   meshbench.wxs(135) : error WIX0389: The Directory/@Name attribute's
-    #   value, 'MeshBench', is not a relative path.
-    #
-    # 'MeshBench' is relative by any reading, so that is WiX's own path
-    # handling and not the authoring. It is a known shape on Linux
-    # (wixtoolset/issues#7154, Ubuntu 22.04, closed "not planned") and it turns
-    # up in minimal environments - that issue, and the Docker SDK images in the
-    # discussion beside it - which is what a runner with no locale is.
-    #
-    # C.UTF-8 rather than a generated en_GB: glibc has carried it built in
-    # since 2.35, which is exactly this runner's floor, so nothing has to be
-    # installed for it to exist.
-    #
-    # v0.0.5's installer was built by wixl, which had no such trouble. WiX
-    # arrived with the dialogs, wixl building none, and the Windows job has
-    # failed before reaching the MSI on every run since - so this is the first
-    # time WiX has actually run here.
+    # This runner sets no locale, and icotool reads one: "icotool: cannot set
+    # locale: No such file or directory". C.UTF-8, which glibc has carried
+    # built in since 2.35 - this runner's floor - so nothing is installed for
+    # it. (WiX met the same missing locale here before it was moved to the
+    # windows-msi job, which is where it can actually build.)
     env:
       LANG: C.UTF-8
       LC_ALL: C.UTF-8
@@ -615,19 +599,16 @@ jobs:
       - name: Dependencies
         run: |
           sudo apt-get update
-          # msitools is msiinfo and msibuild: one reads the built package for
-          # verify-msi.sh and the other puts back the single row WiX will not
-          # author. wixl used to build the installer and no longer does - it
-          # builds no dialogs, and the installer was asked for two.
           # icoutils is for the one file Windows wants that the repository does
           # not carry: an .ico holding every size, built from the committed
           # PNGs the same way macos-app.sh builds the .icns. python3-pil
-          # composes the two dialog bitmaps from the same committed artwork -
-          # ImageMagick would have done, but 22.04 carries version 6, whose
-          # command is `convert` and not `magick`, and a build that works where
-          # it was written and fails where it runs is the worst kind.
+          # composes the installer's two dialog bitmaps from the same committed
+          # artwork - ImageMagick would have done, but 22.04 carries version 6,
+          # whose command is `convert` and not `magick`. The installer itself
+          # is built in the windows-msi job and read back in
+          # windows-msi-verify, which installs msitools for that.
           sudo apt-get install -y --no-install-recommends \
-            gcc-mingw-w64-x86-64 zip msitools icoutils python3-pil
+            gcc-mingw-w64-x86-64 zip icoutils python3-pil
 
 
       - name: Build
@@ -658,6 +639,7 @@ jobs:
               { echo "::error::version '$VERSION' is not X.Y.Z or X.Y.Z-dev.N"; exit 1; } ;;
           esac
           go run ./tools/licgen -text dist/meshbench/LICENCES
+          mkdir -p dist/msi
           GOOS=windows GOARCH=amd64 CGO_ENABLED=1 CC=x86_64-w64-mingw32-gcc \
           go build -trimpath \
             -ldflags "-H windowsgui -X gioui.org/app.ID=io.github.meshbench.meshbench \
@@ -719,8 +701,11 @@ jobs:
             https://github.com/googlefonts/noto-emoji/raw/v2.051/fonts/NotoColorEmoji.ttf
           echo compact > dist/meshbench/VARIANT
           (cd dist && zip -qr meshbench-windows-x86_64-compact.zip meshbench)
-          packaging/windows-msi.sh dist/meshbench "$VERSION" \
-            "dist/meshbench-windows-x86_64-compact.msi"
+          # The installer's half of the compact pair: the tree as it stands,
+          # and what the WiX build needs from this side. The .msi itself is
+          # built on Windows by the windows-msi job (#508).
+          cp -a dist/meshbench dist/msi/stage-compact
+          packaging/windows-msi.sh dist/msi/stage-compact "$VERSION" dist/msi/extra-compact
 
           # Now the emulators, making the same tree the bundled variant.
           . packaging/emulator-pins.env
@@ -774,25 +759,18 @@ jobs:
           ls -la dist/*.zip
           file dist/meshbench/meshbench.exe
 
-      - name: The installer
+      - name: The installer's half from here
         # An MSI as well as the zip rather than instead of it. The zip is a
         # complete build and stays the download for a memory stick, a build
         # agent, or anyone who wants no installer.
         #
-        # What the installer adds is a deliberate location. This bundle finds
-        # the emulators and the chip model beside meshbench.exe, so a user who
-        # unpacks the zip into Downloads and then moves the one executable
-        # somewhere tidy - which is the natural thing to do with a single
-        # executable - has broken emulation and will not be told why. The
-        # installer puts the whole directory somewhere on purpose, and brings
-        # an entry in Apps and Features, an uninstall, and an upgrade that
-        # replaces the previous version instead of accumulating beside it.
-        #
-        # Still no Windows runner: WiX reads packaging/meshbench.wxs and
-        # writes the .msi here, beside the mingw cross-build that made the
-        # .exe. The script checks the tables of what it built before it
-        # returns, because an installer that is wrong about upgrading looks
-        # exactly like one that is right until somebody installs two versions.
+        # What the installer adds is a deliberate location, an entry in Apps
+        # and Features, an uninstall, an upgrade that replaces the previous
+        # version - and, since #508, a wizard that asks where to go and says
+        # when it has finished. That needs the WiX toolset, which builds an MSI
+        # only on Windows, so this step prepares and the windows-msi job
+        # builds: the icon and the dialog bitmaps need icotool and Pillow,
+        # which are here, and the database needs msi.dll, which is there.
         run: |
           set -e
           VERSION="${{ inputs.version }}"
@@ -802,9 +780,18 @@ jobs:
               *)  VERSION="0.0.0-dev-$(git rev-parse --short HEAD)" ;;
             esac
           fi
-          packaging/windows-msi.sh dist/meshbench "$VERSION" \
-            "dist/meshbench-windows-x86_64-bundled.msi"
-          ls -la dist/*.msi
+          cp -a dist/meshbench dist/msi/stage-bundled
+          packaging/windows-msi.sh dist/msi/stage-bundled "$VERSION" dist/msi/extra-bundled
+          ls dist/msi
+
+      # Both staged trees and what goes with them, for the Windows runner. Not
+      # a release asset: the release takes the MSIs once verify-msi.sh has read
+      # them back.
+      - uses: actions/upload-artifact@v7
+        with:
+          name: msi-stage
+          retention-days: 1
+          path: dist/msi
 
       - uses: actions/upload-artifact@v7
         if: inputs.release || startsWith(github.ref, 'refs/tags/v')
@@ -812,9 +799,84 @@ jobs:
           name: meshbench-windows
           # As the Linux upload above.
           retention-days: ${{ inputs.release && 1 || 3 }}
+          path: dist/*.zip
+
+  windows-msi:
+    timeout-minutes: 30
+    # The installer, built where WiX can build one. WiX writes the MSI
+    # database through Windows' own msi.dll and refuses everywhere else - on
+    # Linux every Directory/@Name is "not a relative path", and with the
+    # names removed it dies on "Unable to load shared library 'msi.dll'"
+    # (#508). wixl runs on Linux and builds no dialogs, so a double-clicked
+    # installer showed a progress bar and closed without a word.
+    #
+    # windows-latest is a hosted runner, which this public repository pays
+    # nothing for. Only the WiX build runs here; staging is on Linux above,
+    # and the check is on Linux below, where msitools reads the tables.
+    needs: windows
+    if: inputs.windows || startsWith(github.ref, 'refs/tags/v')
+    runs-on: windows-latest
+    steps:
+      - uses: actions/checkout@v7
+      - uses: actions/download-artifact@v8
+        with: { name: msi-stage, path: msi }
+      - name: WiX
+        shell: pwsh
+        run: |
+          dotnet tool install --global wix --version 5.0.2
+          wix extension add -g WixToolset.UI.wixext/5.0.2
+          wix --version
+      - name: Build both installers
+        shell: pwsh
+        run: |
+          New-Item -ItemType Directory -Force dist | Out-Null
+          packaging/windows-msi.ps1 -Stage msi/stage-compact -Extra msi/extra-compact `
+            -Out dist/meshbench-windows-x86_64-compact.msi
+          packaging/windows-msi.ps1 -Stage msi/stage-bundled -Extra msi/extra-bundled `
+            -Out dist/meshbench-windows-x86_64-bundled.msi
+      - uses: actions/upload-artifact@v7
+        with:
+          name: msi-unverified
+          retention-days: 1
           path: |
-            dist/*.zip
             dist/*.msi
+            dist/*.msi.files
+
+  windows-msi-verify:
+    timeout-minutes: 15
+    # What Windows will act on, read back out of each database rather than out
+    # of the source: the upgrade code and version, the file count, ALLUSERS,
+    # the dialogs, and where an upgrade goes. Only what passes is offered to
+    # the release, as meshbench-windows-msi.
+    needs: windows-msi
+    if: inputs.windows || startsWith(github.ref, 'refs/tags/v')
+    runs-on: [self-hosted, linux, x64, lab-2204]
+    steps:
+      - uses: actions/checkout@v7
+      - uses: actions/download-artifact@v8
+        with: { name: msi-stage, path: msi }
+      - uses: actions/download-artifact@v8
+        with: { name: msi-unverified, path: dist }
+      - name: Dependencies
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y --no-install-recommends msitools
+      - name: Read both back
+        run: |
+          set -e
+          for v in compact bundled; do
+            . "msi/extra-$v/msi.env"
+            msi="dist/meshbench-windows-x86_64-$v.msi"
+            # The count of what WiX harvested, taken on the Windows runner.
+            files=$(cat "$msi.files")
+            packaging/verify-msi.sh "$msi" "$MSIVERSION" "$UPGRADE" "$((files + 1))"
+          done
+      - uses: actions/upload-artifact@v7
+        if: inputs.release || startsWith(github.ref, 'refs/tags/v')
+        with:
+          name: meshbench-windows-msi
+          retention-days: ${{ inputs.release && 1 || 3 }}
+          path: dist/*.msi
 
   release:
     timeout-minutes: 20
@@ -840,7 +902,10 @@ jobs:
     if: >-
       always() && (inputs.release ||
       (github.event_name == 'push' && startsWith(github.ref, 'refs/tags/v')))
-    needs: [linux, macos, windows]
+    # windows-msi-verify, not just windows: the MSIs are built and read back
+    # after the windows job finishes, so without it this job would start
+    # before meshbench-windows-msi exists and refuse a zip with no .msi.
+    needs: [linux, macos, windows, windows-msi-verify]
     # Hosted, unlike every job above it, because this one builds nothing. It
     # downloads what they built, checks it, and hands it to gh - so the glibc
     # floor the lab-2204 label exists to pin does not apply here at all. That
@@ -869,8 +934,11 @@ jobs:
       tag: ${{ steps.publish.outputs.tag }}
     steps:
       - uses: actions/checkout@v7
+      # The release artefacts only: the MSI stage and the unverified MSIs are
+      # working files between jobs, and only meshbench-windows-msi has been
+      # read back.
       - uses: actions/download-artifact@v8
-        with: { path: incoming }
+        with: { path: incoming, pattern: 'meshbench-*' }
 
       # This job is the one that still needs gh: creating and uploading a
       # release is a write, and reimplementing that over curl would be a worse
@@ -939,7 +1007,7 @@ jobs:
           if ls dist/*windows*.zip >/dev/null 2>&1 && ! ls dist/*windows*.msi >/dev/null 2>&1; then
             echo "::error::a Windows zip was built and no .msi came with it;"\
                  "the installer is packaging/meshbench.wxs, built by the"\
-                 "windows job's installer step"
+                 "windows-msi job and read back by windows-msi-verify"
             exit 1
           fi
           # The project's own licence is checked by the linux job, which has
diff --git a/CHANGELOG.md b/CHANGELOG.md
index a38e02b4..bb79a90b 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -34,6 +34,12 @@ had changed in them - which is the gap this file exists to close.
 
 ### Changed
 
+- **The Windows installer asks where to go and says when it has finished.**
+  It is built by the WiX toolset again, now on a Windows runner, which is the
+  only place WiX can build one: a Destination Folder page with a Change button,
+  a completion page, the brand on both, and the install location in Apps and
+  Features. Staging stays on Linux, and the tables are read back there before
+  the release takes the installers.
 - **`sim.state` says when the wall clock decided something.** `reproducible`
   is false, with the reason, once a node-writing verb ran at a playing clock
   without `at_ms`, a client outside the simulation wrote to a served
diff --git a/docs/install.md b/docs/install.md
index 0dfd39ab..cb5b8c4a 100644
--- a/docs/install.md
+++ b/docs/install.md
@@ -94,21 +94,14 @@ Intel Macs are not built yet. Ask if you need one.
 
 Two downloads, and either is a complete build.
 
-`meshbench-windows-x86_64-bundled.msi` is the installer. Double-click it and it
-installs to `C:\Program Files\MeshBench`, adds a Start menu entry, and appears
-in Apps and Features with an uninstall. Installing a newer one replaces the
-installation rather than putting a second copy beside it. The uninstall removes
-what it installed and nothing else: your fixtures, cached firmware, terrain
-tiles and settings live under your profile and are left alone.
-
-It asks nothing while it runs. The toolset that builds it cannot draw dialogs,
-and the one that can only runs on Windows, which this pipeline has none of. To
-install somewhere else, or per-user, pass it on the command line:
-
-```
-msiexec /i meshbench-windows-x86_64-bundled.msi INSTALLDIR="D:\Tools\MeshBench"
-msiexec /i meshbench-windows-x86_64-bundled.msi MSIINSTALLPERUSER=1
-```
+`meshbench-windows-x86_64-bundled.msi` is the installer. Double-click it and it asks
+where to go — `C:\Program Files\MeshBench` unless you browse somewhere else —
+adds a Start menu entry, and appears in Apps and Features with an uninstall and
+the location it used. Installing a newer one replaces the installation rather
+than putting a second copy beside it, and keeps the directory you chose. The
+uninstall removes what it installed and nothing else: your fixtures, cached
+firmware, terrain tiles and settings live under your profile and are left
+alone.
 
 Everything the wizard offers can also be a switch, which is what you want for
 an unattended install, and there are two it does not offer. From a Command
diff --git a/packaging/meshbench.wxs b/packaging/meshbench.wxs
index 5838c925..bcd4f322 100644
--- a/packaging/meshbench.wxs
+++ b/packaging/meshbench.wxs
@@ -1,56 +1,44 @@
 <?xml version="1.0" encoding="utf-8"?>
 <!--
-  The Windows installer, built on Linux by wixl. There is no Windows runner in
-  this pipeline and this file does not need one: wixl reads this source and
-  writes the .msi, and the same cross-build that produces meshbench.exe
-  produces the installer around it.
+  The Windows installer, built by the WiX toolset. There is no Windows runner
+  in this pipeline and this file does not need one: WiX 5 is a .NET tool and
+  runs on Linux, so the same cross-build that produces meshbench.exe produces
+  the installer around it.
+
+  It was built by wixl until the dialogs were wanted. wixl builds none - see
+  GNOME/msitools#3 - so the installer could not say it had finished and could
+  not offer a folder to install into, and both were asked for. Everything else
+  here is the same set of decisions, carried across: what goes where, what it
+  is called, how it upgrades, and the shortcuts.
 
   What this exists for is the layout rather than the binary. The bundle carries
-  QEMU, Renode and the SX1262 model, and finds them beside meshbench.exe, so a
+  QEMU, Renode and radioserver.exe and finds them beside meshbench.exe, so a
   user who unpacks the zip and then moves the one executable somewhere tidy has
   silently broken emulation with nothing to tell them so. An installer puts the
   whole directory somewhere deliberate and keeps it together.
 
-  Built by wixl rather than the WiX toolset, deliberately. WiX was tried for
-  the sake of the install-folder dialogs, which wixl cannot build - see
-  GNOME/msitools#3 - and it cannot be used here at all: it needs Windows'
-  msi.dll to write the database, so on Linux it gets as far as refusing every
-  Directory/@Name as "not a relative path" and would fail on msi.dll even if
-  that were fixed. Its own first line of output says it only supports Windows.
-  Building the installer on a Windows runner is what the dialogs would cost,
-  and that is a change to the shape of the pipeline rather than to this file.
-
-  Everything under the install directory is harvested by wixl-heat into
-  ComponentGroup "Bundle", so this file carries only what a harvest cannot
-  know: where it goes, what it is called, how it upgrades, and the shortcuts.
-
-  Three variables come from packaging/windows-msi.sh:
+  Two variables come from packaging/windows-msi.sh:
     ProductCode  the GUID for this exact version, derived from it
     Version      X.Y.Z, which is what Apps and Features shows
-    Extra        the two files that come from this repository rather than from
-                 the staged bundle: the icon and the note below
+  and two paths, Stage (the assembled bundle) and Extra (the icon and the note,
+  which come from this repository rather than from the bundle).
 -->
-<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
-  <Product Id="$(var.ProductCode)"
-           Name="MeshBench"
-           Language="1033"
-           Version="$(var.Version)"
+<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs"
+     xmlns:ui="http://wixtoolset.org/schemas/v4/wxs/ui">
+  <Package Name="MeshBench"
            Manufacturer="MeshBench"
-           UpgradeCode="6f2a1c84-7f3b-4c9e-9a6d-0d8f5b1e2c30">
+           Version="$(var.Version)"
+           ProductCode="$(var.ProductCode)"
+           UpgradeCode="6f2a1c84-7f3b-4c9e-9a6d-0d8f5b1e2c30"
+           Language="1033"
+           Codepage="1252"
+           InstallerVersion="500"
+           Compressed="yes">
 
-    <!--
-      InstallerVersion 500 is Windows Installer 5.0, which is Windows 7 and
-      later, and it is what makes one package able to install per-machine or
-      per-user. Below that, ALLUSERS=2 is not honoured and the package would
-      have to pick one for everybody.
-    -->
-    <Package InstallerVersion="500"
-             Compressed="yes"
-             Manufacturer="MeshBench"
-             Description="MeshBench $(var.Version)"
-             Comments="Plan and test MeshCore LoRa networks against real firmware. GPL-3.0-or-later."/>
+    <SummaryInformation Description="MeshBench $(var.Version)"
+                        Manufacturer="MeshBench"/>
 
-    <Media Id="1" Cabinet="meshbench.cab" EmbedCab="yes"/>
+    <MediaTemplate EmbedCab="yes"/>
 
     <!--
       Upgrade in place, which is the thing an installer gets wrong by
@@ -60,72 +48,105 @@
       fixed for the life of the product and identifies "MeshBench" across every
       version. ProductCode is derived from the version by the build script, so
       two builds of the same version are the same product and a reinstall is a
-      reinstall rather than a second arrival. And the range below claims every
-      version below this one, so installing 0.3.0 over 0.2.0 finds it, removes
-      it, and installs into the same place.
+      reinstall rather than a second arrival. And MajorUpgrade claims every
+      older version, so installing 0.3.0 over 0.2.0 finds it, removes it, and
+      installs into the same place.
 
-      The second range only detects: a downgrade is refused by the condition
-      further down rather than allowed to write older files over newer ones.
+      Scheduled after InstallValidate, so the old version is gone before the
+      new files are written. Scheduled late instead, the two copies coexist for
+      part of the transaction and the old one's uninstall takes the new one's
+      files with it where a name is shared - which is most of this bundle.
+
+      A downgrade is refused rather than allowed to write older files over
+      newer ones.
     -->
-    <Upgrade Id="6f2a1c84-7f3b-4c9e-9a6d-0d8f5b1e2c30">
-      <UpgradeVersion Minimum="0.0.0" IncludeMinimum="yes"
-                      Maximum="$(var.Version)" IncludeMaximum="no"
-                      Property="OLDERVERSIONBEINGUPGRADED"/>
-      <UpgradeVersion Minimum="$(var.Version)" IncludeMinimum="yes"
-                      OnlyDetect="yes"
-                      Property="NEWERVERSIONDETECTED"/>
-    </Upgrade>
+    <MajorUpgrade Schedule="afterInstallValidate"
+                  AllowDowngrades="no"
+                  DowngradeErrorMessage="A newer MeshBench is already installed. Remove it first if you meant to go back to this one."/>
 
     <!--
-      After InstallValidate, so the old version is gone before the new files
-      are written. Scheduled late instead, the two copies coexist for part of
-      the transaction and the old one's uninstall takes the new one's files
-      with it where a name is shared - which is most of this bundle.
+      There is no ARPNOMODIFY here any more, and its absence is deliberate.
+      The wixl build set it, with the reason written beside it: "a Modify
+      button would open an installer with nothing in it to change". That is no
+      longer true - running the .msi again now offers Repair and Remove - so
+      the property is left to the toolset, which sets NoModify itself because
+      nothing in this package is independently selectable.
+      
+      Uninstalling needs nothing authored. Apps and Features carries the entry
+      and its Uninstall, running the package again offers Remove, and
+      msiexec /x takes the product code. A Start menu "Uninstall MeshBench"
+      shortcut is deliberately not added: Microsoft's own guidance is against
+      it, and Windows 10 and 11 hide them.
     -->
-    <InstallExecuteSequence>
-      <RemoveExistingProducts After="InstallValidate"/>
-    </InstallExecuteSequence>
-
-    <Condition Message="A newer MeshBench is already installed. Remove it first if you meant to go back to this one.">
-      NOT NEWERVERSIONDETECTED OR Installed
-    </Condition>
+    <Icon Id="meshbench.ico" SourceFile="$(var.Extra)/meshbench.ico"/>
+    <Property Id="ARPPRODUCTICON" Value="meshbench.ico"/>
+    <Property Id="ARPURLINFOABOUT" Value="https://github.com/MeshBench/meshbench"/>
 
     <!--
-      2 rather than 1: the package decides per install rather than for
-      everybody. Left alone it installs per-machine into Program Files and asks
-      for elevation; with MSIINSTALLPERUSER=1 it installs under the user's own
-      profile and asks for nothing.
+      A public property set on the msiexec command line does not survive the
+      elevation a per-machine install goes through unless it is secured, and
+      these two are the ones this package offers. Authored here rather than
+      patched in afterwards, which is what the wixl build had to do: it wrote
+      the row itself for the upgrade properties and refused a second one.
     -->
-    <Property Id="ALLUSERS" Value="2"/>
-
     <!--
-      SecureCustomProperties is not authored here even though INSTALLDIR needs
-      to be in it - a property set on the msiexec command line is dropped when
-      the install elevates unless it is named there, so a chosen location would
-      otherwise work for a per-user install and be ignored for a per-machine
-      one, which is the worse half of not working. wixl writes that row itself
-      to carry the two upgrade properties below, and a second row with the same
-      key fails the build. packaging/windows-msi.sh appends to the row wixl
-      wrote, and packaging/verify-msi.sh checks the result.
+      ALLUSERS is not set here and cannot be. This package has always been
+      dual-purpose - ALLUSERS=2, per-machine by default and per-user with
+      MSIINSTALLPERUSER=1, which is what lets somebody without administrator
+      rights install into their own profile - and WiX 4 removed the option,
+      leaving Scope with only perMachine and perUser. It emits ALLUSERS=1
+      itself, so authoring a second row here is a duplicate-symbol error.
+      windows-msi.sh puts the 2 back afterwards, and verify-msi.sh checks it,
+      because losing a documented install route to a schema change would be a
+      regression nobody asked for.
     -->
-    <Property Id="ARPPRODUCTICON" Value="meshbench.ico"/>
-    <Property Id="ARPURLINFOABOUT" Value="https://github.com/MeshBench/meshbench"/>
+    <Property Id="MSIINSTALLPERUSER" Secure="yes"/>
+
     <!--
-      No Modify button. wixl builds no dialogs, so the button would open an
-      installer with nothing in it to change; the desktop shortcut is chosen on
-      the command line at install time instead, as below.
+      Where the last install went, so an upgrade stays there.
+      
+      Without this an upgrade installs into the default and the previous
+      directory is removed under it: somebody who chose D:\Tools\MeshBench in
+      the dialog would find the next version in Program Files and their choice
+      silently undone. Measured before it was added - 0.0.6 installed to
+      C:\MBTrial came back as 0.0.7 in Program Files.
+      
+      A command line still wins: a property set there is not overwritten by a
+      search, so INSTALLDIR=... on an upgrade moves it deliberately.
+
+      HKLM only, because RegistrySearch takes a real hive and not HKMU. A
+      per-machine install - the default, and the one with a folder dialog in
+      front of it - is therefore remembered; a per-user install writes its path
+      to HKCU and is not read back, so an upgrade of one returns to the
+      default. Worth doing properly if anybody installs per-user twice.
     -->
-    <Property Id="ARPNOMODIFY" Value="1"/>
+    <Property Id="INSTALLDIR" Secure="yes">
+      <RegistrySearch Id="PreviousInstallDir" Root="HKLM"
+                      Key="Software\MeshBench\MeshBench" Name="InstallDir"
+                      Type="raw"/>
+    </Property>
 
-    <Icon Id="meshbench.ico" SourceFile="$(var.Extra)/meshbench.ico"/>
+    <!--
+      Where it goes. Program Files for a per-machine install; the same
+      directory under the user's own profile when MSIINSTALLPERUSER=1, which
+      the ALLUSERS note above explains.
+    -->
+    <StandardDirectory Id="ProgramFiles6432Folder">
+      <Directory Id="INSTALLDIR" Name="MeshBench"/>
+    </StandardDirectory>
 
-    <Directory Id="TARGETDIR" Name="SourceDir">
-      <Directory Id="ProgramFiles64Folder">
-        <Directory Id="INSTALLDIR" Name="MeshBench"/>
-      </Directory>
-      <Directory Id="ProgramMenuFolder"/>
-      <Directory Id="DesktopFolder"/>
-    </Directory>
+    <!--
+      Everything in the assembled bundle, harvested by the compiler rather than
+      by a separate tool. wixl-heat named each directory with a fresh random id
+      on every run and wixl derived each component's GUID from that, so the
+      same tree built twice came out as two different installers and the build
+      script had to renumber the ids to get a reproducible package back. Files
+      needs none of that: it walks the tree itself, in its own order, every
+      time.
+    -->
+    <ComponentGroup Id="Bundle" Directory="INSTALLDIR">
+      <Files Include="$(var.Stage)\**"/>
+    </ComponentGroup>
 
     <!--
       The one file the zip does not carry, and the only difference between the
@@ -135,61 +156,79 @@
       installed build is updated by running the newer installer, and a build
       unpacked from a zip is not, so the two cannot be told the same thing.
     -->
-    <DirectoryRef Id="INSTALLDIR">
-      <Component Id="InstallNote" Guid="3d6b8f47-1e29-4a05-b8c3-92f7d4e6a018" Win64="yes">
+    <ComponentGroup Id="InstallNote" Directory="INSTALLDIR">
+      <Component Id="InstallNote" Guid="3d6b8f47-1e29-4a05-b8c3-92f7d4e6a018" Bitness="always64">
         <File Id="installed_by_msi.txt" Name="installed-by-msi.txt"
               Source="$(var.Extra)/installed-by-msi.txt" KeyPath="yes"/>
+        <!-- Read back by the search above, so an upgrade stays where it was put. -->
+        <RegistryValue Root="HKMU" Key="Software\MeshBench\MeshBench"
+                       Name="InstallDir" Type="string" Value="[INSTALLDIR]"/>
       </Component>
-    </DirectoryRef>
+    </ComponentGroup>
 
     <!--
       A shortcut cannot be a component's own key path, so a registry value
-      stands in for one. HKCU rather than HKMU, which would be the better
-      answer and follow the install into whichever hive it went to: wixl writes
-      its own enumeration into the Registry table's Root column rather than the
-      value Windows Installer defines, and HKMU comes out as 4, which is not a
-      root at all. HKCU comes out as 1, which is.
+      stands in for one. HKMU, which follows the install into whichever hive it
+      went to - the wixl build had to use HKCU because it wrote its own
+      enumeration into the Registry table's Root column and HKMU came out as 4,
+      which is not a root at all. A real toolset writes the value Windows
+      Installer defines, so the better answer is available again.
+
+      Both shortcuts pass "workbench". Nothing requires it any more - a bare
+      meshbench.exe opens the workbench since #503 - but naming it is the same
+      thing the .desktop file and the macOS wrapper do, and a shortcut that
+      states what it runs is one less thing to work out from the outside.
     -->
-    <DirectoryRef Id="ProgramMenuFolder">
-      <Component Id="StartMenuShortcut" Guid="b41d6e02-3a55-4f18-9c27-7e4a0b6d9155" Win64="yes">
+    <StandardDirectory Id="ProgramMenuFolder">
+      <Component Id="StartMenuShortcut" Guid="b41d6e02-3a55-4f18-9c27-7e4a0b6d9155" Bitness="always64">
         <Shortcut Id="StartMenuMeshBench"
                   Name="MeshBench"
                   Description="Plan and test MeshCore LoRa networks against real firmware"
                   Target="[INSTALLDIR]meshbench.exe"
+                  Arguments="workbench"
                   WorkingDirectory="INSTALLDIR"
                   Icon="meshbench.ico"/>
-        <RegistryValue Root="HKCU" Key="Software\MeshBench\MeshBench"
+        <RegistryValue Root="HKMU" Key="Software\MeshBench\MeshBench"
                        Name="StartMenuShortcut" Type="integer" Value="1" KeyPath="yes"/>
       </Component>
-    </DirectoryRef>
+    </StandardDirectory>
 
     <!--
       Off unless asked for. An installer that plants a desktop icon nobody
       asked for is the behaviour people complain about, so this is a feature at
       level 0 - present in the package, not installed unless the install names
-      it. It is a feature rather than a component with a condition on it
-      because wixl does not build conditions on components, and this way the
-      switch is one Windows Installer already understands:
+      it, either on the command line or by ticking it in the dialog:
 
         msiexec /i meshbench-<version>-windows-x86_64.msi ADDLOCAL=Complete,DesktopShortcut
     -->
-    <DirectoryRef Id="DesktopFolder">
-      <Component Id="DesktopShortcutComponent" Guid="0a7c3d91-58e6-42b7-8d10-c3f9a2e47b68" Win64="yes">
+    <StandardDirectory Id="DesktopFolder">
+      <Component Id="DesktopShortcutComponent" Guid="0a7c3d91-58e6-42b7-8d10-c3f9a2e47b68" Bitness="always64">
         <Shortcut Id="DesktopMeshBench"
                   Name="MeshBench"
                   Description="Plan and test MeshCore LoRa networks against real firmware"
                   Target="[INSTALLDIR]meshbench.exe"
+                  Arguments="workbench"
                   WorkingDirectory="INSTALLDIR"
                   Icon="meshbench.ico"/>
-        <RegistryValue Root="HKCU" Key="Software\MeshBench\MeshBench"
+        <RegistryValue Root="HKMU" Key="Software\MeshBench\MeshBench"
                        Name="DesktopShortcut" Type="integer" Value="1" KeyPath="yes"/>
       </Component>
-    </DirectoryRef>
+    </StandardDirectory>
+
+    <!--
+      Apps and Features shows an "Install location", and ours was blank:
+      nothing set ARPINSTALLLOCATION, so Windows knew where it had put the
+      files and told nobody. It cannot be a plain Property - [INSTALLDIR] is
+      not resolved until the install is costed - so it is set once costing has
+      settled.
+    -->
+    <SetProperty Id="ARPINSTALLLOCATION" Value="[INSTALLDIR]"
+                 After="CostFinalize" Sequence="execute"/>
 
     <Feature Id="Complete" Title="MeshBench" Level="1" Display="expand"
              Description="MeshBench, the emulators, the radio model and the shipped fixtures">
       <ComponentGroupRef Id="Bundle"/>
-      <ComponentRef Id="InstallNote"/>
+      <ComponentGroupRef Id="InstallNote"/>
       <ComponentRef Id="StartMenuShortcut"/>
 
       <Feature Id="DesktopShortcut" Title="Desktop shortcut" Level="0"
@@ -197,5 +236,32 @@
         <ComponentRef Id="DesktopShortcutComponent"/>
       </Feature>
     </Feature>
-  </Product>
+
+    <!--
+      The dialogs this migration was for: a folder to install into, and a page
+      at the end saying it finished. WixUI_InstallDir is the stock set for
+      exactly that pair.
+
+      The licence page is skipped. WixUI_InstallDir puts one between the
+      welcome and the folder, and MeshBench is GPL-3.0-or-later: the GPL is not
+      a licence anybody has to accept before running the program, and asking
+      them to tick that they have would be stating something untrue about it.
+      The licence travels in the bundle as LICENCES, which is where it belongs.
+    -->
+    <ui:WixUI Id="WixUI_InstallDir" InstallDirectory="INSTALLDIR"/>
+    <UI>
+      <Publish Dialog="WelcomeDlg" Control="Next" Event="NewDialog" Value="InstallDirDlg" Order="2"/>
+      <Publish Dialog="InstallDirDlg" Control="Back" Event="NewDialog" Value="WelcomeDlg" Order="2"/>
+    </UI>
+
+    <!--
+      And the brand on it. The dialog bitmap fills the left of the welcome and
+      the finished pages, which are the first and last things anybody sees, and
+      the banner runs along the top of everything between them. Both are built
+      from the committed artwork by windows-msi.sh, because WiX takes bitmaps
+      and the repository keeps PNGs.
+    -->
+    <WixVariable Id="WixUIDialogBmp" Value="$(var.Extra)/dialog.bmp"/>
+    <WixVariable Id="WixUIBannerBmp" Value="$(var.Extra)/banner.bmp"/>
+  </Package>
 </Wix>
diff --git a/packaging/verify-msi.sh b/packaging/verify-msi.sh
index 54cc1950..6e54ef92 100755
--- a/packaging/verify-msi.sh
+++ b/packaging/verify-msi.sh
@@ -66,9 +66,13 @@ say "product code $got, derived from the version"
 upgrades=$(table Upgrade | upper)
 holds "$upgrades" "$want" ||
   bad "$msi has no Upgrade row for $want, so it would install beside an older version"
-holds "$upgrades" OLDERVERSIONBEINGUPGRADED ||
+# The property names are the toolset's: WiX 4 and later's MajorUpgrade writes
+# WIX_UPGRADE_DETECTED and WIX_DOWNGRADE_DETECTED, where WiX 3 and hand-authored
+# packages used OLDERVERSIONBEINGUPGRADED and NEWERVERSIONDETECTED. Either pair
+# is the same two rows; the check is that both rows exist.
+holds "$upgrades" "WIX_UPGRADE_DETECTED\|OLDERVERSIONBEINGUPGRADED" ||
   bad "$msi detects no older version to remove"
-holds "$upgrades" NEWERVERSIONDETECTED ||
+holds "$upgrades" "WIX_DOWNGRADE_DETECTED\|NEWERVERSIONDETECTED" ||
   bad "$msi would let an older build install over a newer one"
 say "older versions are removed and a newer one is refused"
 
@@ -92,6 +96,38 @@ case "$(prop SecureCustomProperties)" in
 esac
 say "installs under Program Files, per machine or per user, into a chosen location"
 
+# The location it chose, said back. Nothing sets ARPINSTALLLOCATION by itself,
+# and without it Apps and Features shows a blank Install location - so a person
+# who wants to know where their copy went has to guess. The action is generated
+# from the SetProperty in meshbench.wxs and named after the property it sets.
+holds "$(table CustomAction)" SetARPINSTALLLOCATION ||
+  bad "$msi does not set ARPINSTALLLOCATION, so Apps and Features would show no install location"
+holds "$(table InstallExecuteSequence)" SetARPINSTALLLOCATION ||
+  bad "$msi never runs SetARPINSTALLLOCATION, so the property is authored and unset"
+say "reports its install location to Apps and Features"
+
+# The dialogs. WiX builds them and wixl could not, which is the whole reason
+# this package moved toolset - so a build that quietly lost them would undo it.
+dlgs=$(table Dialog)
+for d in WelcomeDlg InstallDirDlg BrowseDlg ExitDialog; do
+  holds "$dlgs" "$d" || bad "$msi has no $d, so the installer cannot ask or report"
+done
+say "asks where to install, and says when it has finished"
+
+# And where an upgrade goes. Without the search, a version installed into a
+# chosen directory comes back in Program Files and the choice is silently
+# undone; measured before it was added.
+holds "$(table Registry)" InstallDir ||
+  bad "$msi does not record its install directory, so an upgrade would not stay put"
+say "remembers where it was installed"
+
+# And that it can be taken off again. An MSI gets this for nothing, which is
+# exactly why it is worth asserting: the maintenance dialogs come from the UI
+# extension, and a package that lost them would still install perfectly and
+# only be found wanting by somebody trying to remove it.
+holds "$dlgs" MaintenanceTypeDlg ||
+  bad "$msi has no maintenance dialog, so running it again offers no Remove"
+say "offers Repair and Remove when run again"
 holds "$(table Shortcut)" ProgramMenuFolder || bad "$msi makes no Start menu entry"
 say "Start menu entry present"
 
diff --git a/packaging/windows-msi.ps1 b/packaging/windows-msi.ps1
new file mode 100644
index 00000000..826fd48d
--- /dev/null
+++ b/packaging/windows-msi.ps1
@@ -0,0 +1,61 @@
+# Build a Windows installer with the WiX toolset, on Windows.
+#
+#   packaging/windows-msi.ps1 -Stage <dir> -Extra <dir> -Out <file.msi>
+#
+# <Extra> is what packaging/windows-msi.sh made on Linux: the icon, the dialog
+# bitmaps, the installer's note and msi.env. WiX builds the dialogs wixl could
+# not - a Destination Folder page with a Change button, and a page that says the
+# install finished - and it only builds an MSI on Windows (#508).
+param(
+  [Parameter(Mandatory)] [string] $Stage,
+  [Parameter(Mandatory)] [string] $Extra,
+  [Parameter(Mandatory)] [string] $Out
+)
+$ErrorActionPreference = 'Stop'
+
+$cfg = @{}
+Get-Content (Join-Path $Extra 'msi.env') | ForEach-Object {
+  $k, $v = $_ -split '=', 2
+  if ($k) { $cfg[$k] = $v }
+}
+
+$wxs = Join-Path $PSScriptRoot 'meshbench.wxs'
+$Stage = (Resolve-Path $Stage).Path
+$Extra = (Resolve-Path $Extra).Path
+$Out = [System.IO.Path]::GetFullPath($Out)
+
+# One command, and no harvest step: WiX walks the tree itself, in its own
+# order, so the same tree built twice is the same installer.
+& wix build -arch x64 `
+  -d "ProductCode=$($cfg.PRODUCT)" -d "Version=$($cfg.MSIVERSION)" `
+  -d "Stage=$Stage" -d "Extra=$Extra" `
+  -ext WixToolset.UI.wixext `
+  -o $Out $wxs
+if ($LASTEXITCODE -ne 0) { throw "wix build failed with $LASTEXITCODE" }
+
+# ALLUSERS back to 2, which is the one thing the toolset will not author.
+#
+# This package has always been dual-purpose: per-machine by default, and
+# per-user with MSIINSTALLPERUSER=1, which is what lets somebody without
+# administrator rights install into their own profile. WiX 4 removed the
+# option and emits ALLUSERS=1, so the row is corrected here, through Windows
+# Installer's own database API, rather than a documented install route being
+# dropped to suit a schema. verify-msi.sh checks it.
+$installer = New-Object -ComObject WindowsInstaller.Installer
+$db = $installer.GetType().InvokeMember('OpenDatabase', 'InvokeMethod', $null, $installer, @($Out, 1))
+$view = $db.GetType().InvokeMember('OpenView', 'InvokeMethod', $null, $db,
+  @("UPDATE ``Property`` SET ``Value``='2' WHERE ``Property``='ALLUSERS'"))
+$view.GetType().InvokeMember('Execute', 'InvokeMethod', $null, $view, $null) | Out-Null
+$view.GetType().InvokeMember('Close', 'InvokeMethod', $null, $view, $null) | Out-Null
+$db.GetType().InvokeMember('Commit', 'InvokeMethod', $null, $db, $null) | Out-Null
+[System.Runtime.InteropServices.Marshal]::FinalReleaseComObject($db) | Out-Null
+
+# How many files WiX harvested from, for verify-msi.sh to hold the package to.
+# Counted here rather than where the tree was staged: it reached this runner as
+# an artifact, which stores each symlink in the emulators as the file it points
+# at, so a count from the Linux side came out short.
+$files = (Get-ChildItem -Path $Stage -Recurse -File -Force).Count
+Set-Content -Path "$Out.files" -Value $files -NoNewline
+
+Get-Item $Out | Format-List Name, Length
+"$files files staged"
diff --git a/packaging/windows-msi.sh b/packaging/windows-msi.sh
index 8d06e14d..05b8c481 100755
--- a/packaging/windows-msi.sh
+++ b/packaging/windows-msi.sh
@@ -1,43 +1,48 @@
 #!/usr/bin/env bash
-# Build the Windows installer from an assembled bundle, on Linux.
+# Get a Windows installer ready to build: everything the WiX step needs that is
+# made from the repository rather than harvested from the staged tree.
 #
-#   packaging/windows-msi.sh <bundle-dir> <version> <output.msi>
+#   packaging/windows-msi.sh <stage-dir> <version> <extra-dir>
 #
-# <bundle-dir> is the directory meshbench.exe sits in, the same one the zip is
-# made from, and everything in it goes into the installer. That is the point:
-# the emulators and the SX1262 model are found beside the binary, so an
-# installer that carried the binary alone would produce a build that cannot
-# emulate a board and cannot say why.
+# The installer itself is built by the WiX toolset, on Windows, by
+# packaging/windows-msi.ps1. WiX cannot build an MSI anywhere else: it needs
+# Windows' own msi.dll to write the database, and on Linux it dies on
+# "Unable to load shared library 'msi.dll'" after refusing every
+# Directory/@Name (#508). wixl, which does run here, builds no dialogs. So the
+# work is split: this half runs on Linux with the tools that only Linux has
+# (icotool, Pillow), the build runs on a Windows runner, and verify-msi.sh
+# reads the result back on Linux with msitools.
 #
-# No Windows runner. wixl reads the WiX source and writes the .msi here, beside
-# the mingw cross-build that produced the .exe. What that costs is the
-# installer's user interface: wixl builds no dialogs, so msiexec shows a
-# progress bar and takes its answers from the command line instead. Those
-# answers - a location, per-user, a desktop shortcut - are written out for
-# somebody installing this in docs/install.md.
+# What lands in <extra-dir>: the icon, the two dialog bitmaps, the note the
+# installer adds beside the binary, and msi.env, which carries the version the
+# MSI is stamped with, the product and upgrade codes, and how many files the
+# stage holds here. The check uses the count windows-msi.ps1 takes of the tree
+# WiX actually harvested instead, because the tree crosses to the Windows
+# runner as an artifact and the emulators' symlinks arrive as the files they
+# point at - a count taken on this side came out short.
 set -euo pipefail
 
 stage=${1:?the directory meshbench.exe sits in}
 version=${2:?the release version}
-out=${3:?the .msi to write}
+extra=${3:?the directory to write into}
 
 here=$(cd "$(dirname "$0")" && pwd)
 
 missing=""
-for t in wixl wixl-heat msiinfo msibuild icotool python3; do
+for t in icotool python3; do
   command -v "$t" >/dev/null || missing="$missing $t"
 done
 if [ -n "$missing" ]; then
-  echo "::error::windows-msi: missing:$missing - wixl and wixl-heat are the" \
-       "'wixl' package on Debian and Ubuntu rather than 'msitools', which is" \
-       "where msiinfo lives; icotool is 'icoutils'" >&2
+  echo "::error::windows-msi: missing:$missing - icotool is 'icoutils'" >&2
   exit 1
 fi
+# The dialog bitmaps are composed with Pillow, which python3 does not carry by
+# itself. Checked here rather than met as a traceback minutes into a release.
+python3 -c 'import PIL' 2>/dev/null || {
+  echo "::error::windows-msi: python3 cannot import PIL - install python3-pil" >&2
+  exit 1
+}
 
-# Windows Installer compares three numeric fields and ignores anything after
-# them, so a development version has no version to compare and is given the
-# lowest one. Every real release is a plain X.Y.Z and passes through.
-msiversion=$version
 # A development build's suffix is not an MSI version, but its base is: the
 # pre-release of 0.0.11 installs as 0.0.11, so the MSI ordering it takes part
 # in is the one the tag means. A version that is not X.Y.Z at all is 0.0.0.
@@ -55,76 +60,26 @@ import uuid, sys
 print(uuid.uuid5(uuid.UUID('$upgrade'), sys.argv[1]).urn[9:].upper())
 " "$msiversion")
 
-# wixl reads every File Source relative to the directory it is run from, and
-# hands an absolute one to g_file_get_child, which rejects it with a GLib
-# assertion and then says it cannot find the file. So the two source trees are
-# linked into one working directory and named relatively from there.
-work=$(mktemp -d)
-trap 'rm -rf "$work"' EXIT
-extra=$work/extra
 mkdir -p "$extra"
-ln -s "$(cd "$stage" && pwd)" "$work/stage"
-out=$(cd "$(dirname "$out")" && pwd)/$(basename "$out")
-
 # Windows wants one icon file holding every size, the way macOS wants one
-# .icns. Built here from the committed PNGs for the same reason macos-app.sh
-# builds the .icns there: one set of source images, and no second copy of the
-# mark to go stale.
+# .icns, built from the committed PNGs so there is no second copy of the mark.
 icotool -c -o "$extra/meshbench.ico" \
   "$here/icons/meshbench-16.png" "$here/icons/meshbench-32.png" \
   "$here/icons/meshbench-48.png" "$here/icons/meshbench-64.png" \
   "$here/icons/meshbench-128.png" "$here/icons/meshbench-256.png"
-
+# The two bitmaps the dialogs are drawn on; see dialog-bitmaps.py.
+python3 "$here/dialog-bitmaps.py" \
+  "$here/../docs/brand/meshbench-card.png" \
+  "$here/icons/meshbench-256.png" \
+  "$extra"
 sed "s/<version>/$version/" "$here/installed-by-msi.txt" \
   > "$extra/installed-by-msi.txt"
 
-# Everything in the bundle, as components. Sorted, so the source that goes
-# into a build is the same from one run to the next and a diff of two builds
-# is about what changed rather than about what order find walked in.
-(cd "$stage" && find . -type f | sed 's|^\./||' | LC_ALL=C sort) |
-  wixl-heat --var var.Stage --directory-ref INSTALLDIR \
-    --component-group Bundle --prefix "" --win64 > "$work/bundle.wxs"
-
-files=$(grep -c '<File ' "$work/bundle.wxs")
-echo "windows-msi: $files files from $stage"
-
-# wixl-heat names each directory with a fresh random id every run, and wixl
-# derives each component's GUID from that, so the same tree built twice comes
-# out as two different installers. Renumbered here in the order they appear -
-# which the sorted harvest above makes stable - so a rebuild of a version
-# produces the same package, and two builds can be compared for what actually
-# changed. Only the directory ids are touched; the component and file ids are
-# already hashes of the paths.
-python3 - "$work/bundle.wxs" <<'PY'
-import re
-import sys
-
-path = sys.argv[1]
-seen = {}
-def stable(m):
-    return seen.setdefault(m.group(0), "dir%04d" % (len(seen) + 1))
-with open(path) as f:
-    src = f.read()
-with open(path, "w") as f:
-    f.write(re.sub(r"dir[0-9A-F]{32}", stable, src))
-PY
-
-(cd "$work" && wixl -a x64 -o "$out" \
-  -D "ProductCode=$product" -D "Version=$msiversion" \
-  -D Stage=stage -D Extra=extra -D Win64=yes \
-  "$here/meshbench.wxs" bundle.wxs)
-
-# A public property set on the msiexec command line does not survive the
-# elevation a per-machine install goes through unless SecureCustomProperties
-# names it, and INSTALLDIR is the one this package offers. wixl writes that row
-# itself, for the upgrade properties, and refuses a second row with the same
-# key - so the row it wrote is extended here rather than authored in the .wxs.
-# tr, because msiinfo writes the IDT form with DOS line endings and a carriage
-# return would ride into the property Windows then reads.
-secure=$(msiinfo export "$out" Property | tr -d '\r' |
-  awk -F'\t' '$1 == "SecureCustomProperties" { print $2 }')
-msibuild "$out" -q "UPDATE \`Property\` SET \`Value\`='$secure;INSTALLDIR;MSIINSTALLPERUSER'
-  WHERE \`Property\`='SecureCustomProperties'"
-
-# Plus the note, which is the one file the installer adds to the bundle.
-"$here/verify-msi.sh" "$out" "$msiversion" "$upgrade" "$((files + 1))"
+files=$(find "$stage" -type f | wc -l)
+cat > "$extra/msi.env" <<ENV
+MSIVERSION=$msiversion
+PRODUCT=$product
+UPGRADE=$upgrade
+FILES=$files
+ENV
+echo "windows-msi: $files files from $stage, MSI version $msiversion"