Files
winutil/docs
KristianandChris Titus fc03af421b Add friendly explanations for common DISM exit codes (#5087)
* 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>
2026-09-29 11:17:51 -05:00
..

WinUtil Docs

Built with Starlight

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.