Conversation
CheckInstallation is instant, but the CleanupTempFiles call right after it deletes ~1.5 GB of temporaries (the ~1 GB downloaded .msixbundle and the extracted ~380 MB inner MSIX). That ran with no progress message, so the UI appeared stuck on "Verifying installation..." for several seconds. Emit a "Cleaning up temporary files..." step before the deletion. This is the first step toward #1127; the redundant intermediate disk extraction is tracked there for follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
xusheng6
marked this pull request as draft
July 20, 2026 22:53
Two changes to investigate and iterate on the slow "cleanup" step: - --bundle <file>: install from an already-downloaded .msixbundle instead of downloading it. The file is used in place and is never added to the temp-file list, so cleanup does not delete it and it can be reused across test runs. Skips all network steps. Also add --verbose/-v to surface info-level logs (including the timing below) in human mode. - Timing instrumentation: log elapsed time for the inner-MSIX extraction, the install-dir extraction, and cleanup, plus per-file size and delete time in CleanupTempFiles. Measured with --bundle on a real package: extracting the inner MSIX to the install dir took ~18 s, but deleting the freshly-extracted 381 MB inner .msix took ~68 s. Reproduced independently: a plain delete of a just-written 381 MB .msix takes ~76 s with Defender real-time protection on (it scans the archive synchronously on delete), versus ~0.2 s to write it. So the "cleanup" delay is antivirus scan-on-delete of the intermediate MSIX, not the raw delete - which is the strongest argument for the #1127 fix of streaming the inner MSIX instead of materializing it to disk. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ry (#1127) The installer previously used a hand-rolled ZIP/inflate reader (vendor/minizip-ng, ~45 KB of bespoke parsing code sitting directly in the download path) and extracted the inner windbg_win-x64.msix to a temporary file before extracting its contents. That temp file was the source of the slow "cleanup": deleting the freshly-written 381 MB .msix took ~68 s because antivirus scans the archive synchronously on delete. - Vendor miniz 3.0.2 (amalgamated miniz.c/miniz.h + LICENSE) and remove the homegrown vendor/minizip-ng parser entirely. miniz is a widely-used, well-audited single-file library that bundles both ZIP reading and inflate, so no separate zlib backend is needed. It also uses 64-bit file offsets (_fseeki64), fixing the old reader's 2 GB (long) limit. - Read the inner package from memory (mz_zip_reader_init_mem) and extract its payload files straight to the install directory. No intermediate .msix file is written or later deleted. Measured with --bundle on a real package: whole install dropped from ~87 s to ~17 s, and cleanup from ~68 s to 0 ms (nothing to delete). The remaining ~17 s is the actual writing of 1446 payload files. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
xusheng6
changed the title
…1127) The per-step and per-file timing (ElapsedMs/MsStr and the Timing- logs) was scaffolding added to diagnose the slow cleanup. The cause is understood and fixed, so restore CleanupTempFiles to its simple form and drop the timing helpers. The --bundle and --verbose CLI flags are kept as useful test/field diagnostics. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
xusheng6
marked this pull request as ready for review
July 21, 2026 14:17
plafosse
self-requested a review
July 21, 2026 17:40
Member
Author
|
We want to see if we can use binja's container file support to do the extraction |
Member
Author
@plafosse this cannot use the binja's zip support -- it is meant to be executed as a standalone executable, and it does not link with binja (or it would not work for the free version). As such, I think miniz is a reasonable choice |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1127.
Summary
The installer used a hand-rolled ZIP/inflate parser (
vendor/minizip-ng, ~45 KB of bespoke code — despite the folder name, it is not upstream minizip-ng) sitting directly in the download path, and it extracted the innerwindbg_win-x64.msixto a temporary file before extracting its contents. That temp file was the real cause of the slow "cleanup": deleting the freshly-written 381 MB.msixtook ~68 s because antivirus scans the archive synchronously on delete.Changes
vendor/miniz, amalgamatedminiz.c/miniz.h+LICENSE) and deletevendor/minizip-ngentirely. miniz is a widely-used, well-audited single-file library bundling both ZIP reading and inflate (no separate zlib backend needed). It also uses 64-bit file offsets, fixing the old reader's 2 GB (long) limit.mz_zip_reader_init_mem) straight into the install dir — no intermediate.msixis written or later deleted.--bundle <file>/--verboseoption to the installer CLI to install from an already-downloaded bundle (kept, not deleted) with timing logs — used to measure the changes below.Measured (via
--bundleon a real 1.13 GB package)1446 payload files extracted; all required files (
dbgeng.dll,TTD.exe, …) present. The remaining ~17 s is the actual writing of those files.Security note
This removes a bespoke ZIP/inflate parser from a supply-chain-sensitive download path in favor of a maintained, widely-reviewed library — motivation for the switch.
🤖 Generated with Claude Code