WJF00052 / WJF00083 / WJF00084 / WJF00159 produced 0-byte ZIPs on the
2026-05-24 capture pass. Export-FormtracepakInventory was the primary
culprit (Get-Service hang, fixed in d359563), but Backup has the same
root failure mode for the same bays: reg.exe export via Start-Process
-Wait and the recursive Get-ChildItem walk over HKLM:\SOFTWARE\
WOW6432Node\Mitutoyo (95k+ values) both lack timeouts, so a degraded
SCM / antivirus interception / WMI repository on the bay can wedge the
script and the operator kills the .bat - same outcome as the inventory
hang.
Two timeout fences:
- reg.exe export: switch from Start-Process -PassThru -Wait to
[System.Diagnostics.Process]::Start + WaitForExit(300_000). If the
process hasn't exited after 5 minutes, Kill() it and log + count an
error; the .reg file for that one root is skipped but other roots
+ the CSV fallback + the file/data captures continue. Bonus: the
ProcessStartInfo path also gives reliable $proc.ExitCode access; the
Start-Process -PassThru object sometimes returned a stub with
unpopulated ExitCode, producing a false "reg.exe exit for ..."
warning even on successful exports.
- Recursive Get-ChildItem CSV walk: move into a Start-Job + Wait-Job
-Timeout 600 (10 min). If the walk hangs, Stop-Job, log, increment
error count, .reg file remains authoritative for that root.
Also fixed a subtle Start-Job return-shape bug introduced in the same
edit: emitting the rows via the pipeline inside the job + Receive-Job
flattens correctly, whereas `return ,$list` wrapped the whole List in a
single-element array, so the outer foreach was treating the list-of-95k
as a single row. Net effect was Registry Values: 4 instead of 95152 in
the manifest. Verified fixed via a full real-install run on the VM:
95152 values captured cleanly in 22 s, 0 errors.
Net behaviour: the failed-bay re-runs (WJF00052/00083/00084/00159)
should now either produce real ZIPs or print a clear warning naming the
specific reg root that hung, instead of leaving an empty ZIP behind.
6602afde38