Create a Bootable USB: Rescue and Install Drives, from Download to First Boot

By the end of this guide you will have a USB drive that boots a computer into one of three things: a full operating-system installer (Windows or Linux), a live environment that runs entirely from the stick, or a recovery environment with repair tools. You will also understand why each step exists — what the firmware is checking when it accepts or rejects the drive, what the creation tool actually writes, and how to tell a successful boot from a failed one — so that when something goes wrong, you can diagnose it instead of guessing. The workflow in one line: decide the purpose → size and prepare the drive → download the image from an official source → verify it → write it with the right tool → boot from it → test before touching any disk.

The first decision is the one most guides skip, because it changes everything downstream: are you making installation media or rescue media? Installation media exists to put a new operating system on a machine — it runs a setup program that will eventually write your target disk, and its value is measured in "clean install completed". Rescue media exists to work on a machine that already has an operating system but cannot use it normally — it runs repair tools, file access or diagnostics without replacing anything, and its value is measured in "data recovered" or "system repaired". A single USB can sometimes serve both roles (a Linux live stick can install and rescue; Windows installation media includes a command prompt with recovery commands), but the settings you choose differ: an installer-focused drive optimizes for the setup program, while a rescue-focused drive often needs specific tools or drivers that an installer does not carry. If you are not sure which situation you are in, make the more conservative one: a live/rescue environment costs nothing to boot and lets you back up files before any irreversible decision.

Situations where a bootable USB is the right tool: installing Windows or Linux on a new machine or an empty drive; reinstalling after a failed update or a corrupted installation; recovering files from a PC that no longer boots into its own disk; running diagnostics (memory tests, disk health checks) outside the operating system that may be failing; and creating a known-good fallback so that "my PC won't start" becomes a 30-minute job instead of an emergency. Situations where it is not the whole answer: a machine with a physically failing drive (the USB helps you copy data out, but the fix is replacing the drive — section 9 covers when to stop and get professional help), hardware faults that prevent any boot (no POST, dead power), or license and driver problems that persist after a clean install. This guide also deliberately stops short of two adjacent topics: the detailed Windows 11 installation walkthrough — edition choice, partition decisions, first-run setup — lives in the Install Windows 11 from a USB Drive guide, and deeper firmware work (POST codes, BIOS updates) is covered by the Motherboard & BIOS/UEFI guide. Everything you need for the media itself — from download to first successful boot — is in this page.

An operating-system image is a packaged snapshot of everything an installer or live system needs: the setup program (or the whole running system), drivers for common hardware, and — crucially — a small bootloader that the firmware can load before any operating system exists. An .iso file is one packaging format: a single file containing a complete filesystem image plus the boot information the firmware needs to start it. Other formats exist too — raw .img files (common for Raspberry OS and some Linux images), WIM files, and vendor-specific bundles — and the creation tool you pick in section 5 depends partly on which format your image uses. The key mental model: the ISO is a shipping box, not the product installed on the stick. A bootable USB is what you get when a tool opens that box and lays its contents out in the specific partition layout the firmware expects.

That layout is where "bootable" actually lives. On a modern UEFI system, the drive must contain a small FAT32 partition — the EFI System Partition (ESP) — marked with a special partition type code; the firmware scans every boot-capable device for such a partition and looks inside it for a signed bootloader file at a defined path. On a legacy BIOS system, there is no partition scan at all: the firmware reads the first 512 bytes of the drive (the Master Boot Record), finds a pointer to boot code in one of the partitions, and hands over execution — so the drive needs an MBR-style layout with that boot record written correctly. The same ISO therefore produces two different physical drives depending on the target: GPT partition table + ESP for UEFI, MBR + boot record for legacy BIOS. Many computers support both modes (often called "CSM" or "compatibility support"), which is why a drive can boot on one machine and be ignored by another that has its firmware set differently.

UEFI adds a security layer legacy BIOS does not have: Secure Boot. When enabled, the firmware refuses to load a bootloader whose digital signature it cannot verify against its built-in key database. This is why official operating-system images work out of the box — Microsoft signs Windows bootloaders, and mainstream Linux distributions ship a signed "shim" that chains verification down to GRUB — while unsigned or home-built images fail with a cryptic signature error until Secure Boot is disabled in firmware (section 7 explains how to do that deliberately, with the trade-offs stated). Legacy BIOS mode has no equivalent check: it will happily boot anything, which is both its flexibility and its vulnerability. Knowing which mode your target machine uses — Settings > System > About on Windows shows "BIOS mode" via msinfo32, or the firmware screen itself — tells you which partition layout to ask the creation tool for, and it is one of the most common causes of "the USB appears but will not boot".

Finally, three kinds of media that all look similar on a stick but do different things at first boot:

The practical consequence of this table: when someone says "I need a bootable USB", the answer to "for what?" determines the image, the tool settings and even the drive size. A Windows installation ISO is not automatically good rescue media — it has no file browser for your old disk until you are deep in setup — while a Linux live stick can open your NTFS partitions, copy files out and run hardware tests before any installer ever runs. Section 9 returns to this distinction with concrete rescue workflows; for now, keep the question "install or rescue?" in front of you, because every later section uses it.

There is no universal minimum size for a bootable USB, and any guide that gives you one is rounding. The real calculation has two terms: the size of the image you actually downloaded, plus headroom for what the creation tool writes around it (partition metadata, and in Rufus’s case the space needed when it converts a large install.wim into an ESD stream). Current mainstream images are all in roughly the same band — a current Windows 11 ISO is about 6 GB, Ubuntu’s desktop LTS image about 5.8 GB, older or lighter distros between 1 and 4 GB — so an 8 GB stick technically fits most of them, but with almost no margin: some tools refuse to work on a drive whose free space is within a few hundred megabytes of the image size, and Ventoy needs extra room for its own boot manager and plugin files. The safe rule: take your downloaded file’s actual size, add 20%, and round up to the next common stick size (8 / 16 / 32 / 64 GB). For a ~6 GB Windows image that means 16 GB is the comfortable choice; for a 2 GB Linux image, 4–8 GB is fine. The table below gives typical bands so you can sanity-check your own numbers.

Speed matters less than people expect, but it is not irrelevant. A USB 2.0 stick (the white or black interior, 480 Mbit/s theoretical) delivers roughly 30–35 MB/s in practice; a USB 3.x stick (blue or red interior, 5 Gbit/s and up) can sustain well over 100 MB/s on good hardware. For the write step that difference is minutes, not hours — a 6 GB image takes around three minutes over USB 3.x and ten to fifteen over USB 2.0. The bigger effect is at install time: Windows setup reads drivers and files from the stick throughout installation, so a slow stick makes every "gathering files" phase longer, and on an old machine with only USB 2.0 ports there is nothing you can do about it except be patient. Compatibility notes for older hardware: USB 3 ports accept USB 2 sticks without any problem (they simply run slower), but some pre-2015 motherboards have finicky USB port support during boot — if a stick will not appear in the boot menu, try a different port, preferably one on the rear of a desktop directly attached to the motherboard rather than a front-panel hub.

Before anything is written, protect the drive’s existing contents and make it impossible to confuse with another device. Three habits prevent almost every data-loss story in this domain: (1) Back up everything on the stick — every creation tool erases the selected drive without a second confirmation that names your files, so "I only had some documents on there" is not a recoverable situation after the fact; copy them to the computer or another drive first. (2) Identify the drive by more than its letter. Drive letters move between reboots and differ per machine; capacity plus manufacturer label (visible in File Explorer’s device properties or Disk Management) is what you will match against when a tool lists "removable devices". If two sticks of similar size are plugged in, unplug one. (3) Put a physical label on it — even a piece of tape reading "INSTALL USB" prevents the classic mistake of reaching for the wrong stick under time pressure, and later distinguishes your rescue media from backup drives when you need it at 2 a.m.

The single most important security decision in this entire workflow happens before any tool is opened: where the image comes from. A bootable USB is, by definition, trusted code that runs before your operating system’s defenses exist — so an image obtained from a third-party "ISO download" site, a repack bundle or a link of unknown origin carries the same weight as installing software from a stranger. The official channels are unglamorous but complete: for Windows, Microsoft’s own Windows 11 download page offers both the Media Creation Tool (which can write the USB directly or save an ISO) and a direct "Download Disk Image (ISO)" flow for the current release; for Linux, each distribution publishes its images on its own domain — Ubuntu’s are at ubuntu.com/download, with official mirrors listed by the project itself. Two practical checks before you download: verify the URL is the vendor’s actual domain (typosquatting sites exist precisely to catch people searching for free Windows ISOs), and prefer HTTPS connections — the certificate check does not prove the file is what you want, but it rules out the cheapest tampering attacks.

Downloading from the official source is necessary but not sufficient: files can be corrupted in transit (a dropped connection, a flaky mirror, an interrupted browser download), and corruption at this stage produces failures that look exactly like hardware problems later — black screens, boot loops, installers that die mid-copy. That is why every serious distribution publishes checksums: a SHA-256 hash is a 64-character fingerprint of the file’s exact contents, and any single changed byte produces a completely different fingerprint. The verification workflow is: (1) note the official SHA-256 value published alongside the image, (2) compute the hash of your downloaded file, (3) compare character for character. On Linux or macOS, sha256sum does it in one line; on Windows, certutil ships with the operating system. The commands below are read-only — they calculate a fingerprint and change nothing.

sha256sum ubuntu-24.04-desktop-amd64.iso
# macOS (same tool via Homebrew, or built-in shasum):
shasum -a 256 ubuntu-24.04-desktop-amd64.iso

certutil -hashfile C:\downloads\ubuntu-24.04-desktop-amd64.iso SHA256

Where available, go one step further and verify the digital signature of the checksum file itself: Ubuntu publishes its SHA256SUMS files with a GPG signature from Canonical’s release key, so you can confirm not just that your file matches the list, but that the list genuinely came from the project — Ubuntu’s own verification tutorial walks through exactly this. Microsoft does not publish standalone hashes for its ISOs in the same way; the Media Creation Tool and the ISO download flow are the trusted path there, so your verification layer is "downloaded from microsoft.com over HTTPS" rather than a hash comparison. And when a check fails, the procedure is strict: do not use that file, delete it, re-download from the official source (ideally on a different network if you are on public Wi-Fi), and re-verify. If two independent downloads both fail verification against the published value, stop and report it to the project rather than trying to install — a mismatch means either your connection is being altered or something upstream changed, and neither is worth finding out about during an installation.

All three tools below are free and from established sources, but they solve different problems, and picking wrong costs you a redo. Rufus (official site: rufus.ie; also distributed through the Microsoft Store) is a Windows-only utility built specifically around the "one image, one drive, target firmware known" workflow: it formats the drive with the partition scheme you choose (GPT for UEFI, MBR for legacy BIOS), writes the boot files correctly for that scheme, and handles the awkward cases — most notably converting an oversized install.wim so a large Windows ISO fits on FAT32. Its interface exposes exactly the settings section 6 needs. Ventoy (ventoy.net) inverts the model: you install its boot manager to the USB once, and from then on adding an operating system means nothing more than copying ISO files onto the drive — multi-boot by default, no reformatting per image. balenaEtcher (etcher.balena.io) is a cross-platform flasher that writes images byte-for-byte (the same operation as the classic dd command) and verifies the result; it is the natural choice for raw images and Linux distros on any operating system, but it offers no partition-scheme selection and no Windows-specific handling.

The decision rules that follow from the table: making a Windows installation drive on a Windows PC → Rufus (or Microsoft’s own Media Creation Tool, which does the same job with fewer options — both are covered in section 6). Building a multi-boot rescue kit you will keep for years → Ventoy. Making a Linux live or install stick on macOS or Linux, or flashing a raw image → balenaEtcher. Two honesty notes: no tool supports every operating system and image format combination — Rufus is the strongest generalist on Windows, but if your image is an unusual vendor bundle, check that tool’s documentation before assuming it can handle it; and "free" tools from unofficial mirrors are not the same product as the ones at the official URLs above, so download only from those destinations. If you are choosing between Rufus and the Media Creation Tool for Windows specifically, either is fine — the MCT is Microsoft’s own path and always targets the current release, while Rufus gives you the partition-scheme controls that matter when the target machine’s firmware mode is unusual.

The steps below are the same skeleton for every tool; the differences live in step 6, where each tool’s controls are covered specifically. One framing note before you start: exact control names and option layouts vary by tool version and by the operating system running the tool. Rufus 4.x, for example, shows a different set of advanced options than Rufus 3.x did, and a Linux-hosted Ventoy installer labels things slightly differently from its Windows build. Where this guide names a specific dropdown or button, treat it as "find the setting that does this" rather than "the pixel-exact location", and check the tool’s own documentation when in doubt — the intent of each setting is stable even when its label moves.

1. Prepare the computer and the USB drive. Unplug every other removable drive so there is no ambiguity about which device you are about to erase. Confirm the target stick is the one from your preparation checklist (section 3) — match capacity and manufacturer label, not just the drive letter. Make sure the computer has stable power (a laptop plugged in) and that you have an account that can install software or approve administrator prompts.
2. Download the correct image from its official source (section 4): the right operating system, the right edition family if the choice matters to you, and the architecture of the target machine — 64-bit for anything sold in the last decade or so. "Correct" also means current: an installation ISO from several generations ago will install an operating system that is already out of support before first boot.
3. Verify the image where verification information exists (section 4). For Linux images with published SHA-256 values, run the comparison now — it takes under a minute and converts a later mysterious failure into a known-good starting point. For Windows ISOs obtained through Microsoft’s own tooling, note the download completed without error and move on.
4. Launch the creation tool with administrator rights. Writing to a removable drive requires elevated access on most systems: run Rufus as administrator, or start Ventoy’s installer with elevated privileges. A tool that cannot see your drive in its device list is almost always an permissions problem before it is a hardware problem.
5. Select the correct USB device — and verify the selection out loud. In the tool’s drive selector, confirm the entry shows the capacity and vendor label of your stick. If you see more than one removable device, stop and unplug the ones you do not mean to erase. This is the single highest-stakes click in the whole procedure: every tool on this page will happily format whatever you point it at.
6. Choose the image and the partition settings for your target machine. Point the tool at the downloaded file, then set the layout to match how the target computer boots: UEFI firmware wants GPT (with a FAT32 EFI System Partition on Windows media), legacy BIOS wants MBR. The tool-specific details for Rufus, Ventoy and balenaEtcher follow below.
7. Start the write and wait for it to finish completely. Do not unplug the drive, sleep the computer or close the window while the progress bar moves — interrupting a write leaves a drive that is neither the old contents nor valid media. Expected times: roughly three minutes for a ~6 GB image over USB 3.x on a modern machine, ten to fifteen over USB 2.0, longer still on older hardware. Each tool signals completion differently (a "READY" status, a success dialog, a verification summary) — trust only that explicit signal, not the moment the progress bar first reaches the end.
8. Eject safely and label the finished drive. Use the system’s safe-eject (or wait for the tool to finish its final sync), unplug, and apply the physical label from section 3. A completed, labeled stick is now a durable asset: it can be stored for months and still boot — the boot files do not expire, though the operating-system version it installs does age.

With Rufus (Windows host)

Rufus opens with the drive already selected — verify it is yours. Set Boot selection to "Disk or ISO image" and browse to your file (for Windows media, Rufus can also accept the extracted contents). Then the two settings that determine whether the target machine will accept the drive: Partition scheme — GPT for a UEFI target, MBR for a legacy BIOS target — and Target system, which Rufus derives from your choice (UEFI or CSM/Legacy BIOS). File system follows automatically in most cases (FAT32 for UEFI); if the image contains a file larger than 4 GB and you are on a UEFI/FAT32 target, Rufus offers to convert install.wim to an ESD stream — accept it, that is the standard fix. Click START; after the format completes, the status bar reads READY when the drive is done. Rufus also supports "DD image" mode for raw images — choose it only when your source is actually a raw .img, not a Windows ISO.

With Ventoy (any host OS)

Ventoy’s installer asks for the target disk and, on first install, formats it with its own layout — UEFI+BIOS hybrid by default, so the same stick can boot in either firmware mode. Confirm the disk selection the same way as everywhere else (capacity + vendor label), accept the format warning knowingly, and let the install finish; it takes under a minute because Ventoy writes only its small boot manager, not an operating system. After that, adding operating systems is just file copying: drag ISO, WIM, IMG or EFI files onto the drive like any folder. Two maintenance notes: when Microsoft ships a Windows build newer than Ventoy’s built-in support, the boot menu offers a plugin update — run it from the menu rather than reinstalling; and if you ever want to return the stick to ordinary use, reformatting it normally removes Ventoy completely.

With balenaEtcher (any host OS)

Etcher’s flow is three screens: Flash from file (choose your image), then target selection, then a write-and-verify run. The target screen shows each removable device with its label and size — click the one that matches your stick; Etcher deliberately makes you confirm the target explicitly, which is exactly the behavior you want. There are no partition-scheme options: Etcher writes the image byte-for-byte as it is, which is correct for Linux distribution ISOs (they carry their own boot layout) and raw images, but it is why Etcher is not the recommended path for Windows installation media — those need the scheme-specific handling Rufus or the Media Creation Tool provide. When the run finishes, Etcher reports the verification result; a completed verification means every byte on the stick matches the source image.

To start from the stick, the firmware must be told to look at the USB device before the internal disk. Most computers offer a one-time boot menu — a list of bootable devices shown for one boot cycle, after which normal order resumes — and that is the cleanest way to test media without changing any permanent settings. Here is where this guide is deliberately specific: there is no universal key. The key differs by manufacturer and often by model year, and guessing through F8/F10/F11/F12/Esc at every power-on works sometimes but is not a method. The reliable way to find the correct one for your machine: (1) look at the brief splash screen during power-on — many systems print "Press <key> for Boot Options" there for a second or two, so power on and watch rather than stare at the logo; (2) search the manufacturer’s official support site for your exact model plus "boot menu" or "boot options" — vendor documentation names the key per model, and this is the source to trust over third-party key lists that go stale; (3) consult the firmware manual that shipped with the machine if you have it. Some brands use a two-step dance (an Esc-style "startup menu" that then offers the boot device list), which is why step 2 matters more than memorizing keys.

If no one-time menu appears, or you want to change the permanent order instead, the path is through UEFI firmware settings — commonly reached by a dedicated key at power-on (again: model-specific, find it the same way) or, on a machine that still boots into Windows, without any key at all: Settings > System > Recovery > Advanced startup > Restart now, then Troubleshoot > UEFI Firmware Settings. Inside firmware, look for a "Boot" section listing devices in order — move the USB entry above the internal disk to test permanently, or use its one-time-boot option if offered. When you are done testing, restore the original order so the machine behaves normally; leaving a dead stick at the top of the boot list is a classic cause of "my PC won’t start" confusion later.

Three firmware-level factors decide whether a valid drive boots at all. Boot mode: if the machine is set to UEFI-only, it will ignore MBR-formatted media (and vice versa on legacy-only systems) — a mismatch shows up as "USB present but not offered" or "not a bootable device", and the fix is either recreating the media with the matching scheme (section 6) or switching the firmware’s mode where it offers both. Secure Boot: official images carry signed bootloaders and should start with Secure Boot enabled; if you see a signature or policy error, section 10’s decision tree covers the safe order of checks before anyone disables anything — disabling Secure Boot is reversible but does lower the machine’s security posture while off, so it is a deliberate step, not a reflex. USB boot restrictions: some systems (corporate-managed machines in particular, and a minority of consumer laptops) hide USB devices from the boot list entirely by policy or firmware setting; if your stick is healthy and correctly made but never appears, check the firmware’s boot configuration for a disabled USB option before doubting the media — and on managed hardware, the restriction may simply be unchangeable by design. The deeper mechanics of all this live in the Motherboard & BIOS/UEFI guide.

A successful boot has recognizable signatures, and knowing them separates "it is working, be patient" from "this is failing, stop and diagnose". From a Windows installation USB, expect the firmware to hand off within seconds to a black screen with a spinner or "Starting Windows", then a language-selection screen — on many images a "Press any key to boot from CD/USB" prompt appears first and expires after a few seconds, so be ready at power-on. From a Linux image, expect either a GRUB-style menu (with "Start Ubuntu" / "Try" and "Install" entries) or a direct fade into the live desktop; from a recovery environment, a repair menu with options like Troubleshoot, Startup Repair or Command Prompt. If instead you get a repeated "Reboot and select proper boot device" message, the firmware found no bootable code on the stick at all — that is a media or scheme problem (section 10), not a waiting game. And if the screen goes black with a still-active disk light for several minutes, remember that USB-based installs are genuinely slow on first load: give it ten minutes of actual disk activity before calling it hung.

When a live environment is available — every mainstream Linux install image provides one, and it is the best free test bench you will ever use — spend five minutes in it before any installation. Things worth checking while nothing is at risk: does the display run at the panel’s native resolution (a driver gap here usually resolves itself after install, but a total black screen on the live session predicts problems); does the network connect, wired or Wi-Fi (Wi-Fi failures in live mode often mean the distro lacks that adapter’s driver — know it before you commit to the OS); is the internal disk visible and readable from the file manager; does audio output work? The critical conceptual point: trying a live environment and installing are different operations. The live session runs in RAM and writes nothing to your disks by default — you can restart into your normal system with zero trace of it. Installing is the operation that modifies the target disk, and it should only start once the live check has answered the question "will this hardware actually run this operating system?"

Before any installation begins — Windows or Linux — four verifications prevent the disasters people describe in forums. (1) Disk selection: in the installer’s drive screen, match the target disk by capacity and label against what you intend to install on; on a machine with several disks, confirm which one holds your data before anything is formatted, because "Disk 0" means nothing without that cross-check. (2) Backups: if there is any chance the installer’s partition step could touch a disk you did not mean to format — including by mistake clicking the wrong entry — back up that disk first; the live environment from the previous paragraph exists precisely to make this backup possible when the installed system is the problem. (3) Encryption keys: if the target machine uses BitLocker or full-disk encryption, have the recovery key saved and testable before installation — an encrypted disk whose key you cannot produce becomes unreadable after any partition change, with no second chance. (4) What survives: know in advance which partitions the installer will leave untouched; a clean install of Windows on one disk does not by itself format your other disks, but it is the moment when that assumption should be verified, not assumed.

The most common rescue job is also the simplest: getting files off a machine that no longer boots into its own disk. Boot the target machine from a Linux live USB (section 8), open the file manager, and the internal drive’s partitions appear as mountable volumes — NTFS partitions from a Windows disk are readable out of the box on mainstream distros. Connect an external drive or network storage, and copy what matters: documents, photos, browser profiles, project folders. Two discipline rules make this safe. First, prefer read-only access: many file managers let you mount a partition read-only (or it can be done from a terminal), which guarantees the rescue session cannot alter the disk you are trying to preserve — with failing hardware especially, every unnecessary write is a coin flip. Second, copy in order of irreplaceability: unique documents and photos before anything re-downloadable, so that if the drive degrades mid-copy (it may), what you lost was the least painful. If a partition will not mount at all — corruption or an encryption layer you cannot open — stop writing to it and treat that as the "seek professional help" situation below, not a puzzle for more tools.

Beyond file rescue, bootable media supports three other safe workflows. Diagnostics outside the failing system: memory tests (MemTest86 from a live USB runs overnight and catches RAM errors that no in-OS test can see reliably), disk health readings (SMART attributes tell you whether a drive is statistically about to fail — the same data the Hard drives & SSDs guide explains), and driver/hardware probing from a live session. These are all read-oriented: they measure the machine without changing it, which is exactly what you want before deciding between repair and replacement. Windows recovery media: Windows can create its own kind of bootable USB — the Recovery Drive wizard (recoverydrive.exe, documented by Microsoft at support.microsoft.com) produces a drive that boots into the Windows Recovery Environment (WinRE) with Startup Repair, command prompt, system image restore and reset options (Microsoft’s WinRE overview). Note the distinction from section 1: a recovery USB repairs an existing Windows installation; it does not replace it unless you explicitly choose reset. A working reference system: a live USB also serves as a clean machine to check email, print documents or test peripherals while the real system is down — useful in ways that are easy to forget when everything else is broken.

The line between "safe rescue work" and "making it worse" is drawn by one question: does this operation write to the disk I am trying to save? Read-only diagnostics, file copies out, and running tests from RAM are all on the safe side; partitioning, formatting, reinstalling over the system volume or running aggressive repair tools that rewrite boot records are not — each of them narrows your remaining options and, on damaged media, can convert a recoverable situation into an unrecoverable one. That is why reinstalling the operating system is not the default answer to every boot failure: it destroys the evidence (logs, file state) that tells you what actually failed, and it is the wrong tool when the real problem is hardware, a missing driver or a corrupted update that a targeted repair would have fixed. The ordered repair procedures for a Windows machine that will not start — Startup Repair first, then targeted tools, with reinstallation last — are covered in the Startup & Boot guide and the recovery-tools library; this section’s job is to keep you on the safe side of the write line until those procedures have had their chance.

Finally, know when to stop and get professional help. The signals are physical, not software: a drive that clicks or grinds, repeatedly powers down and respins, disappears from the firmware’s device list intermittently, or shows SMART attributes in the failing range is degrading hardware — every additional power-on and retry session reduces the odds of full data recovery. If the data on such a drive is irreplaceable (the only copy of years of documents or photos), the proportionate move is: stop using the machine, keep the drive powered off if practical, and take it to a professional data-recovery service before running any further tools — even gentle ones. "It probably just needs a reinstall" is the most expensive sentence in computer repair when said about a failing disk with irreplaceable data.

Almost every bootable-USB failure falls into one of eight families, and the correct first action differs between them — which is why guessing ("recreate it three times") wastes an afternoon while diagnosis takes ten minutes. Use the decision tree below for a guided walk: pick your symptom, answer two or three questions, and it ends with a concrete next step and the safety note that applies. Below that, the symptom index lists all eight families with their likely causes and safe diagnostics in one searchable place — filter by category or search for a keyword like "secure boot" or "black screen". Both cover the same ground; pick whichever shape you prefer. One rule applies to every branch: recreate the media before doubting the hardware, and verify the image before recreating — a corrupt source file will produce the identical failure however many times you rewrite it.

Symptom index — all eight failure families

8 of 8 symptoms shown

No symptoms match your current filters — try a different keyword or reset the category.

The checklist below is the acceptance test for everything this guide produced: the first group confirms the media itself was created correctly, the second confirms the first boot actually succeeded. Tick items as you verify them — your progress is saved in this browser between visits, and the reset button starts over. A USB that passes both groups is a durable asset: store it labeled, keep the image’s version noted on the label (so you know what generation of operating system it installs), and re-verify the source image only when you need a current release.

Frequently asked questions

Where this guide stops, these pick up — the full Windows 11 installation walkthrough, the firmware layer underneath, and the ordered repair paths for machines that will not start.

References

• Download Windows 11 — Microsoft · the official source for the Media Creation Tool and Windows 11 ISO images; also the route for current Windows 10 media via Microsoft’s equivalent page.
• Recovery Drive — Microsoft Support · how the Windows recovery-drive wizard works and what the resulting USB contains.
• Windows Recovery Environment — Microsoft Support · the repair environment a recovery USB boots into, and its options.
• Rufus — official site · downloads (signed executable) and documentation; also distributed via the Microsoft Store listing.
• Ventoy — official download page · the multi-boot USB tool, its installer and plugin-update documentation.
• balenaEtcher — official site · the cross-platform image flasher used for Linux images and raw files.
• Ubuntu downloads — canonical · official Ubuntu images, with published checksums alongside each release.
• How to verify your Ubuntu download — Ubuntu tutorials · the official walkthrough for checksum and GPG signature verification of Ubuntu images.