Summary
The WinDbg/TTD installer used a hand-rolled ZIP/inflate parser and materialized a large intermediate file to disk, so the install appeared to hang on the "Verifying installation..." step.
Background
For a current WinDbg package the installer touched roughly 1.9 GB of temporary disk I/O. The inner windbg_win-x64.msix (381 MB) was written to a temp file only to be reopened and read straight back, then deleted.
Symptom: "Verifying installation..." appears stuck
CheckInstallation() itself is instant (six fs::exists checks). The perceived hang was the CleanupTempFiles() call that ran right after it. Measured: deleting the freshly-written 381 MB inner .msix took ~68 s — not because the raw delete is slow (that's ~85 ms) but because antivirus scans the just-written archive synchronously on delete.
Resolution (landed in #1128)
- Replaced the homegrown ZIP/inflate parser (
vendor/minizip-ng, ~45 KB of bespoke code — despite the name, not upstream minizip-ng) with the vendored, well-audited miniz amalgamation. Also removes a bespoke parser from a supply-chain-sensitive path and fixes the old reader's 2 GB (long) offset limit.
- Extract the inner package directly from memory (
mz_zip_reader_init_mem) into the install dir — no intermediate .msix file is written or later deleted.
- Gave the cleanup step its own progress message.
Measured (real 1.13 GB package): whole install ~87 s → ~17 s; cleanup ~68 s → 0 ms (nothing to delete). The remaining ~17 s is the actual writing of 1446 payload files.
Follow-up (not in #1128)
In the real download path the 1.13 GB .msixbundle itself is still deleted at the end and could hit the same antivirus scan-on-delete cost. Worth measuring separately; the inner-package temp (the ~68 s case) is resolved.
Summary
The WinDbg/TTD installer used a hand-rolled ZIP/inflate parser and materialized a large intermediate file to disk, so the install appeared to hang on the "Verifying installation..." step.
Background
For a current WinDbg package the installer touched roughly 1.9 GB of temporary disk I/O. The inner
windbg_win-x64.msix(381 MB) was written to a temp file only to be reopened and read straight back, then deleted.Symptom: "Verifying installation..." appears stuck
CheckInstallation()itself is instant (sixfs::existschecks). The perceived hang was theCleanupTempFiles()call that ran right after it. Measured: deleting the freshly-written 381 MB inner.msixtook ~68 s — not because the raw delete is slow (that's ~85 ms) but because antivirus scans the just-written archive synchronously on delete.Resolution (landed in #1128)
vendor/minizip-ng, ~45 KB of bespoke code — despite the name, not upstream minizip-ng) with the vendored, well-audited miniz amalgamation. Also removes a bespoke parser from a supply-chain-sensitive path and fixes the old reader's 2 GB (long) offset limit.mz_zip_reader_init_mem) into the install dir — no intermediate.msixfile is written or later deleted.Measured (real 1.13 GB package): whole install ~87 s → ~17 s; cleanup ~68 s → 0 ms (nothing to delete). The remaining ~17 s is the actual writing of 1446 payload files.
Follow-up (not in #1128)
In the real download path the 1.13 GB
.msixbundleitself is still deleted at the end and could hit the same antivirus scan-on-delete cost. Worth measuring separately; the inner-package temp (the ~68 s case) is resolved.