Start with the least damaging PowerShell repair path: file repair, then image repair, then the reset that matches the failure, such as Windows Update, networking, or a package problem. Pick the wrong command and you can burn time, reset healthy parts, or leave the fault in place. This guide ties each symptom to the right command, the safest order, and the fallback if it fails.

Likely causes

Likely causes
PowerShell logo and command-themed title text on a white background

These failures usually trace to damaged protected files, corruption in the Windows Component Store, stale DNS data, a bad network adapter state, or a package install error. Less often, the cause is a drive fault, an update log you need to read, or a shell or version mismatch that keeps the repair command from running where you expect.

  • Most often: component store corruption or damaged protected files.
  • Often: Windows Update cannot download repair content.
  • Often: DNS cache or adapter state is stale.
  • Sometimes: package installs fail while the system files are fine.
  • Less commonly: the wrong PowerShell edition or an unfit Windows version is blocking the command.

Say your laptop freezes after a cumulative update and Windows keeps returning generic error text. That pattern often points to image corruption first, not a broken app. Suppose a Wi-Fi adapter still shows connected but websites do not load; that usually calls for DNS and adapter reset steps before you reinstall anything.

What should you run first, DISM or SFC?

Run DISM first, then SFC. DISM /Online /Cleanup-Image /RestoreHealth repairs the Windows Component Store, and SFC then replaces bad system files with healthy cached versions. If Windows Update cannot supply repair files, add a local /Source and, when needed, /LimitAccess to keep DISM off Windows Update.

  1. Open Windows PowerShell or PowerShell as administrator.
  2. Run DISM /Online /Cleanup-Image /RestoreHealth.
  3. If the PC has no internet or Windows Update is broken, rerun DISM with a local source, such as a mounted ISO or WIM path, plus /LimitAccess.
  4. After DISM finishes, run sfc /scannow in the same elevated session.
  5. Restart if either command reports repaired files.

A common first-timer mistake is starting with SFC because it looks simpler. That can leave the Component Store untouched, so SFC has nothing healthy to pull from. DISM first, SFC second, is the safer order. Microsoft documents this repair sequence, and DISM’s /Source and /LimitAccess switches are the fallback when online repair is not available.

Use a local source when DISM cannot reach Windows Update

When a machine is offline, behind a strict policy, or stuck on a damaged update path, point DISM at a known-good source. Microsoft says /Source supplies known good files, while /LimitAccess prevents Windows Update from being used as the repair source; that combination is the cleanest offline path (per Microsoft support).

  1. Mount a Windows ISO or make sure a trusted WIM source is available.
  2. Run DISM with /Source and /LimitAccess.
  3. If DISM completes, run sfc /scannow next.
  4. If DISM reports a source problem, verify the source matches the installed Windows edition and build.

How do you fix Windows Update problems?

Start by creating a readable update log, then repair the component store if update failures repeat. Get-WindowsUpdateLog turns update traces into a text file you can inspect, which helps separate a bad package, a download failure, and a deeper component-store problem before you keep retrying the same update.

  1. Open an elevated PowerShell session.
  2. Run Get-WindowsUpdateLog and inspect the text file it creates.
  3. If the log points to corruption, run DISM /Online /Cleanup-Image /RestoreHealth.
  4. Run sfc /scannow after DISM finishes.
  5. Try Windows Update again after the repair pass.

Get-WindowsUpdateLog is the better first move when update history is noisy and the error code keeps changing. DISM is the next move when the log hints at image damage. On managed devices, Windows 10 and Windows 11 may differ in how update policies are applied, but the log-generation command stays the same.

How do you reset network issues?

Clear the DNS cache first, then restart only the adapters that are already up, and confirm recovery with a real network test. This avoids reinstalling drivers when the failure is just stale name resolution or a stuck adapter state. Test-NetConnection can check a host such as google.com.

  1. Open an elevated PowerShell window.
  2. Run Clear-DnsClientCache.
  3. List active adapters with Get-NetAdapter filtered by Status -eq 'Up'.
  4. Run Restart-NetAdapter on the adapter or adapters that are already up.
  5. Check recovery with Test-NetConnection google.com.

Picture a desktop that can ping the router but not load websites by name. Clearing the DNS cache can fix that faster than a full network reset. If the adapter is truly stuck, restart the active adapter after filtering on Status equal to Up. That is a reset, not a driver reinstall.

Can PowerShell fix app or package issues?

Yes, but only when the problem is the package layer rather than Windows itself. winget is available from any command shell on supported systems, including Windows 11 and Windows Server 2025, and it can install packages without switching tools. PowerShell 7 installs side by side with Windows PowerShell 5.1, so the shell you open matters. (Microsoft Learn)

  1. Open the shell you want to use: Windows PowerShell 5.1 or PowerShell 7.
  2. Check whether winget is available in that shell.
  3. Use winget to install or repair the app package.
  4. If the app still fails, run sfc /scannow afterward to rule out system-file damage.

PowerShell 7 does not replace Windows PowerShell 5.1. It installs side by side in a new directory, so an older script or admin task may still expect 5.1. Begin with the package manager when the failure is clearly app-specific; move to DISM and SFC when the app failure looks system-wide.

What PowerShell commands can I run to fix Windows?

The main repair commands are DISM /Online /Cleanup-Image /RestoreHealth for component-store repair, sfc /scannow for protected system files, Get-WindowsUpdateLog for update diagnostics, Clear-DnsClientCache for stale DNS, Restart-NetAdapter for stuck adapters, and Test-NetConnection for connectivity checks. Most of them need an elevated session.

Symptom Exact PowerShell command Admin required Internet required Expected success signal Fallback if it fails
System files seem damaged, apps crash, Windows behaves oddly DISM /Online /Cleanup-Image /RestoreHealth Yes Usually yes Repair completes without source errors Use /Source with /LimitAccess, then run sfc /scannow
Protected files still look broken after DISM sfc /scannow Yes No SFC reports repaired files or no integrity violations Rerun DISM, then SFC again
Windows Update keeps failing Get-WindowsUpdateLog No No Readable text log is created Repair the Component Store with DISM, then retry update
DNS names do not resolve correctly Clear-DnsClientCache Yes No New DNS lookups stop failing Restart the adapter with Restart-NetAdapter
Wi-Fi or Ethernet is connected but traffic is stuck Get-NetAdapter | Where-Object {$_.Status -eq 'Up'} | Restart-NetAdapter Yes No Adapter disconnects and reconnects cleanly Run Test-NetConnection google.com; if that fails, check router or policy
Need to confirm recovery to the internet Test-NetConnection google.com No Yes Connectivity test succeeds Repeat DNS and adapter steps, or inspect routing and firewall policy

Still not working?

Still not working?
A Windows PowerShell window displays help text on a desktop screen

If the repair commands fail, move up the ladder: confirm you are in an elevated shell, use a local install source for DISM, and verify that the Windows version supports the repair options you chose. Check whether the machine is Windows 10, Windows 11, or Server, because PowerShell 7 availability and package tooling can differ by edition and build.

  1. Open PowerShell as administrator and rerun the exact command.
  2. If DISM cannot download files, mount a matching ISO and rerun it with /Source and /LimitAccess.
  3. If the failure is package-specific, try winget from cmd.exe, Windows PowerShell, or PowerShell.
  4. If PowerShell itself seems broken, use Get-WindowsUpdateLog or check Event Viewer for the next failure code.
  5. If the system still will not recover, escalate to Microsoft support or a local administrator with deployment access.

Keep a matching Windows ISO or install source ready before an outage turns offline repair into guesswork. That matters most on disconnected systems and on servers with limited update access.

Keep reading

Frequently asked questions

How do I repair Windows system files with PowerShell?

Run DISM /Online /Cleanup-Image /RestoreHealth first, then run sfc /scannow in an elevated shell. DISM repairs the Windows Component Store, and SFC then replaces corrupted files from cached copies. If Windows Update cannot supply files, add a local /Source and /LimitAccess.

Which PowerShell command fixes Windows Update problems?

Get-WindowsUpdateLog is the best first diagnostic command because it creates a readable text file. If the log points to corruption, repair the image with DISM /Online /Cleanup-Image /RestoreHealth, then rerun Windows Update. That sequence separates a logging problem from an actual repair problem.

How do I check whether PowerShell can reach the internet?

Run Test-NetConnection google.com. If the test fails, clear the DNS cache with Clear-DnsClientCache and restart the active adapter with Restart-NetAdapter after filtering on Status -eq 'Up'. If the command still fails, the issue is likely beyond basic name resolution.

What Windows versions support these PowerShell repair commands?

DISM repair switches such as CheckHealth, ScanHealth, RestoreHealth, Source, and LimitAccess require at least Windows 8 or Windows Server 2012 for image servicing. For package work, winget is included in Windows 11 and Windows Server 2025, and it can run from any command shell.

Can PowerShell fix Windows store or app issues?

Yes, if the failure is limited to installation or package state. Use winget to install or repair the package from Windows PowerShell, PowerShell 7, or cmd.exe. If the app still fails after that, follow with sfc /scannow to check for deeper file damage.