* Add friendly explanations for common DISM exit codes Invoke-WinUtilISODism threw only a raw exit code on DISM failure (e.g. "DISM add-driver failed with exit code 112"), leaving users to look up what the number means themselves. Adds a $knownExitCode lookup table mapping common Windows/DISM exit codes (disk full, access denied, file/path not found, file in use, timeout, etc.) to plain-English explanations. When a failure's exit code is recognized, the thrown message now includes the explanation in parentheses; unrecognized codes fall back to the original plain-number message. Verified the script still parses correctly after the change. * Add missing period to fallback DISM error message * Add tests for DISM known/unknown exit code error messages Adds a test verifying a known exit code (112) produces the friendly explanation in the thrown message, alongside the existing test verifying an unrecognized code still falls back to the plain numeric message. Verified: all 35 tests in win11creator.Tests.ps1 pass. * Document DISM friendly error messages in Win11 Creator troubleshooting Adds a Troubleshooting table row explaining the new DISM error message format (exit code + explanation in parentheses), with guidance for the most common cases and a link to Microsoft's full error code reference for anything not explained. * Fix duplicate DISM calls in unmapped exit code test The unmapped-code test called Invoke-WinUtilISOScript twice — once via Should -Throw, once to capture the message for the no-parens check — causing $script:dismCalls to double-count. Consolidated to a single call, checking both the exit code and the absence of a parenthesized explanation against one captured exception message. Verified: all 36 tests in win11creator.Tests.ps1 pass. * Fix broken DISM error code reference link in docs Replaced the dead windows-hardware/manufacture link with Microsoft's actual System Error Codes reference page, which DISM exit codes correspond to. * Strengthen DISM fallback regression coverage --------- Co-authored-by: Chris Titus <contact@christitus.com>
WinUtil Docs
Documentation site for WinUtil, built with Astro and Starlight. Served at winutil.christitus.com.
🚀 Project Structure
.
├── public/
├── src/
│ ├── assets/
│ ├── components/
│ ├── content/
│ │ └── docs/
│ ├── styles/
│ └── content.config.ts
├── astro.config.mjs
├── docker-compose.yml
├── Dockerfile
├── package.json
└── tsconfig.json
Starlight looks for .md or .mdx files in the src/content/docs/ directory. Each file is exposed as a route based on its file name.
Images can be added to src/assets/ and embedded in Markdown with a relative link.
Static assets, like favicons, can be placed in the public/ directory.
🧞 Commands
All commands run in a Docker container — there's no need to install Node or npm dependencies on your host. This is deliberate, not just convenience: npm/pnpm/yarn have seen a steady stream of supply-chain attacks (malicious postinstall/preinstall scripts, credential-stealing packages), so npm install and friends never run directly on a contributor's machine here. Note the container still has read-write access to this docs/ directory (it's bind-mounted for live reload), so this only contains a compromised package to the project folder plus the container itself — it doesn't reach the rest of your host (SSH keys, other repos, cloud credentials elsewhere on disk). Don't keep real secrets in docs/ as a result.
Docker (with Compose) is required — install Docker Desktop (or Docker Engine + the docker compose plugin on Linux) and make sure the daemon is running before using any of the commands below.
All commands are run from the docs/ directory, from a terminal:
| Command | Action |
|---|---|
docker compose build |
Builds the dev image (needed after Dockerfile or dependency changes) |
docker compose up winutil-astro |
Starts local dev server at localhost:4321 |
docker compose run --rm winutil-astro npm run build |
Build the production site to ./dist/ |
docker compose run --rm --service-ports winutil-astro npm run preview -- --host 0.0.0.0 |
Preview the build locally, before deploying |
docker compose run --rm winutil-astro npm run astro ... |
Run CLI commands like astro add, astro check |
docker compose down |
Stop and remove the dev container |
Source files are bind-mounted into the container, so edits on the host are picked up immediately by the dev server — no rebuild needed for normal content or code changes. After changing package.json, package-lock.json, or the Dockerfile, rebuild the image and drop the node_modules volume, since Docker only seeds a named volume from the image the first time it's created — a plain rebuild leaves the old node_modules in place:
docker compose build
docker compose down -v
docker compose up winutil-astro
The first docker compose up (or any command before an image exists) builds the image and runs npm install from scratch, which can take a few minutes. Subsequent runs reuse the cached image and start almost immediately.
👀 Want to learn more?
Check out Starlight's docs, read the Astro documentation, or jump into the Astro Discord server.