Upgrade from Windows 10 to Windows 11 in Place: Check Compatibility, Back Up First, Run the Upgrade and Verify Drivers Survive

An in-place upgrade runs the Windows 11 setup program on top of your running Windows 10 installation. During the process, setup stages new system files in a temporary folder (usually C:\$WINDOWS.~BT), then across several reboots swaps the operating system while leaving your user profiles, personal files and — if you choose the "keep apps and settings" option — most of your installed applications in place. The old system is preserved as C:\Windows.old, which is what makes the ten-day rollback in section 17 possible. Nothing you do in this guide erases a partition: the disk layout, drive letters and everything on any other disk stay exactly where they are.

The reason to move at all is no longer optional comfort — it is the support clock. Standard support for Windows 10 ended on October 14, 2025, so a normal Windows 10 installation no longer receives routine security updates. Microsoft offered time-limited paid Extended Security Updates (ESU) for some situations: the commercial ESU program covers Pro, Enterprise and Education editions in commercial use, and a short consumer purchase window existed for Home devices in late 2025 — but as of this writing there is no ongoing free update path for Windows 10. On the other side of the upgrade, Windows 11 24H2 is the current mainstream release (the interim 23H2 build for Home and Pro reached end of support in October 2025), so an in-place upgrade from a current Windows 10 build lands you on a supported version. If you stay on Windows 10, you are making a deliberate risk decision about unpatched security flaws — which is fine to make, but make it with that fact in front of you.

The in-place upgrade is the right tool when three conditions hold: your hardware meets the Windows 11 requirements, you want to keep your applications and settings rather than rebuilding them, and your current installation is healthy enough to run setup. It is the wrong tool in a few situations. If the PC does not meet the hardware bar, an in-place upgrade is not something you can legitimately complete — section 13 covers what that actually means and which workarounds are defensible versus which ones quietly trade away future updates. If Windows 10 itself is badly damaged (boot loops, corrupted system files that SFC/DISM cannot fix), setup may fail before it starts doing useful work; in that case the clean-install walkthrough is the better route, because a clean install does not depend on the old installation being functional. And if you only want current updates without touching your software, Windows Update already does that on a supported OS — an upgrade is for moving operating systems, not applying patches.

Here is the shape of what follows, in five phases. Prepare (sections 2–6): prove compatibility with evidence, back up and then verify the backup, and give the disk room to work. Upgrade (sections 7–9): run setup through the Installation Assistant or from official media, choosing the option that keeps your apps and files, and understand what "keep" actually guarantees. Drivers (sections 10–12): record a baseline before you start, then verify Wi-Fi, audio, graphics and Bluetooth genuinely work afterwards — not just that Device Manager shows no warning triangles. When things go wrong (sections 13–18): diagnose compatibility blocks, stalled progress and error codes from the setup logs, follow the recovery decision tree for a failed upgrade, use rollback within its limits, and repair missing drivers on a system that at least boots. Verify and plan (sections 19–20): run an automated post-upgrade verification script and finish with a checklist plus a written readiness report you can keep with the backup. The expected result of doing all of this is a supported Windows 11 installation with your files, working drivers and a documented paper trail — or, if something fails, a known recovery path instead of a guess.

Windows 11 is the first consumer release where Microsoft enforces a hardware floor at install time, and the floor exists for concrete reasons: features like hardware-based security (Virtualization-Based Security, Credential Guard) assume TPM 2.0 and Secure Boot, and the driver support commitment assumes CPUs from roughly the last decade. The official bar is: a supported 64-bit CPU, 4 GB of RAM, 64 GB of storage, TPM 2.0, UEFI firmware with Secure Boot capability, a DirectX 12-compatible GPU with a WDDM 2.x driver, and a display of at least 720p. The table below pairs each requirement with how to check it on your machine and what a failure actually implies — because "fails the CPU check" and "has no TPM chip" lead to very different decisions.

The fastest whole-machine check is Microsoft’s PC Health Check app (free from the Microsoft Store or the Windows 11 download page): it runs all the eligibility tests and shows a single "This PC can run Windows 11" verdict, with an "Upgrade now" button when you are on Windows 10. Settings > System > Activation on Windows 10 also surfaces a device-specification message when the hardware is not supported. Treat both as summaries, though — they tell you the verdict but not which requirement drives it. That distinction matters: a PC that fails only because its firmware TPM is switched off is a ten-minute BIOS change away from eligibility (section 13 walks through that), while a PC with an unsupported CPU is not fixable in software at all. Running the individual checks yourself — even just noting the CPU model, TPM state and Secure Boot state — gives you the evidence you need to make that distinction instead of accepting a bare "not supported".

Two honest caveats about what a passing check does and does not promise. First, meeting the requirements does not guarantee every driver or application will survive — it guarantees Microsoft will support the platform; individual components like fingerprint readers, vendor utilities or older GPUs can still misbehave, which is exactly why sections 10–12 record a baseline and verify afterwards. Second, failing a check does not mean the machine literally cannot run Windows 11 — it means Microsoft will not support that configuration, updates are not guaranteed, and some security features may be unavailable. People do install on unsupported hardware using unofficial workarounds; section 13 explains what those workarounds actually change so you can decide for yourself, but this guide does not walk through them as a recommended procedure.

The PC Health Check app gives you a verdict, but it does not give you a record. A small PowerShell script fixes that: it reads the same facts the eligibility check uses — OS build, CPU model, memory, storage capacity and free space, TPM state, Secure Boot state — and prints each one as PASS, WARN, FAIL or INFO, so the decision "is this machine eligible" becomes something you can re-run, screenshot and keep with your backup. The script below is deliberately read-only: it inspects the system and writes nothing, changes no settings, and never starts an upgrade. It runs on Windows 10 (and reports gracefully if pointed at a machine that is already on Windows 11).

# =============================================================
#  DiagMyPCHub - Windows 11 in-place upgrade: readiness check
#  READ-ONLY. This script only inspects the system and prints a
#  report. It changes no settings, installs nothing and never
#  starts an upgrade. Run it from a normal (non-admin) PowerShell
#  window on the Windows 10 machine you are about to upgrade.
# =============================================================

$ErrorActionPreference = 'Stop'
$results = New-Object System.Collections.ArrayList

function Add-Result {
    param(
        [string]$Check,
        [ValidateSet('PASS','WARN','FAIL','INFO')][string]$State,
        [string]$Detail
    )
    [void]$script:results.Add([pscustomobject]@{ Check = $Check; State = $State; Detail = $Detail })
}

Write-Host ''
Write-Host '=== Windows 11 in-place upgrade readiness check ==='
Write-Host ('Checked on {0} - {1}' -f (Get-Date).ToString('yyyy-MM-dd HH:mm'), $env:COMPUTERNAME)
Write-Host ''

# ---------- Operating system ----------
$os = Get-CimInstance Win32_OperatingSystem
$build = [int]$os.BuildNumber
if ($build -ge 22000) {
    Add-Result 'Operating system' 'INFO' ('Already running Windows 11 (build {0}). Nothing to upgrade.' -f $build)
}
elseif ($os.Version -like '10.0.*') {
    if ($build -ge 19045) {
        Add-Result 'Operating system' 'PASS' ('Windows 10 build {0} - a supported in-place source.' -f $build)
    } else {
        Add-Result 'Operating system' 'WARN' ('Windows 10 build {0}. Bring Windows Update fully current before upgrading; very old builds may need several update rounds first.' -f $build)
    }
}
else {
    Add-Result 'Operating system' 'FAIL' ('Unexpected OS version {0}.{1} - this script targets Windows 10.' -f $os.Version, $build)
}

# ---------- Processor ----------
$cpu = (Get-CimInstance Win32_Processor | Select-Object -First 1).Name.Trim()
Add-Result 'Processor' 'INFO' $cpu
$cpuState = 'WARN'
$cpuNote = 'Verify this exact model against the Microsoft supported CPU list before upgrading.'
if ($cpu -match '(?i)intel.*core') {
    if ($cpu -match '(?i)i[3579]-([4-9]\d{3})|i[3579] ([4-9]\d{3})') {
        $gen = [int]$Matches[1].Substring(0,1)
        if ($gen -ge 8) {
            $cpuState = 'PASS'
            $cpuNote = ('Intel Core (model number indicates generation {0} or newer) - check the official list to be certain.' -f $gen)
        } else {
            $cpuState = 'FAIL'
            $cpuNote = 'Model number suggests pre-8th-generation Intel Core - not on the supported list.'
        }
    }
    elseif ($cpu -match '(?i)pentium|celeron|atom') {
        $cpuState = 'FAIL'
        $cpuNote = 'Intel Pentium, Celeron or Atom parts are not supported for Windows 11.'
    }
}
elseif ($cpu -match '(?i)amd.*ryzen') {
    if ($cpu -match '(\d{4})') {
        $series = [int]$Matches[1]
        if ($series -ge 2000) {
            $cpuState = 'PASS'
            $cpuNote = ('AMD Ryzen (series {0}, Zen 2 generation or newer by model number) - check the official list to be certain.' -f $series)
        } else {
            $cpuState = 'FAIL'
            $cpuNote = 'Model number suggests first-generation Ryzen - not on the supported list.'
        }
    }
}
elseif ($cpu -match '(?i)xeon|epyc') {
    $cpuState = 'WARN'
    $cpuNote = 'Server-class CPU. A small number of Xeon/EPYC parts are supported - verify this exact model against the Microsoft list.'
}
Add-Result 'CPU support (heuristic)' $cpuState $cpuNote

# ---------- Memory ----------
$ramGb = [math]::Round((Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory / 1GB, 1)
if ($ramGb -ge 4) {
    Add-Result 'Memory' 'PASS' ('{0} GB installed (minimum 4 GB).' -f $ramGb)
} else {
    Add-Result 'Memory' 'FAIL' ('{0} GB installed - below the 4 GB minimum.' -f $ramGb)
}

# ---------- Storage ----------
$vol = Get-Volume -DriveLetter C -ErrorAction SilentlyContinue
if ($vol) {
    $capGb = [math]::Round($vol.Size / 1GB, 0)
    $freeGb = [math]::Round($vol.SizeRemaining / 1GB, 0)
    if ($capGb -ge 64) {
        Add-Result 'Storage capacity' 'PASS' ('C: total {0} GB (minimum 64 GB).' -f $capGb)
    } else {
        Add-Result 'Storage capacity' 'FAIL' ('C: total {0} GB - below the 64 GB minimum.' -f $capGb)
    }
    if ($freeGb -ge 30) {
        Add-Result 'Free space on C:' 'PASS' ('{0} GB free - comfortable headroom for the upgrade.' -f $freeGb)
    }
    elseif ($freeGb -ge 20) {
        Add-Result 'Free space on C:' 'WARN' ('{0} GB free - the upgrade will probably fit, but free up more space to be safe.' -f $freeGb)
    } else {
        Add-Result 'Free space on C:' 'FAIL' ('{0} GB free - free up at least 20-30 GB before starting (see the disk-space section).' -f $freeGb)
    }
}
else {
    Add-Result 'Storage capacity' 'WARN' 'Could not read the C: volume. Check it manually in File Explorer.'
}

# ---------- TPM ----------
try {
    $tpm = Get-Tpm
    if ($tpm.TpmReady) {
        Add-Result 'TPM 2.0' 'PASS' ('TPM present and ready (version {0}).' -f $tpm.Version)
    }
    elseif ($tpm.TpmPresent) {
        Add-Result 'TPM 2.0' 'WARN' 'TPM is present but not active - enable it in the firmware settings (often under Security or Authentication).'
    }
    else {
        Add-Result 'TPM 2.0' 'FAIL' 'No TPM reported by Windows. Check whether the firmware has a disabled or firmware-based TPM option before concluding the hardware is missing.'
    }
}
catch {
    Add-Result 'TPM 2.0' 'WARN' 'Get-Tpm could not run on this system - check TPM status in tpm.msc instead.'
}

# ---------- Secure Boot ----------
try {
    $sb = Confirm-SecureBootUEFI
    if ($sb) {
        Add-Result 'Secure Boot' 'PASS' 'Secure Boot is enabled.'
    } else {
        Add-Result 'Secure Boot' 'WARN' 'Secure Boot is not active. Windows 11 requires UEFI firmware with Secure Boot capability - enable it in the firmware settings (it may require disabling CSM or legacy boot first).'
    }
}
catch {
    Add-Result 'Secure Boot' 'FAIL' 'Confirm-SecureBootUEFI failed - this system may be running legacy BIOS mode, which Windows 11 does not support.'
}

# ---------- Graphics ----------
$gpu = (Get-CimInstance Win32_VideoController | Select-Object -First 1).Name
Add-Result 'Graphics' 'INFO' ('{0} - confirm the GPU supports DirectX 12 with a WDDM 2.x driver.' -f $gpu)

# ---------- BitLocker (informational) ----------
try {
    $blv = Get-BitLockerVolume -ErrorAction Stop | Where-Object { $_.VolumeType -eq 'OS' }
    if ($blv) {
        Add-Result 'BitLocker' 'INFO' ('OS volume is protected ({0}). Save the recovery key somewhere you can find it before upgrading.' -f $blv.ProtectionStatus)
    }
}
catch {
    Add-Result 'BitLocker' 'INFO' 'No OS-volume BitLocker protection detected (or not readable without admin).'
}

# ---------- Report ----------
$results | Format-Table -AutoSize | Out-String -Width 200 | Write-Host

$fails = @($results | Where-Object { $_.State -eq 'FAIL' }).Count
$warns = @($results | Where-Object { $_.State -eq 'WARN' }).Count
Write-Host ('Result: {0} blocking failure(s), {1} warning(s).' -f $fails, $warns)
if ($fails -gt 0) {
    Write-Host 'A FAIL on a hardware requirement (CPU, TPM, Secure Boot, RAM, storage) means this PC is not officially supported for Windows 11.'
    exit 1
}
elseif ($warns -gt 0) {
    Write-Host 'Resolve the WARN items (usually firmware settings or disk space) before starting the upgrade.'
}
else {
    Write-Host 'No blocking issues found. Cross-check the CPU against the Microsoft official list, then continue with the backup steps.'
}

To run it, open Notepad, paste the script, and save it as readiness.ps1 in a folder you own (for example your Documents folder — choose "All Files" as the file type so Notepad does not append .txt). Then open PowerShell from the Start menu and run powershell -ExecutionPolicy Bypass -File C:\Users\YOURNAME\Documents\readiness.ps1. The -ExecutionPolicy Bypass flag applies only to that one invocation and is the standard way to run a script you have just saved yourself; it does not change your machine’s policy. If you prefer, you can also select all the text in the file, copy it, paste it directly into an open PowerShell window and press Enter — the script behaves identically either way.

Reading the output: PASS means that requirement is satisfied as far as Windows can report it; FAIL on a hardware row (CPU, TPM, Secure Boot, memory, storage capacity) is a blocking result — the machine is not officially supported and you should stop and read section 13 before doing anything else; WARN means "probably fixable or worth checking" (a present-but-disabled TPM, insufficient free space, a CPU model the script cannot classify); INFO rows are context only. Note what the script deliberately does not do: it cannot confirm your exact CPU against Microsoft’s supported list (the CPU row is a model-number heuristic — always verify the printed model name against the official list yourself), and it cannot fully validate the GPU’s DirectX 12/WDDM 2.x status, so treat that INFO row as a reminder to check dxdiag. The script also exits with code 1 when any blocking FAIL is present, which matters if you ever run it across several machines in a loop.

=== Windows 11 in-place upgrade readiness check ===
Checked on 2026-03-14 09:12 - DESKTOP-7XK2M

Check                   State Detail
-----                   ----- ------
Operating system        PASS  Windows 10 build 19045 - a supported in-place source.
Processor               INFO  Intel(R) Core(TM) i5-10500 CPU @ 3.10GHz
CPU support (heuristic) PASS  Intel Core (model number indicates generation 8 or newer) - check the official list to be certain.
Memory                  PASS  16 GB installed (minimum 4 GB).
Storage capacity        PASS  C: total 476 GB (minimum 64 GB).
Free space on C:        WARN  24 GB free - the upgrade will probably fit, but free up more space to be safe.
TPM 2.0                 PASS  TPM present and ready (version 2.0).
Secure Boot             PASS  Secure Boot is enabled.
Graphics                INFO  NVIDIA GeForce GTX 1650 - confirm the GPU supports DirectX 12 with a WDDM 2.x driver.
BitLocker               INFO  No OS-volume BitLocker protection detected (or not readable without admin).

Result: 0 blocking failure(s), 1 warning(s).
Resolve the WARN items (usually firmware settings or disk space) before starting the upgrade.

The in-place upgrade is designed to keep your files, and on a healthy machine it usually does — but "usually" is not a backup strategy. The realistic failure modes are: the upgrade aborts mid-flight on a disk that turns out to be failing (the stress of copying tens of gigabytes is exactly what exposes weak drives), a power loss during one of the reboots, or a post-upgrade problem where you decide to start over from scratch and wish you had known which files mattered. The rollback in section 17 restores the operating system state from Windows.old, but it only exists for ten days, it disappears the moment you clean up old Windows installations, and it never protects data that lives outside the upgraded volume. The only protection that works in all of these cases is a copy of your important files on a different physical device — an external USB drive or a second internal disk, not another folder on C:.

The workhorse approach for an upgrade is a one-time, deliberately scoped copy of your user profile to the external drive, run with robocopy, which is built into Windows and far more reliable than drag-and-drop for large trees. The command below copies everything under your profile (Documents, Desktop, Downloads, Pictures, Music, Videos) while skipping junction points and tolerating a couple of transient read errors. Replace E:\Backup\YOURNAME with the real path on your external drive and C:\Users\YOURNAME with your actual profile folder. If you keep important data outside the profile — a D: drive full of projects, for example — add a second robocopy run for it. Note that robocopy exit codes 0–7 all mean success (they encode "files copied" / "extra files present" flags); 8 and above are real errors.

robocopy "C:\Users\YOURNAME" "E:\Backup\YOURNAME" /E /XJ /R:2 /W:5 /NP /NDL

rem Second run for anything important that lives outside your profile, e.g. a D: drive:
rem robocopy "D:\Projects" "E:\Backup\Projects" /E /XJ /R:2 /W:5 /NP /NDL

Three judgment calls are yours to make, and each one is worth thinking about explicitly rather than defaulting. Scope: if the full profile copy will take many hours because of a huge media library, back up the irreplaceable things first (documents, photos, work, project source) and let the rest wait — an upgrade should not be held hostage by 2 TB of video files you can re-download. Encryption: if your C: drive is protected with BitLocker, the OS volume’s recovery key must be saved somewhere you can find it (your Microsoft account or a printed copy) before any operation that touches the disk — an upgrade can trigger a BitLocker recovery prompt, and without the key the drive locks. Applications: file copies do not back up installed programs. For anything you would hate to reinstall (licensed software with keys you have not written down, custom-configured tools), spend ten minutes now noting the product name, version, license location and any profile or settings folders it uses — that list is what section 9 turns into a post-upgrade reinstallation plan.

A backup that has never been tested is an assumption, and assumptions are exactly what this whole guide is trying to remove. The common silent failures are unglamorous: the external drive was never connected long enough to finish copying, it filled up halfway through a large tree, a folder of files you assumed were copied actually sits in a location robocopy did not reach, or the drive itself has developed bad sectors that will surface precisely when you need to read them back. None of these show up as an error on backup day — the copy "finished" — and all of them turn into a very expensive discovery during the one window when your patience is lowest. Verification costs ten minutes; the alternative costs the data.

The practical verification method has four layers, each answering a different question. 1. Does the destination exist and is it healthy? Check the backup volume’s health status — a drive reporting anything other than "Healthy" disqualifies itself as a backup target until it is fixed or replaced. 2. Is there actually data there? Count files and total size in the backup folder; zero files means nothing happened, and a total far below your profile’s real size means the copy was incomplete. 3. Is it current? Look at the newest file in the backup — if its timestamp is days older than files you have obviously been working on, run another pass before upgrading. 4. Can specific recent files be found there with matching sizes? Pick five recently touched documents from your Documents folder and confirm each one exists in the backup with the same byte size. Opening a sample or two directly from the backup (not from C:) is the final proof that the copies are readable, not just present.

# =============================================================
#  DiagMyPCHub - Verify a backup before an in-place upgrade
#  READ-ONLY. Confirms the backup location exists, is healthy and
#  contains recent copies of your files. It never writes to or
#  modifies the backup. Replace E:\Backup with YOUR path first.
# =============================================================

$ErrorActionPreference = 'Stop'
$backupRoot = 'E:\Backup'   # <-- change this to your real backup folder

Write-Host ''
Write-Host '=== Backup verification ==='
Write-Host ''

# 1. The location must exist and be a folder
if (-not (Test-Path -LiteralPath $backupRoot)) {
    Write-Host ('FAIL: path not found: {0}' -f $backupRoot)
    exit 1
}
Write-Host ('PASS: backup location exists: {0}' -f $backupRoot)

# 2. The volume holding the backup must be healthy
$drive = ($backupRoot -split '\\')[0]
$diskLetter = ($drive -replace ':','')
$vol = Get-Volume -DriveLetter $diskLetter -ErrorAction SilentlyContinue
if ($vol) {
    Write-Host ('INFO: volume {0} ({1}) health = {2}, free = {3} GB' -f `
        $vol.FileSystemLabel, $diskLetter, $vol.HealthStatus, [math]::Round($vol.SizeRemaining/1GB,1))
    if ($vol.HealthStatus -ne 'Healthy') {
        Write-Host 'WARN: the backup volume is not reporting Healthy. Do not start the upgrade until this is fixed.'
    }
}

# 3. Count files and total size in the backup
$measure = Get-ChildItem -LiteralPath $backupRoot -Recurse -File -ErrorAction SilentlyContinue |
    Measure-Object -Property Length -Sum
if ($measure.Count -eq 0) {
    Write-Host 'FAIL: the backup folder contains no files. Nothing has actually been backed up.'
    exit 1
}
Write-Host ('PASS: {0} files, {1} GB total in the backup' -f $measure.Count, [math]::Round($measure.Sum/1GB,2))

# 4. How recent is the newest file in the backup?
$newest = Get-ChildItem -LiteralPath $backupRoot -Recurse -File |
    Sort-Object LastWriteTime -Descending | Select-Object -First 1
$ageDays = [math]::Round(((Get-Date) - $newest.LastWriteTime).TotalDays, 1)
Write-Host ('INFO: newest file in backup: {0} (written {1} days ago)' -f $newest.FullName, $ageDays)
if ($ageDays -gt 7) {
    Write-Host 'WARN: the newest backed-up file is more than a week old. Run another backup pass before upgrading.'
}

# 5. Spot-check: pick 5 recent documents from YOUR profile and confirm copies exist in the backup
$profileDocs = Get-ChildItem (Join-Path $env:USERPROFILE 'Documents') -File -ErrorAction SilentlyContinue |
    Sort-Object LastWriteTime -Descending | Select-Object -First 5
$missing = 0
foreach ($f in $profileDocs) {
    $inBackup = Get-ChildItem -LiteralPath $backupRoot -Recurse -File -Filter $f.Name -ErrorAction SilentlyContinue |
        Where-Object { $_.Length -eq $f.Length } | Select-Object -First 1
    if ($inBackup) {
        Write-Host ('PASS: found in backup (size match): {0}' -f $f.Name)
    } else {
        Write-Host ('FAIL: not found in backup with matching size: {0}' -f $f.Name)
        $missing++
    }
}

Write-Host ''
if ($missing -gt 0) {
    Write-Host ('Result: {0} recent file(s) missing from the backup. Copy them now, then re-run this script.' -f $missing)
    exit 1
}
Write-Host 'Result: backup location looks complete and current. You may proceed to the upgrade steps.'

If you made a full system image rather than (or in addition to) file copies, verification looks different because you cannot casually "open" an image: the meaningful test is restoring something from it. Most imaging tools let you browse the image and extract individual files or folders — do exactly that, restore one folder of documents to a scratch location on your PC, and compare it against the originals. A full boot-test of the image (restoring it to a second disk and starting from it) is the gold standard but is a heavy operation; for an upgrade decision, a successful file-level extraction plus a healthy source drive is proportionate evidence. Whatever the method, the passing criterion is the same: you have personally read data back from the backup, not just watched a progress bar.

The upgrade stages a large amount of intermediate data on the system drive before it swaps anything over — that is the $WINDOWS.~BT folder, which can easily occupy 20–30 GB or more depending on what setup downloads and compiles. Running out of space mid-staging is one of the most common causes of a failed in-place upgrade (it typically surfaces as error 0x80070070, "not enough disk space", covered in section 15). The requirement to aim for is therefore at least 20–30 GB free on C: before you start, with more being better if your drive is small or your Windows installation has accumulated years of update history. Freeing space is also a useful canary: a disk that barely has room to upgrade is often the same disk that is about to fail under load, so treat this step as a health check as much as a chore.

Clean up in order of safety and effort. First, Storage Sense (Settings > System > Storage): it removes temporary files and empties the Recycle Bin automatically if you enable it, and its "Clean now" button handles the low-risk items immediately. Second, the classic Disk Cleanup tool: run cleanmgr for C:, then click "Clean up system files" and tick the large categories — "Previous Windows installations", "Windows Update Cleanup" and "Delivery Optimization Files" can together free many gigabytes on a machine that has been updated in place several times. Third, uninstall applications you no longer use (Settings > Apps > Installed apps) — this is the only step that shrinks what the upgrade has to carry forward, so it helps twice. Fourth, move large media to another drive or your backup drive if C: is still tight. What you should not do: manually delete anything inside C:\Windows, C:\$WINDOWS.~BT (unless a failed upgrade left it behind and section 16 tells you to clean it), or the WinSxS component store — hand-deleting system files is how "free up space" becomes "repair install". If Disk Cleanup with system-files mode does not get you to 20 GB, stop and rethink scope (a larger drive or a reset/clean route) rather than force-cleaning.

# =============================================================
#  DiagMyPCHub - Disk space inspection before an in-place upgrade
#  READ-ONLY. Shows every volume's free space so you can decide
#  what to move or clean up. It deletes nothing.
# =============================================================

Write-Host ''
Write-Host '=== Volumes ==='
Get-Volume | Where-Object { $_.DriveLetter } |
    Select-Object DriveLetter,
        @{n='Label';e={$_.FileSystemLabel}},
        @{n='GBTotal';e={[math]::Round($_.Size/1GB,0)}},
        @{n='GBFree';e={[math]::Round($_.SizeRemaining/1GB,0)}},
        HealthStatus |
    Format-Table -AutoSize

$freeC = (Get-Volume -DriveLetter C).SizeRemaining / 1GB
Write-Host ('C: has {0} GB free.' -f [math]::Round($freeC,1))
if ($freeC -lt 20) {
    Write-Host 'Below the ~20-30 GB of headroom an in-place upgrade typically wants. Free up space (Storage Sense, Disk Cleanup with "Clean up system files", move large media to another drive) and re-check.'
} else {
    Write-Host 'That is workable headroom for the upgrade staging area.'
}

Write-Host ''
Write-Host '=== Largest top-level folders on C: (first 15, by size) ==='
Get-ChildItem 'C:\' -Directory -Force -ErrorAction SilentlyContinue |
    Where-Object { $_.Name -ne 'PerfLogs' } |
    ForEach-Object {
        $size = (Get-ChildItem $_.FullName -Recurse -File -Force -ErrorAction SilentlyContinue |
            Measure-Object -Property Length -Sum).Sum
        [pscustomobject]@{ Folder = $_.Name; GB = [math]::Round($size/1GB,1) }
    } |
    Sort-Object GB -Descending | Select-Object -First 15 |
    Format-Table -AutoSize

Space is only half of "prepare". The other half is putting the operating environment into the state setup expects. Bring Windows 10 fully current first: open Windows Update and install every pending update, including feature updates if offered, then reboot until nothing is pending. In-place upgrades from a very old build are significantly more failure-prone than from a current one, because setup has to bridge a larger gap in system components. Create a restore point (search "create a restore point" → Create) as a cheap extra safety layer — the upgrade process makes its own recovery state, but a named restore point gives you a labeled landmark if anything goes sideways before the swap. Power and peripherals: plug a laptop in and do not start the upgrade on battery; unplug non-essential USB devices (external disks other than your backup, dongles, extra monitors) so nothing gets confused during the reboots. And one deliberate non-recommendation: this guide does not ask you to disable antivirus, Secure Boot or any security protection as a routine step — if a specific security product is documented by its vendor to interfere with OS upgrades, follow that vendor’s guidance for an upgrade window, but do not switch protections off "just in case" and leave them off.

The Installation Assistant is Microsoft’s single-file upgrade tool, downloadable from the official Windows 11 download page. It runs on your existing Windows 10 installation (no bootable media involved), checks the machine against the requirements, and then offers two roles: upgrading this PC now, or creating installation media for another PC. For most people it is the simplest supported route to an in-place upgrade, because it bundles the compatibility check, the download of the right build and the setup launch into one guided flow — and because it will refuse to start the upgrade on hardware that does not qualify, which keeps you from discovering a compatibility block at the worst possible moment.

1. Download the tool — go to Microsoft’s Windows 11 download page (linked in References) and choose "Download Windows 11 Installation Assistant". Verify you are on the genuine microsoft.com domain before running anything; this file is only a few MB and does not need to be large.
2. Run it — double-click the downloaded file and accept the User Account Control prompt. Read the license terms and continue.
3. Let it check the PC — the assistant runs its compatibility scan. On a supported machine it asks what you want to do: "Upgrade this PC now" or "Create installation media (USB flash drive, DVD or ISO file) for another PC". Choose the upgrade.
4. Choose what to keep — you will be asked whether to keep your personal files and apps, or only your personal files. For a standard in-place upgrade choose "Keep personal files and apps"; the other option is for when you want Windows 11 with your data but without your current application set.
5. Let it work — the assistant downloads the required components (staging them in C:\$WINDOWS.~BT), performs a pre-upgrade scan, then restarts the PC into the upgrade process. Expect several reboots and a total of roughly one to three hours on a typical SSD — longer on a slow HDD. Do not power off the machine during this window; if it looks frozen, section 14 explains how to tell "slow" from "stuck".

Under the hood, both this tool and the media route (next section) run the same setup engine — what differs is how you get there. The assistant’s pre-upgrade scan reports problems it can detect before committing: insufficient disk space, missing firmware features, or applications flagged as incompatible with the target version. Treat that scan output as input to your decision, not gospel: a warning about a specific application does not by itself mean the upgrade will fail (many flagged apps work fine), but it is exactly the kind of thing you want noted in your pre-upgrade list from section 9 so you can verify that app afterwards. If the assistant cannot start the upgrade at all, do not switch to the media route hoping it behaves differently — a hard block on one path is usually the same underlying hardware or system condition showing up on the other; diagnose it using sections 13 and 15 first.

One practical fact about this tool saves people a lot of confusion when things go sideways: cancelling or failing partway through is not a dead end. If you close the assistant, lose power, or the upgrade aborts, the machine returns to your working Windows 10 desktop and the staged components simply sit in C:$WINDOWS.~BT taking up space — they do not damage anything, and a later run of setup (assistant or media) reuses or replaces them as needed. You can clean that staging data away with Disk Cleanup’s system-files mode whenever you want the space back, and retry from a clean slate at any time. That reversibility is exactly why the assistant is a sensible first attempt: the cost of trying it on a properly backed-up machine is a wasted hour at worst, while the information you get back — how far setup got, what it flagged, whether your hardware passes its checks — is input to every later decision in this guide. What you should never do with a cancelled assistant run is assume it “undid” anything: check that your desktop, files and applications are exactly as they were before, because the staging phase is read-only on your data but the assumption of safety deserves a ten-second verification.

There is a distinction that trips up a lot of people, so it gets stated bluntly: running setup.exe from official installation media while logged into your running Windows 10 desktop performs an in-place upgrade. Booting the PC from that media and starting setup from the boot menu performs a clean install. The same ISO is both tools; what changes the outcome is where setup starts from. This section covers only the in-place route — for the boot-from-USB clean-install procedure, use the companion Install Windows 11 from a USB Drive walkthrough. Download the official ISO from Microsoft’s Windows 11 download page (the "Download Windows 11 Disk Image (ISO)" option), and verify the source domain as with any software: installation media should come from microsoft.com, never from third-party image repositories.

1. Mount the ISO — double-click the downloaded .iso file. Windows mounts it as a virtual drive (it appears in File Explorer with a drive letter); no burning or USB writing is needed for an in-place upgrade.
2. Start setup from the desktop — open the mounted drive and run setup.exe. You will see the familiar "Set up Windows" window. If asked how setup should download updates, letting it download now is the smoother default on a good connection; the other option downloads later during the process.
3. Choose what to keep — setup asks whether you want to keep your personal files and apps or only your personal files. Choose "Keep Windows 10 apps and settings" (worded slightly differently across builds) for the standard in-place upgrade. This is the option that preserves your application set.
4. Handle the product key screen — if your current edition’s activation is tied to this hardware, setup usually detects it and you can skip entering a key. If you deliberately want to change editions (for example, Home to Pro), enter the valid Pro product key here; that is the supported way an in-place upgrade changes editions. Do not enter a key for a different or unrelated edition "to be safe" — a mismatched key can steer setup into behaviour you did not intend.
5. Install and let it reboot — click Install. Setup stages files, then performs the same multi-reboot upgrade sequence as the assistant. Same rules apply: power connected, no interference, and section 14 for interpreting a long "working" screen.

Two constraints shape what the media route can do, and both are worth understanding before setup asks questions. Language must match: an in-place upgrade keeps the installation’s language; you cannot use French media to upgrade an English Windows 10 in place (setup will reject the mismatch). If you genuinely need a different language, that is a clean-install decision, not an in-place one. Edition must be the same or higher: Home media upgrades Home, Pro media upgrades Pro (and can move Home to Pro with a valid Pro key), but you cannot use lower-edition media to upgrade a higher edition — setup detects your current edition and enforces the direction. Finally, note what the media route does for you automatically when online: Dynamic Update, where setup fetches the latest updates and drivers relevant to your hardware before committing, which is one reason an in-place upgrade from a freshly downloaded ISO tends to land on a well-updated system.

A few practical notes on the media itself keep this route smooth. The mounted ISO behaves like a read-only virtual drive: it appears with its own drive letter in File Explorer, disappears when you unmount it (right-click > Eject) or reboot, and leaves no trace on disk — so there is nothing to clean up afterwards, and the physical USB stick you may have used to download it can be reused immediately. Keep the ISO file itself after the upgrade completes: the same image that upgraded you in place is also your future repair media, and re-running its setup.exe from a mounted state on a troubled Windows 11 installation is a legitimate way to replace damaged system components while keeping files and apps. If setup.exe will not launch at all from the mounted drive — an immediate crash or a “file is corrupted” style message — the usual cause is a truncated or altered download: compare the file size against what Microsoft publishes for that edition, re-download it once on a stable connection, and verify you saved it from the genuine download page. A corrupted ISO fails early and predictably; a partially written one fails later and confusingly, so the re-download is worth doing even when the first attempt “almost worked”.

"Keep personal files and apps" is a promise with edges, and knowing where the edges are is what separates a smooth upgrade from a surprise. What it reliably preserves: your user profile, everything in it (Documents, Desktop, Pictures, browser profiles and history that live there), desktop and Start-menu shortcuts, and the large majority of installed applications — both classic Win32 programs and Microsoft Store apps. What it does not guarantee: any application whose behaviour depends on components underneath the OS itself. Security products with kernel drivers or boot-start services, anti-cheat systems, virtualization tools with their own hypervisors, older 32-bit line-of-business applications, and vendor utilities tied to specific driver versions are the recurring problem classes — they may survive perfectly, may need a quick reinstall, or (rarely) may stop working until the vendor ships an updated build. The upgrade does not "reinstall" your apps; it carries them forward over a replaced system, so anything that was tightly coupled to old system components is exposed when those components change.

Activation deserves its own paragraph because people worry about it and the answer is usually reassuring. On a retail or OEM machine, Windows activation is typically a digital entitlement linked to your hardware signature: the same physical machine upgrading in place keeps its activated state, and after the upgrade Settings > System > Activation should still show Windows as activated — verify it once you are on the desktop. If the machine uses a manually entered retail key, that key remains valid and re-activation happens automatically or with one retry. In an enterprise environment using KMS or Active Directory-based activation, reactivation happens against the same infrastructure after the upgrade; if a domain-joined machine shows as unactivated for a day or two while it finds its KMS host again, that is normal transient behaviour rather than a lost license. The one case that genuinely changes licensing is an edition change (section 8): moving Home to Pro consumes a Pro key and the machine’s entitlement follows the new edition — plan that deliberately rather than letting a stray key on screen do it for you.

So make the preservation concrete before you start, in two moves. First, write down your critical-application list: the programs whose loss would actually hurt (licensed tools with keys stored only in your head, apps with years of settings, anything with a non-obvious profile location). Ten minutes now buys you a verification checklist later and a reinstallation order if something did not carry over. Second, capture a machine-readable snapshot of what is installed, so "what was on this PC" is a fact rather than a memory:

# Classic Win32 applications registered with Windows:
Get-CimInstance Win32_Product |
    Select-Object Name, Version, Vendor |
    Sort-Object Name |
    Export-Csv "$env:USERPROFILE\Downloads\apps-win32-before.csv" -NoTypeInformation

# Microsoft Store / modern packages (fast and reliable):
Get-AppxPackage |
    Select-Object Name, Version, PackageFamilyName |
    Sort-Object Name |
    Export-Csv "$env:USERPROFILE\Downloads\apps-store-before.csv" -NoTypeInformation

After the upgrade completes, walk the critical-application list deliberately: launch each important program, confirm its settings and profiles are intact (open a recent document, check a saved login where appropriate), and note anything that misbehaves. Most post-upgrade application problems fall into three buckets — the app needs its vendor’s updated installer (reinstall over the top), the app needs a driver-level component that section 18 covers, or the app simply is not compatible with Windows 11 and was only ever working by inertia. Distinguishing those three takes the pre-upgrade list: without it, every broken app looks identical. And remember the asymmetry that makes this whole section worth doing — files are protected by your backup, but applications are only protected by this inventory, because a file copy does not reinstall software.

Drivers are the part of an upgrade where "it worked before" is the only baseline you have, and it evaporates the moment the OS underneath changes. The audit’s purpose is to turn that baseline into a written record before the upgrade: which devices exist, which drivers they run (version and date), and which of them are already misbehaving. That last point matters more than it sounds — if Device Manager shows a warning triangle on your Wi-Fi adapter today, the upgrade is not the thing that broke it, and mixing pre-existing faults into post-upgrade symptoms will send you chasing ghosts in section 18. Open Device Manager (search "Device Manager" from the Start menu), expand every category, and look at the status column: anything with a yellow triangle or listed under "Other devices" gets noted now, along with a decision — fix it first if the fix is a simple driver update, or accept and record it if it is a known dead end.

Not all drivers carry the same post-upgrade risk, so weight your audit by class. Graphics: current NVIDIA, AMD and Intel drivers ship Windows 11 support, and most integrated graphics from the last decade are fine — the risk concentrates in very old discrete GPUs whose vendors have stopped publishing new driver branches; for those, Windows will fall back to a generic Microsoft display driver that works but may cap resolution or refresh rate. Wi-Fi: the most common genuine casualty of an upgrade on older laptops, because some adapter generations simply never received a Windows 11 driver; if your Wi-Fi card is from several years ago, have a USB Wi-Fi adapter (or phone tethering) in reach as plan B — you will need network access for updates and vendor drivers the moment the upgrade lands. Audio: Realtek and similar mainstream audio almost always survives or is repaired by Windows Update within minutes. Chipset, fingerprint readers, card readers and vendor utilities (the manufacturer’s "tune-up" suites) are the long tail: individually minor, collectively the source of most post-upgrade grumbles, and usually fixed from the OEM’s support page rather than from a chip vendor.

The practical rule for sourcing drivers is machine first, component second: for a laptop or branded desktop, the manufacturer’s support page (searched by your exact model number) publishes the driver set it has validated for that machine on Windows 11, and that is where you go first when something needs reinstalling. Chip-vendor pages (Intel, NVIDIA, AMD, Realtek) are the second stop — better for graphics cards in particular, where the vendor’s current driver usually beats the OEM’s older bundled one. Windows Update is your safety net rather than your primary source: it carries a large driver store and will fix many gaps automatically after an upgrade, but it does not know about every component, especially niche peripherals. During the audit, record for each critical device (Wi-Fi, audio, GPU, chipset, anything with a warning triangle) the make/model, driver version and date, and where you would download a fresh copy — that one-line-per-device note is what makes section 18 a ten-minute repair instead of an afternoon of guessing. The next section automates exactly this record.

Reading Device Manager by eye is fine for one machine on a good day; a script gives you something better — a complete, timestamped, diffable record. The script below enumerates every signed driver in use (device name, manufacturer, version, date, provider, INF file and status), writes it to a CSV you can open in Excel or compare line-by-line after the upgrade, and prints any devices currently reporting an error. Its default behaviour is read-only apart from writing that one CSV file, and it validates the output path — refusing to write into system locations like C:\Windows so a careless parameter cannot turn an inventory script into a system-modifying one.

# =============================================================
#  DiagMyPCHub - Driver inventory with CSV export
#  Default run is READ-ONLY except for writing the CSV report you
#  ask for. Add -ExportPackages to also copy the in-use driver
#  packages (.inf/.sys files) to a folder; that step needs an
#  elevated (admin) PowerShell window and only copies files.
#
#  Examples:
#    powershell -File driver-inventory.ps1
#    powershell -File driver-inventory.ps1 -OutFile D:\backups\drivers.csv
#    powershell -File driver-inventory.ps1 -ExportPackages -PackageDir D:\backups\driver-packages
# =============================================================

[CmdletBinding()]
param(
    [string]$OutFile = (Join-Path $env:USERPROFILE 'Downloads\driver-inventory.csv'),
    [string]$PackageDir = '',
    [switch]$ExportPackages
)

$ErrorActionPreference = 'Stop'

# ---------- Validate the output path (refuse system locations) ----------
function Get-SafeTarget {
    param([string]$Requested, [string]$What)
    if ([string]::IsNullOrWhiteSpace($Requested)) { throw "A $What path is required." }
    $full = [System.IO.Path]::GetFullPath($Requested)
    foreach ($blocked in @('C:\Windows','C:\Program Files','C:\Program Files (x86)','C:\ProgramData')) {
        if ($full.StartsWith($blocked, [System.StringComparison]::OrdinalIgnoreCase)) {
            throw "Refusing to write the $What inside $blocked - choose a folder you own (e.g. your Downloads folder or an external drive)."
        }
    }
    return $full
}

$csvPath = Get-SafeTarget -Requested $OutFile -What 'CSV report'
$parent = Split-Path -Parent $csvPath
if (-not (Test-Path -LiteralPath $parent)) {
    New-Item -ItemType Directory -Path $parent -Force | Out-Null
}

Write-Host ''
Write-Host ('Driver inventory - {0} on {1}' -f (Get-Date).ToString('yyyy-MM-dd HH:mm'), $env:COMPUTERNAME)
Write-Host ''

# ---------- Collect the driver table ----------
$drivers = Get-CimInstance Win32_PnPSignedDriver |
    Where-Object { $_.DeviceName } |
    Select-Object DeviceName, Manufacturer, DriverVersion, DriverDate, ProviderName, InfName, Status |
    Sort-Object DeviceName

$drivers | Export-Csv -LiteralPath $csvPath -NoTypeInformation -Encoding UTF8
Write-Host ('Wrote {0} driver rows to: {1}' -f @($drivers).Count, $csvPath)

# ---------- Devices with problems (console only) ----------
$bad = Get-PnpDevice -Status Error -ErrorAction SilentlyContinue
if ($bad) {
    Write-Host ''
    Write-Host 'Devices currently reporting an error:'
    $bad | Select-Object FriendlyName, Class, Status | Format-Table -AutoSize
}

# ---------- Optional: export in-use driver packages (admin only) ----------
if ($ExportPackages) {
    $isAdmin = ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
    if (-not $isAdmin) {
        Write-Host 'WARN: -ExportPackages needs an elevated PowerShell window. Skipping the package export; the CSV was still written.'
    } else {
        if ([string]::IsNullOrWhiteSpace($PackageDir)) {
            $PackageDir = Join-Path (Split-Path -Parent $csvPath) 'driver-packages'
        }
        $pkgFull = Get-SafeTarget -Requested $PackageDir -What 'package export folder'
        New-Item -ItemType Directory -Path $pkgFull -Force | Out-Null
        Write-Host ('Exporting in-use driver packages to: {0}' -f $pkgFull)
        pnputil /export-drivers "$pkgFull" /in-use /subdirs
    }
}

Write-Host ''
Write-Host 'Keep the CSV (and package folder, if exported) with your backup. After the upgrade, compare it against a fresh run to spot anything that did not survive.'

The -ExportPackages switch is worth understanding because it changes what "record" means. A CSV tells you which driver versions were in use; pnputil /export-drivers goes further and copies the actual driver packages — the .inf, .sys and catalog files for every in-use driver — into a folder you control. That folder is genuine insurance: if after the upgrade a device has no driver available from Windows Update or the vendor (the classic case being an old Wi-Fi card whose manufacturer stopped publishing), you can install the exact package that worked before with pnputil /add-driver "path\to\folder\*.inf" /install, and the device is back without needing the old OS. The export is additive — it copies files out of the driver store, it does not modify or remove anything — but it does need an elevated PowerShell window, which is why the script checks for admin rights first and degrades gracefully (CSV still written) when run without them.

How to use the inventory in practice: run the script before the upgrade and copy the CSV (and package folder, if you exported one) to your backup drive alongside everything else from section 4. After the upgrade, run it again with a different output name — driver-inventory.ps1 -OutFile drivers-after.csv — and compare the two files side by side in Excel or any spreadsheet program. The interesting rows are not the ones that changed versions (that is expected and usually an improvement); they are the devices that were present before, absent or erroring after, and the warning-triangle list printed at the end of each run. That diff, together with your section 10 notes on where to download each vendor’s driver, is the complete input to section 18’s repair procedure — which is exactly why the record is made now, while everything still works and every question has a definite answer.

The first thirty minutes on Windows 11 are for verification, not celebration — and the standard is functional, not cosmetic. A device with no warning triangle in Device Manager can still be running on a generic driver that caps your monitor at 60 Hz, routes audio through the wrong endpoint, or connects to Wi-Fi at a fraction of its real speed. Work the four areas in an order that respects dependencies: network first, because Windows Update and vendor download sites need it (if Wi-Fi is dead, use Ethernet, a USB network adapter or phone tethering before anything else — the chicken-and-egg problem section 18 covers); then graphics, by checking that the display runs at its native resolution and refresh rate (Settings > System > Display > Advanced display) and playing a video full-screen; then audio, testing both output and input — play a sound, check the right output device is selected in the volume mixer, and record a few seconds of microphone if you use calls; finally Bluetooth, by actually pairing a device (headset, mouse or phone) rather than just confirming the radio toggles. A green Device Manager list plus these four functional passes is what "drivers survived" means in this guide.

# =============================================================
#  DiagMyPCHub - Post-upgrade device verification (read-only)
#  Run AFTER the in-place upgrade, once Windows Update has had a
#  chance to run. It only reads device state and prints PASS /
#  WARN lines. Nothing is installed or changed.
# =============================================================

$ErrorActionPreference = 'Continue'
Write-Host ''
Write-Host ('Post-upgrade device check - {0} on {1}' -f (Get-Date).ToString('yyyy-MM-dd HH:mm'), $env:COMPUTERNAME)
Write-Host ''

# ---------- Wi-Fi / Ethernet ----------
$adapters = Get-NetAdapter -Physical | Where-Object { $_.InterfaceDescription }
$up = @($adapters | Where-Object { $_.Status -eq 'Up' })
if ($up.Count -gt 0) {
    Write-Host ('PASS: network adapter(s) up: {0}' -f (($up | ForEach-Object { if ($_.LinkSpeed -is [string]) { $_.Name + ' (' + $_.LinkSpeed + ')' } else { $_.Name + ' (' + [math]::Round($_.LinkSpeed/1e6,0) + ' Mbps)' } }) -join ', '))
} else {
    Write-Host 'FAIL: no physical network adapter reports Status = Up. Check the Wi-Fi toggle, Ethernet cable/port, then the driver (see the missing-drivers section).'
}

# ---------- Audio ----------
$snd = Get-CimInstance Win32_SoundDevice | Where-Object { $_.Status -eq 'OK' }
if (@($snd).Count -gt 0) {
    Write-Host ('PASS: audio device(s) OK: {0}' -f (($snd | ForEach-Object { $_.Name }) -join ', '))
} else {
    Write-Host 'FAIL: no audio device reports OK. Play a test sound to confirm; if silent, install the manufacturer audio driver.'
}

# ---------- Graphics ----------
$vid = Get-CimInstance Win32_VideoController
if (@($vid).Count -gt 0) {
    $v = $vid | Select-Object -First 1
    Write-Host ('PASS: graphics controller present: {0} (driver {1}, mode {2})' -f $v.Name, $v.DriverVersion, $v.VideoModeDescription)
    if ($v.VideoModeDescription -match '1[0-9]{2}x[0-9]{3}') {
        Write-Host 'INFO: display is below 1080p. If your monitor supports more, the GPU driver may still be generic.'
    }
} else {
    Write-Host 'FAIL: no video controller reported (very unusual - capture a screenshot of this output).'
}

# ---------- Bluetooth ----------
$btSvc = Get-Service bthserv -ErrorAction SilentlyContinue
$btDev = Get-PnpDevice -Class Bluetooth -ErrorAction SilentlyContinue | Where-Object { $_.Status -eq 'OK' }
if (($btSvc) -and ($btSvc.Status -eq 'Running') -and (@($btDev).Count -gt 0)) {
    Write-Host ('PASS: Bluetooth service running and {0} Bluetooth device(s) OK.' -f @($btDev).Count)
} elseif ($btSvc) {
    Write-Host ('WARN: Bluetooth service is {0} but no Bluetooth adapter reports OK. Check Settings > Bluetooth for the radio and driver.' -f $btSvc.Status)
} else {
    Write-Host 'INFO: no Bluetooth stack found (the machine may have no Bluetooth hardware).'
}

# ---------- Anything else broken ----------
$bad = Get-PnpDevice -Status Error -ErrorAction SilentlyContinue
if ($bad) {
    Write-Host ''
    Write-Host ('WARN: {0} device(s) currently report an error:' -f @($bad).Count)
    $bad | Select-Object FriendlyName, Class, Status | Format-Table -AutoSize
} else {
    Write-Host ''
    Write-Host 'PASS: no devices report a PnP error.'
}

Write-Host ''
Write-Host 'Next: do the real functional tests (stream a video for GPU + audio, browse the web on Wi-Fi, pair a Bluetooth device) - a green list is necessary but not sufficient.'

The script’s output is deliberately conservative: a PASS line means the device layer reports healthy, not that your experience will be flawless — which is why the final line points at the functional tests instead of declaring victory. If every row passes but something still feels off (audio crackle, Wi-Fi dropping, monitor stuck at low refresh), the problem has moved from "missing driver" to "wrong or generic driver", and the remedy is the same source order as the table: OEM page, chip vendor, then Windows Update. If a row fails outright — no network adapter up, no audio device OK — stop the verification tour and go straight to section 18 with that specific failure in hand; fixing one missing driver at a time, starting with networking, is faster than trying to diagnose everything at once.

Timing matters more than people expect in this verification window, and getting it wrong produces false alarms that send you down section 18’s repair path for problems that resolve themselves. After an in-place upgrade completes, Windows typically runs its first update pass automatically on the next boot or shortly after login, and that pass is when the bulk of driver replacements happen — a Wi-Fi adapter that is missing at the ten-minute mark very often appears by the thirty-minute mark once Windows Update has fetched its driver package. The practical rule: let the machine sit with updates running for at least half an hour before you declare any device broken, and check whether Windows Update shows “up to date” before interpreting a missing device as permanent. Two other behaviours in this window are normal rather than alarming: some vendor utilities (the manufacturer’s support apps, fingerprint software) detect the new OS on first launch and prompt for their own update or reinstall, which is the intended self-healing path; and a freshly upgraded machine can run noisier and warmer than usual for the first day while background indexing, telemetry and update work completes. Verify devices after that settling period, not in its middle.

A "compatibility block" is setup’s way of saying the machine does not meet a requirement, and it shows up in three familiar forms: the Installation Assistant refusing to offer an upgrade with the message that this PC can’t run Windows 11; setup aborting during its checks with codes in the 0x800F0922 / 0x800F0923 family (compatibility and driver-signalling failures); or PC Health Check listing one or more failed requirements. The first move is always the same: identify which requirement is actually failing, because each one has a different fixability. Run the readiness script from section 3 — it separates "TPM present but disabled" (fixable in firmware) from "no TPM reported" (a hardware question) from "unsupported CPU" (not fixable in software at all). If you only have the bare error message, work backwards through the section 2 table: note the exact CPU model, check tpm.msc for the spec version and "Ready" state, and check msinfo32 for BIOS mode. The block is a symptom; the failed requirement is the diagnosis.

Three fixes are legitimate, supported, and worth doing before you conclude the machine cannot upgrade. Enable a firmware TPM: many PCs that report "no TPM" actually have one built into the CPU — Intel calls it PTT (Platform Trust Technology), AMD calls it fTPM — sitting disabled in the firmware settings, usually under Security, Authentication or similar. Enabling it is a standard BIOS/UEFI change documented by the manufacturer; after enabling, reboot and re-run tpm.msc to confirm "Ready". Enable Secure Boot: if the firmware supports UEFI but Secure Boot is off (common on machines that were deliberately set to legacy/CSM boot), turning it on in the firmware settings satisfies the requirement — sometimes you must disable CSM/legacy boot first, which changes how the machine starts and should be done with the manufacturer’s guidance in view. Update the BIOS/UEFI: a firmware update from the motherboard or laptop manufacturer can fix TPM detection, add Secure Boot capability on marginal boards, and resolve CPU-identification quirks; it is also simply good hygiene before any major OS operation. What is not fixable this way: an unsupported CPU generation, insufficient RAM (physically), or a drive below 64 GB — those are hardware facts, and the honest options for them are in the next paragraph.

This is where the guide takes a deliberate position on the workarounds that circulate online. Registry-based bypasses do exist — they modify setup’s compatibility checks so installation proceeds on unsupported hardware — and this guide will not walk you through applying them as a routine step, for three concrete reasons. First, Microsoft does not support that configuration: security updates are not guaranteed, some Windows 11 features (parts of the security stack in particular) may be unavailable or behave differently, and future feature updates can be blocked on machines that installed this way. Second, they change behaviour you cannot see — a bypassed machine is not "Windows 11 with a warning label", it is a different support status than the supported one. Third, the decision they serve is usually the wrong one: if your CPU genuinely does not qualify, the real choices are (a) stay on Windows 10 and consciously accept its post-October 2025 update situation — including any paid ESU option that applies to your edition and use case — (b) replace or upgrade the hardware, or (c) install unsupported with full knowledge of what you give up. Option (c) is a legitimate choice for a lab machine or a secondary PC where you own the risk; it is not a good default for the computer you rely on daily. Whatever you decide, decide it from this paragraph with the facts in front of you — not from a forum thread that stops at "it worked for me".

The most common "failure" of an in-place upgrade is not a failure at all — it is a phase that looks frozen while doing a lot of quiet work. The screens that trigger panic are predictable: "Getting ready", "Installing updates", "We’ll restart your PC a few times", and the percentage counters that sit on values like 27% or 65% for what feels like an eternity. Some of these phases legitimately take a long time — on a mechanical hard drive, particular phases can run well past an hour while setup copies and compresses large file sets, and even SSDs pause visibly during the final configuration steps where almost nothing appears to change on screen. The rule that separates patience from intervention is observable activity, not the clock: as long as there is evidence the system is working — the disk activity light blinking, fan noise changing with load, the percentage inching forward even every few minutes, the mouse cursor still moving — the correct action is to wait with power connected. Interrupting a genuinely active write is how "stalled for an hour" becomes "unbootable machine".

When doubt sets in, make it evidence-based instead of emotional. Sit with the machine and note, over a ten-minute window: does the percentage or phase text change at all? Is the disk activity light on intermittently (a hard drive doing real work) or completely dark (suspicious)? Are the fans behaving like a loaded system? Does the cursor respond? Write down the exact screen text and percentage — you will want it when reading logs in section 15. The decision rule: any sign of progress, however slow, means keep waiting; total absence of disk activity for an extended period (on the order of an hour or more, with a steady power supply) is the point where a forced reboot becomes the reasonable next step. If you do force the reboot, do not treat it as giving up — Windows’ upgrade process is designed to resume from its staging area after an interruption, so the machine will typically come back either into the original Windows 10 desktop (upgrade aborted and rolled back automatically) or back into the upgrade where it left off. Either outcome is workable; what you do next depends on which one you get, and section 16’s decision tree sorts that out.

If stalls keep happening — the upgrade aborts, resumes, stalls again — stop retrying blindly and look for the underlying cause, because a repeated stall is a symptom with a small set of common culprits. A failing disk is the big one: setup’s sustained read/write load exposes drives that are about to die, and I/O hangs on a dying drive look exactly like a frozen percentage; check the drive’s health status (the readiness script and section 6 both surface it) and lean on your backup if it is not reporting Healthy. Overheating causes throttling that can slow phases to a crawl — dust-clogged cooling in an old machine is a classic; if the fans are screaming or the case is hot to the touch, let it cool and re-check airflow before retrying. Interference from security software can stall specific phases where setup touches protected components; rather than disabling protections wholesale, check whether your vendor documents an upgrade-compatibility mode. And network stalls during the update-download phase (Dynamic Update fetching current patches and drivers) will sit at a percentage until the transfer completes or times out — a flaky connection is a plausible cause that a wired Ethernet link eliminates. In every case, after the machine comes back, read the setup logs in section 15 before starting another attempt; the log will usually name the phase and the reason, which turns "it got stuck again" into a specific, addressable problem.

Every in-place upgrade writes detailed logs, and when something fails the answer is almost always in them — which makes the logs the single most underused diagnostic tool in this entire scenario. The primary files live in the staging folder C:\$WINDOWS.~BT\Sources\Panther: setupact.log is the full activity record (every phase, every file operation, at length), and setuperr.log is the condensed companion that contains mostly errors and failures — if setuperr.log is empty or absent, that is itself useful information. There is also C:\Windows\Panther\unattend.xml, which records unattended-answer configuration when relevant. These folders carry hidden/system attributes, so the reliable way to reach them is to paste the full path into File Explorer’s address bar rather than navigating by eye — and note that on a completed or cleaned-up upgrade the $WINDOWS.~BT folder may no longer exist at all, which tells you where in the lifecycle you are standing.

Reading technique matters more than log size. In setupact.log, search for the strings error, fail and hex codes like 0x8007; then find the first genuine error in the sequence, not the last — upgrade failures cascade, and the final entry is usually a knock-on effect (a phase aborting because an earlier copy failed). The first error names the cause: a specific file that could not be copied, a disk-space exhaustion at a particular moment, a driver compatibility verdict. The codes below are the ones most commonly reported in connection with in-place upgrades; treat them as a starting vocabulary, not an exhaustive table — the log line around the code is always the authority.

# =============================================================
#  DiagMyPCHub - Extract the useful lines from Windows upgrade logs
#  READ-ONLY. Looks in the $WINDOWS.~BT staging folder (created
#  while an upgrade runs) and prints the tail of setuperr.log plus
#  recent error lines from setupact.log. It never modifies logs.
# =============================================================

$panther = Join-Path $env:SystemDrive '$WINDOWS.~BT\Sources\Panther'
Write-Host ''
Write-Host ('Setup log check - {0}' -f (Get-Date).ToString('yyyy-MM-dd HH:mm'))
Write-Host ''

if (-not (Test-Path -LiteralPath $panther)) {
    Write-Host 'No $WINDOWS.~BT staging folder found on this drive.'
    Write-Host 'That means either the upgrade has completed and been cleaned up, or it never staged. If you are troubleshooting a failure, check C:\Windows\Panther\unattend.xml as well.'
    exit 0
}

Write-Host ('Staging folder found: {0}' -f $panther)
Write-Host ''

$errLog = Join-Path $panther 'setuperr.log'
if (Test-Path -LiteralPath $errLog) {
    Write-Host '=== Last 40 lines of setuperr.log (the condensed failure log) ==='
    Get-Content -LiteralPath $errLog -Tail 40
} else {
    Write-Host 'setuperr.log not present - often a good sign (no recorded errors).'
}

Write-Host ''
$actLog = Join-Path $panther 'setupact.log'
if (Test-Path -LiteralPath $actLog) {
    Write-Host '=== Recent error/failure lines from setupact.log (last 25 matches) ==='
    Select-String -LiteralPath $actLog -Pattern 'error|fail|0x[0-9A-Fa-f]{8}' |
        Select-Object -Last 25 |
        ForEach-Object { $_.Line }
}

Write-Host ''
Write-Host 'Read the lines around the first error, not just the last one - the first failure is usually the cause and later entries are knock-on effects.'

For a second opinion on what the logs mean, Microsoft publishes SetupDiag, a small diagnostic tool that analyses exactly these upgrade logs and reports likely causes in plain language; it is documented on Microsoft Learn (see References) and is worth running after any failed upgrade before you commit to a fix. The workflow is: run the extraction script above to see the raw evidence, run SetupDiag for its interpretation, then map both onto the code table — if the three sources agree on a cause (for example, all pointing at disk space), you can act with confidence; if they disagree, trust the raw log line naming the specific file or component, because that is the ground truth the other two are summarizing.

A failed in-place upgrade leaves the machine in exactly one of three states, and identifying which state you are in is the entire first step — because the correct next action differs completely between them, and acting on the wrong assumption (for example, trying to "finish" an upgrade that already aborted) wastes time and can destroy the evidence you need. State A: the PC boots normally into your original Windows 10 desktop; the upgrade aborted and rolled itself back, usually with a message about completing setup later or an error code on screen. State B: the PC boots into Windows 11 but it is broken — repeated restarts, a login that fails, or a desktop where critical components do not work. State C: the PC does not reach a usable desktop at all — black screen, boot loop, or a direct drop into the recovery environment. Take a minute to place yourself honestly before touching anything: which of the three is this? The decision tree below branches from that answer.

Equally useful is the short list of things that make recovery worse, because they are the mistakes people make at exactly this moment, when frustration is highest and the machine is least cooperative. Do not re-run setup in a loop — repeating an upgrade attempt without fixing the diagnosed cause just regenerates the same failure and burns your rollback window with each cycle. Do not delete Windows.old or clean up “previous installations” before you have finished deciding whether to roll back — that action is irreversible, and the decision deserves a night of thought, not a cleanup click. Do not format or reinstall over the system drive out of frustration — that is precisely the scenario your section 5 backup exists for, and restoring from it is faster than the spiral of attempts that usually precedes it. And know the escalation point: if Startup Repair, rollback and file-level repair have all been tried and the machine still will not boot reliably, the problem is structural (disk, firmware, or a damaged installation beyond in-place repair), and the proportionate next step is your backup restore plus a fresh installation — with OEM or professional support engaged if the hardware itself is in question. Recovery is a sequence of bounded attempts; the discipline is in stopping each attempt when its evidence says it cannot work.

Two rules hold across every branch of this tree. First, collect evidence before cleanup: the staging folder and its logs are temporary by design — Disk Cleanup removes them, a successful upgrade removes them, and once they are gone the specific reason for the failure is much harder to pin down. If you are in State A, your first action is the section 15 script, not Disk Cleanup. Second, know your stop point: recovery is a sequence of increasingly invasive attempts (read logs → built-in rollback → Startup Repair → file-level repair → restore from backup), and each step should be justified by evidence that the previous one could not work. If you have rolled back once, retried with the diagnosed cause fixed, and failed again at the same point, the machine is telling you something structural — a weak disk, a genuine compatibility problem, or a damaged installation — and the proportionate response is the backup-and-rebuild path, not a fourth attempt. That is not failure; that is the backup doing exactly what it was for.

Windows keeps a way out of every in-place upgrade: the previous operating system, preserved as C:\Windows.old, can be restored through Settings > System > Recovery > "Go back to a previous version" (wording varies slightly by build). The rollback reinstalls the Windows 10 system state from that folder and returns you to your pre-upgrade desktop. It is the single most important recovery feature in this entire scenario, so its conditions deserve to be stated precisely rather than assumed. Rollback is available for ten days after the upgrade completes. After that window closes, the option disappears — not as a mystery policy, but because Windows then considers the old installation obsolete and eligible for reclamation. The "Go back" option also requires that Windows.old still exists on disk; anything that deletes it removes rollback with it, most notably Disk Cleanup’s "Previous Windows installations" category (the same cleanup you use to tidy up after a failed upgrade in section 16 — which is why that cleanup is deliberate there: you are choosing to leave the rollback path behind). Recovery options therefore depend on retained files, elapsed time and disk-cleanup decisions, all at once.

Equally important is what rollback does not do, because surprises here are the cost of assuming it is a full undo. Rollback restores the operating system to its state at the moment the upgrade started: your files return to how they were then, which means changes you made to files during the days on Windows 11 are lost — a document you edited on day three reverts to its pre-upgrade content. Applications installed after the upgrade are removed (they did not exist in the restored state), and drivers return to their pre-upgrade versions. In practice this is rarely painful for a rollback that happens within days, but it is a real data consideration: if you did meaningful work during the Windows 11 window, save or copy those files somewhere before rolling back. And note the asymmetry with your backup — rollback restores the system, while your section 5 backup protects your files regardless of what any OS operation does; the two mechanisms cover different things, and neither replaces the other.

The discipline that makes rollback useful rather than comforting: roll back, then diagnose, then retry — never roll back and immediately re-run the upgrade. A rollback undoes the result of a failed attempt; it does not fix the cause. If the upgrade failed for a reason (disk space, disk health, a compatibility verdict, a stalled phase), that reason is still there waiting on the other side of the rollback. So the sequence after every rollback is: confirm you are back on a working Windows 10, run the section 15 log extraction while the evidence still exists, identify and fix the specific cause using sections 6, 13 or 14 as appropriate, verify your backup is still current (you may have used it), and only then start the upgrade again. If you find yourself rolling back a second time for the same symptom, stop — that repetition is the machine telling you the problem is structural, and the proportionate move is the section 16 decision tree’s final branch: backup restore and a clean route, with full knowledge of why.

The most common "bad" outcome of an in-place upgrade is also the least dangerous: Windows 11 boots to a working desktop, your files are there, your apps mostly run — but one or more devices are missing, generic, or misbehaving. No Wi-Fi, silent audio, a monitor stuck at low resolution, Bluetooth absent from Settings. This state is a driver gap, not a system failure, and it has a standard repair order that respects how Windows actually sources drivers. Step one is always Windows Update, run to completion: the first update pass after an OS upgrade is when Windows pulls the bulk of its driver store updates for your hardware, and a surprising number of "missing" devices simply appear after that pass finishes — so if you are checking devices before the first update round has completed, you are diagnosing a transient state. Step two is the manufacturer’s package for anything still missing: the OEM support page for your exact machine model (section 10’s rule), or the chip vendor for graphics cards, downloading the current Windows 11 driver and installing it normally. Step three is manual installation from files when you have a specific package in hand: Device Manager > right-click the device > "Update driver" > "Browse my computer for drivers", pointing at the downloaded folder — or, for exported packages from section 11, pnputil /add-driver "path\to\package\*.inf" /install, which installs the exact driver that worked before the upgrade.

The special case worth planning for is no network at all after the upgrade — the chicken-and-egg problem where the missing driver is the one you need in order to download drivers. Three bridges work, in order of convenience: a USB Ethernet adapter (the most reliable; it uses generic drivers that Windows 11 already has), smartphone USB tethering (share your phone’s connection over USB — Windows treats it as a wired network), or downloading the needed driver on another machine and transferring it by USB stick. Once any of those is up, run Windows Update and follow the standard order above. If you exported driver packages in section 11, this is also the moment they earn their keep: the old Wi-Fi card’s exact driver package can be installed from the USB stick with pnputil, restoring network access without needing the vendor to still publish that driver at all — which matters for adapter generations whose support ended years ago.

Two closing points keep this section honest. First, rolling back a driver is a built-in, safe operation: if a freshly installed driver makes things worse (artifacts on screen, audio dropouts, Wi-Fi instability), Device Manager > device properties > Driver tab > "Roll Back Driver" restores the previous version — provided one exists in the store. Use it freely when a new driver regresses behaviour; that is what it is for, and it costs nothing. Second, know when to stop chasing: if a component’s manufacturer no longer publishes Windows 11 drivers for it (old fingerprint readers, niche capture cards, decade-old audio chips), the generic Microsoft driver is the ceiling, not a placeholder — the device may work in reduced form or not at all, and no amount of searching changes that. In that case, document the limitation in your post-upgrade notes (the section 19 report is the natural place), decide whether the component matters enough to replace in hardware, and move on. A successful upgrade with one documented, understood limitation beats a "perfect" upgrade you spent three days chasing.

Verification done by memory is verification skipped. The script below turns the whole "is this upgrade actually complete and healthy" question into a single run that checks the facts: is Windows 11 really running (and which build), is activation intact, are TPM and Secure Boot still in the state you left them in, do any devices report errors, is the network up, do audio and graphics report healthy, and is there reasonable free space left on the system drive. It prints each check as PASS/WARN/FAIL and writes the same results to a timestamped text report you can keep — which matters more than it sounds, because "what did the machine look like right after the upgrade" is a question you will want to answer weeks later when some odd behaviour starts, and a saved report answers it in seconds.

# =============================================================
#  DiagMyPCHub - Post-upgrade verification with written report
#  READ-ONLY on the system; the only thing it writes is a text
#  report file (default: your Downloads folder). Run it once
#  Windows Update has run at least one round after the upgrade.
# =============================================================

[CmdletBinding()]
param(
    [string]$ReportFile = (Join-Path $env:USERPROFILE 'Downloads\post-upgrade-report.txt')
)

$ErrorActionPreference = 'Continue'

function Get-SafeTarget {
    param([string]$Requested, [string]$What)
    if ([string]::IsNullOrWhiteSpace($Requested)) { throw "A $What path is required." }
    $full = [System.IO.Path]::GetFullPath($Requested)
    foreach ($blocked in @('C:\Windows','C:\Program Files','C:\Program Files (x86)','C:\ProgramData')) {
        if ($full.StartsWith($blocked, [System.StringComparison]::OrdinalIgnoreCase)) {
            throw "Refusing to write the $What inside $blocked - choose a folder you own."
        }
    }
    return $full
}

$lines = New-Object System.Collections.ArrayList
function Note([string]$State, [string]$Msg) {
    [void]$script:lines.Add(('{0,-5} {1}' -f $State, $Msg))
    Write-Host ('{0,-5} {1}' -f $State, $Msg)
}

Write-Host ''
Note 'INFO' ('Post-upgrade verification - {0} on {1}' -f (Get-Date).ToString('yyyy-MM-dd HH:mm'), $env:COMPUTERNAME)
Write-Host ''

# 1. OS version must be Windows 11
$os = Get-CimInstance Win32_OperatingSystem
$build = [int]$os.BuildNumber
if ($build -ge 22000) {
    Note 'PASS' ("Running Windows 11 build {0} ({1})." -f $build, $os.Caption)
} else {
    Note 'FAIL' ("Not running Windows 11 (version {0}, build {1}). The upgrade may not have completed." -f $os.Version, $build)
}

# 2. Activation
try {
    $act = (Get-CimInstance -Namespace 'root\cimv2' -ClassName 'SoftwareLicensingProduct' -Filter "LicenseStatus=1 AND Name LIKE '%Windows%'" | Select-Object -First 1).Name
    if ($act) { Note 'PASS' ("Windows reports as activated ({0})." -f $act) }
    else { Note 'WARN' 'No activated Windows product found. Check Settings > System > Activation.' }
} catch { Note 'WARN' 'Could not read activation status (Settings > System > Activation to check manually).' }

# 3. Security features still on
try {
    $tpm = Get-Tpm
    if ($tpm.TpmReady) { Note 'PASS' ('TPM present and ready.') } else { Note 'WARN' ('TPM not ready (TpmPresent={0}). Check firmware settings.' -f $tpm.TpmPresent.ToString()) }
} catch { Note 'WARN' 'Get-Tpm unavailable on this system.' }
try {
    if (Confirm-SecureBootUEFI) { Note 'PASS' 'Secure Boot enabled.' } else { Note 'WARN' 'Secure Boot not active.' }
} catch { Note 'WARN' 'Secure Boot state could not be read (legacy BIOS mode?).' }

# 4. Devices
$bad = Get-PnpDevice -Status Error -ErrorAction SilentlyContinue
if ($bad) {
    Note 'WARN' ('{0} device(s) report a PnP error: {1}' -f @($bad).Count, (($bad | ForEach-Object { $_.FriendlyName }) -join '; '))
} else {
    Note 'PASS' 'No devices report a PnP error.'
}

$up = @(Get-NetAdapter -Physical | Where-Object { $_.Status -eq 'Up' })
if ($up.Count -gt 0) { Note 'PASS' ('Network up: {0}' -f (($up | ForEach-Object { $_.Name }) -join ', ')) }
else { Note 'FAIL' 'No physical network adapter is up.' }

$snd = @(Get-CimInstance Win32_SoundDevice | Where-Object { $_.Status -eq 'OK' })
if ($snd.Count -gt 0) { Note 'PASS' ('Audio OK: {0}' -f (($snd | ForEach-Object { $_.Name }) -join ', ')) }
else { Note 'FAIL' 'No audio device reports OK.' }

$vid = @(Get-CimInstance Win32_VideoController)
if ($vid.Count -gt 0) { Note 'PASS' ('Graphics: {0} (driver {1})' -f $vid[0].Name, $vid[0].DriverVersion) }
else { Note 'FAIL' 'No video controller reported.' }

# 5. Storage headroom
$freeC = [math]::Round((Get-Volume -DriveLetter C).SizeRemaining / 1GB, 1)
if ($freeC -ge 20) { Note 'PASS' ("{0} GB free on C:." -f $freeC) } else { Note 'WARN' ("Only {0} GB free on C: - clean up space." -f $freeC) }

# 6. Last boot (a very recent last-boot right after upgrading is normal; repeated reboots are not)
Note 'INFO' ('Last boot: {0}' -f $os.LastBootUpTime.ToString('yyyy-MM-dd HH:mm'))

# ---------- Write the report ----------
$repPath = Get-SafeTarget -Requested $ReportFile -What 'report file'
$parent = Split-Path -Parent $repPath
if (-not (Test-Path -LiteralPath $parent)) { New-Item -ItemType Directory -Path $parent -Force | Out-Null }
$lines | Set-Content -LiteralPath $repPath -Encoding UTF8
Write-Host ''
Write-Host ('Report written to: {0}' -f $repPath)

Treat this script as a recurring instrument rather than a one-off, because its value compounds over time. Run it again after each major Windows feature update — not just after the initial upgrade — and keep the reports in date order next to your readiness report; together they become a health timeline of the machine. A drift between two runs is itself diagnostic: a device that was PASS at the upgrade and WARNs three months later points at driver degradation or a component starting to fail (check its history in Device Manager before replacing anything); free space that has quietly dropped below 20 GB predicts the next Windows Update problem before it happens; and a TPM or Secure Boot state that changed without you touching firmware settings deserves immediate investigation, since those should not move on their own. For more than one machine, the same script run on each PC with reports saved to a shared folder gives you a fleet-wide picture of upgrade health for the cost of a few seconds per device — which is the single-PC discipline from this guide scaled up without changing anything about it.

How to read the results: a FAIL on the OS-version row means the upgrade did not actually complete (you may be looking at a rolled-back machine — check section 16 before anything else); a FAIL on network or audio points straight at section 18’s repair order; WARN rows are "check this manually" items — activation that the script cannot read, TPM/Secure Boot states that differ from your pre-upgrade record (which would be genuinely worth investigating, since those should not change during an in-place upgrade), or low free space. The report file is the deliverable: save it next to your section 20 readiness report and your driver CSVs, so that a complete paper trail of "what this machine was before, what the upgrade did, what it looks like now" sits together on your backup drive. If you manage more than one PC, running the same script on each and keeping the reports side by side is the difference between remembering configurations and having them.

Everything in this guide compresses into one working list, and the version below is interactive: tick items as you complete them, watch the progress bar, and your state is saved in this browser between visits (the reset button starts over). Work the groups in order — nothing in "During" is safe before "Before" is done, and "After" is what turns a completed upgrade into a verified one. The checklist is deliberately redundant with the sections: that is the point. A checklist you can execute without re-reading twenty sections is a checklist that gets executed on the day it matters, when your attention is on the progress bar instead of this page.

The second half of this section turns the same discipline into a portable document. The readiness-report script below consolidates everything the earlier scripts know — system facts, compatibility check results, storage state and a driver summary — into one text file designed to be read by a human (or an IT department) without any context. Run it before the upgrade and keep the file with your backup; after the upgrade, run the section 19 script and compare its output against this one. The pair answers the two questions that matter: "was this machine ready to upgrade?" and "did it come out the other side healthy?" — both in writing, both timestamped, both independent of whatever state the machine is in when you next need the answer.

# =============================================================
#  DiagMyPCHub - Upgrade readiness report (consolidated)
#  READ-ONLY on the system; writes one text report combining the
#  compatibility checks, storage state and a driver summary.
#  Run it before the upgrade and keep the file with your backup.
# =============================================================

[CmdletBinding()]
param(
    [string]$ReportFile = (Join-Path $env:USERPROFILE 'Downloads\upgrade-readiness-report.txt')
)

$ErrorActionPreference = 'Continue'

function Get-SafeTarget {
    param([string]$Requested, [string]$What)
    if ([string]::IsNullOrWhiteSpace($Requested)) { throw "A $What path is required." }
    $full = [System.IO.Path]::GetFullPath($Requested)
    foreach ($blocked in @('C:\Windows','C:\Program Files','C:\Program Files (x86)','C:\ProgramData')) {
        if ($full.StartsWith($blocked, [System.StringComparison]::OrdinalIgnoreCase)) {
            throw "Refusing to write the $What inside $blocked - choose a folder you own."
        }
    }
    return $full
}

$lines = New-Object System.Collections.ArrayList
function Note([string]$Msg) { [void]$script:lines.Add($Msg) }

Note '=========================================================='
Note (' Windows 10 to Windows 11 in-place upgrade - readiness report')
Note (' Generated {0} on {1}' -f (Get-Date).ToString('yyyy-MM-dd HH:mm'), $env:COMPUTERNAME)
Note '=========================================================='
Note ''

# ---- System ----
$os = Get-CimInstance Win32_OperatingSystem
$cpu = (Get-CimInstance Win32_Processor | Select-Object -First 1).Name.Trim()
$ramGb = [math]::Round((Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory / 1GB, 1)

Note 'SYSTEM'
Note ('  OS:            {0} (build {1})' -f $os.Caption, $os.BuildNumber)
Note ('  CPU:           {0}' -f $cpu)
Note ('  Memory:        {0} GB' -f $ramGb)
$gpu = (Get-CimInstance Win32_VideoController | Select-Object -First 1).Name
Note ('  Graphics:      {0}' -f $gpu)
Note ''

# ---- Compatibility ----
Note 'COMPATIBILITY CHECKS (verify each; FAIL means not officially supported)'
try {
    $tpm = Get-Tpm
    if ($tpm.TpmReady) { Note ('  [PASS] TPM present and ready (version {0})' -f $tpm.Version) }
    elseif ($tpm.TpmPresent) { Note '  [WARN] TPM present but not active - enable in firmware' }
    else { Note '  [FAIL] No TPM reported by Windows' }
} catch { Note '  [WARN] TPM status could not be read (check tpm.msc)' }

try {
    if (Confirm-SecureBootUEFI) { Note '  [PASS] Secure Boot enabled' }
    else { Note '  [WARN] Secure Boot not active - enable in firmware settings' }
} catch { Note '  [FAIL] Secure Boot check failed - possible legacy BIOS mode' }

if ($ramGb -ge 4) { Note ('  [PASS] Memory {0} GB (minimum 4)' -f $ramGb) } else { Note ('  [FAIL] Memory {0} GB below minimum' -f $ramGb) }

$vol = Get-Volume -DriveLetter C -ErrorAction SilentlyContinue
if ($vol) {
    if ([math]::Round($vol.Size/1GB,0) -ge 64) { Note ('  [PASS] C: capacity {0} GB (minimum 64)' -f [math]::Round($vol.Size/1GB,0)) }
    else { Note '  [FAIL] C: capacity below 64 GB' }
    $freeGb = [math]::Round($vol.SizeRemaining/1GB,0)
    if ($freeGb -ge 20) { Note ('  [PASS] C: free space {0} GB' -f $freeGb) }
    else { Note ('  [WARN] C: only {0} GB free - free up space before upgrading' -f $freeGb) }
}

Note ''
Note 'NOTE: the CPU check is manual - compare the model above with Microsoft''s supported'
Note 'CPU list (linked in the tutorial). A supported CPU plus TPM 2.0 plus Secure Boot'
Note 'plus 4 GB RAM plus 64 GB storage is the official bar.'
Note ''

# ---- Storage ----
Note 'STORAGE'
Get-Volume | Where-Object { $_.DriveLetter } | ForEach-Object {
    Note ('  {0}: {1} GB total, {2} GB free ({3})' -f $_.DriveLetter, [math]::Round($_.Size/1GB,0), [math]::Round($_.SizeRemaining/1GB,0), $_.HealthStatus)
}
Note ''

# ---- Driver summary ----
Note 'DRIVER SUMMARY (full list: run the driver-inventory script for a CSV)'
$drivers = Get-CimInstance Win32_PnPSignedDriver | Where-Object { $_.DeviceName }
Note ('  Signed drivers in use: {0}' -f @($drivers).Count)
$net = @(Get-CimInstance Win32_NetworkAdapterConfiguration | Where-Object { $_.IPEnabled })
Note ('  Active network adapters: {0}' -f @($net).Count)
$snd = @(Get-CimInstance Win32_SoundDevice | Where-Object { $_.Status -eq 'OK' })
Note ('  Audio devices OK: {0}' -f @($snd).Count)
$bad = Get-PnpDevice -Status Error -ErrorAction SilentlyContinue
if ($bad) {
    Note ('  Devices reporting errors: {0}' -f @($bad).Count)
    foreach ($b in $bad) { Note ('    - {0} ({1})' -f $b.FriendlyName, $b.Class) }
} else {
    Note '  Devices reporting errors: none'
}
Note ''

# ---- Checklist reminders ----
Note 'BEFORE YOU START (tick these off in the tutorial checklist)'
Note '  [ ] Backup made to a drive that is not C:, and verified restorable'
Note '  [ ] BitLocker recovery key saved somewhere findable (if encryption is on)'
Note '  [ ] Windows Update brought Windows 10 fully current'
Note '  [ ] 20-30 GB free on C:'
Note '  [ ] Laptop plugged in / UPS connected'
Note '  [ ] Driver inventory CSV saved with the backup'
Note ''
Note 'Keep this report next to your backup. After the upgrade, run the post-upgrade'
Note 'verification script and compare its output against this file.'

$repPath = Get-SafeTarget -Requested $ReportFile -What 'report file'
$parent = Split-Path -Parent $repPath
if (-not (Test-Path -LiteralPath $parent)) { New-Item -ItemType Directory -Path $parent -Force | Out-Null }
$lines | Set-Content -LiteralPath $repPath -Encoding UTF8
Write-Host ('Report written to: {0}' -f $repPath)
$lines | ForEach-Object { Write-Host $_ }

One last word on how these pieces fit together, because the value of this guide is not any single section but the chain. The compatibility evidence from sections 2–3 justifies starting at all. The verified backup from sections 4–5 is what makes every later step reversible in practice, not just in theory. The driver records from sections 10–11 turn "something is missing" into a specific, fixable task. The log discipline from sections 14–15 turns "it failed" into a diagnosed cause. And the rollback knowledge from section 17 keeps you honest about time limits — ten days, one window, no extensions. Do all of it and an in-place upgrade becomes what it is supposed to be: a routine, documented, reversible operation on a machine that stays yours throughout.

The difference between a smooth in-place upgrade and a stressful one is almost never the upgrade itself — it is what happened before you clicked Install and what you did about the first warning sign after. Check compatibility with evidence rather than hope, and know which failures are firmware switches versus hardware facts. Back up to a different physical device, then prove the backup works by reading data back from it, because rollback has a ten-day window and a verified backup does not. Record your drivers before the OS changes underneath them, verify devices functionally afterwards, and when something fails, let the setup logs name the cause instead of guessing at symptoms. Keep the two reports — readiness before, verification after — with the backup, and you will have a machine whose upgrade history is something you can actually show.

References

• Download Windows 11 — Microsoft · the official source for the Installation Assistant, the Media Creation Tool and the Windows 11 ISO image.
• Windows 11 requirements — Microsoft Learn · the authoritative hardware requirements this guide’s compatibility checks are based on, including the supported CPU lists.
• Product Lifecycle FAQ: Extended Security Updates — Microsoft Learn · which editions qualify for Windows 10 ESU and how the extended-update program works after standard support ended.
• SetupDiag — Microsoft Learn · Microsoft’s diagnostic tool for analysing Windows upgrade setup logs after a failed installation.