PowerShell Troubleshooting Toolkit: Four Quick Copy-Paste Windows Fixes

PowerShell gives you a scalpel for Windows troubleshooting: four copy‑and‑paste commands that answer the right questions fast, fix the common problems I see on machines I rotate through, and get you from “What’s wrong?” to “Working again” without hunting through a dozen Settings panels.

Background​

Power users and admins have known for years that PowerShell exposes the system as objects you can probe, sort, and act on. Where Windows Settings and Control Panel show buttons and toggles, PowerShell shows live objects — files, folders, packages, network stacks, and processes — that you can inspect programmatically. Using a handful of simple one‑liners cuts out guesswork: you’ll identify the largest folders, enumerate and remove unwanted Store apps, reset the network stack, and quickly find the processes chewing CPU or RAM. For each of those tasks I’ll show the practical command, explain what it does, highlight common pitfalls, and offer safer alternatives when needed.
Before you run anything: open PowerShell as Administrator when the command needs elevated privileges (right‑click PowerShell or Windows Terminal and choose “Run as administrator”). When I share destructive commands (package removals, resets) I’ll show the non‑destructive way to inspect first so you always know what will change.

---

Find the biggest storage hogs — fast​

Why this matters​

Storage fills slowly and silently until one day a machine won’t install updates or the user can’t save a file. Clicking through Settings > System > Storage gets you some info, but it’s often slow and not obvious where the biggest wins are. A short PowerShell pipeline lists the largest folders so you can reclaim the most space quickly.

Command to run (copy / paste)​

• Inspect folder sizes in a path (replace the path with the folder or drive you want to analyze):
• Non‑destructive scan (lists folders and sizes, sorted descending):
  

  Get-ChildItem "C:\Users\YourName" -Directory |
  ForEach-Object {
   $size = (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum
  } | Sort-Object SizeGB -Descending

• Quick summary per-file type (largest individual files):
  

  Get-ChildItem "C:\Users\YourName" -Recurse -File -ErrorAction SilentlyContinue |
  Sort-Object Length -Descending |
  Select-Object -First 25 Name, FullName, @{n='SizeMB';e={[math]::Round($_.Length/1MB,2)}}

What the commands do​

• Get-ChildItem enumerates files or folders; with -Directory it returns folders you can loop over. The documentation describes how recursion and providers work and why using LiteralPath/Force/Filter matters for large scans.
• Measure-Object -Property Length -Sum aggregates file sizes (Length is file size in bytes) so we can convert to GB and sort. This is the standard technique to compute directory sizes in PowerShell.

Practical notes and pitfalls​

• Performance: scanning an entire C: with -Recurse can take a long time on mechanical drives or when many small files exist. Start with high‑level folders (C:\Users) and drill down on the few that appear largest. Use -ErrorAction SilentlyContinue to skip permission errors.
• Cloud‑only / OneDrive stubs: cloud‑placeholder files may appear with attributes that make naive size calculations misleading. If you see unexpectedly small or zero sizes, account for cloud‑only items or filter them out. Tools and forum threads show this is a common gotcha.
• Long paths and locked files: older PowerShell or Windows versions may hit path length limits or throw errors on locked files. If the machine is old or you're scanning system locations, expect to run with admin rights and accept that some files may be inaccessible.

When to use a GUI alternative​

If you prefer a GUI or need faster visual scanning, third‑party utilities (TreeSize, WinDirStat) give immediate heatmaps. PowerShell’s advantage is scriptability and reproducibility; once you have a script you can run it on dozens of machines without clicking.

---

List installed Store apps and remove the ones you don’t want​

Why this helps​

Windows accumulates shelfware: preinstalled Store apps, trial apps, and vendor extras. The Settings > Apps list helps for classic desktop apps, but Microsoft Store / MSIX packages are best handled with the Appx/App cmdlets. A quick enumeration shows you what’s installed per user and makes removal repeatable.

Commands to run​

• List packages for the current user:
  Get-AppxPackage | Select-Object Name, PackageFullName
• Find a package by name (example: Teams):
  Get-AppxPackage [I]MicrosoftTeams[/I]
• Remove a package for the currently signed‑in user (be careful):
  Get-AppxPackage [I]MicrosoftTeams[/I] | Remove-AppxPackage

What these commands cover — and what they don't​

• Get-AppxPackage enumerackages (Store and modern Windows apps). It does not remove legacy Win32 installers (.msi/.exe) — those still require Programs & Features, winget, or manual uninstallers. The MS docs list the MSIX cmdlets and their intended use.
• Removing a package affects the current user by default. If you need to remove a package for all users or remove the provisioned package so new user accounts don’t get it, you’ll need additional steps (-AllUsers, Remove-AppxProvisionedPackage) — the behavior has evolved across Windows versions and sometimes requires extra registry cleanup. Community threads and Microsoft guidance explain these variations and caveats.

Safety checklist​

• Run Get-AppxPackage [I]partialName[/I] first to confirm the exact package name.
• Don’t remove packages you don’t recognize — some are dependencies for Start menu, Search, or system features.
• If you remove an app and want to reinstall later, use the Store or Add-AppxPackage / Get-AppxPackage -AllUsers patterns to recover.
• On managed devices (Intune, imaging workflows), consider using OS image customization or provisioning packages rather than ad‑hoc removals; some removals are reverted by system updates unless you remove the provisioned package too.

---

Reset the network stack — quick triage for flaky internet​

Why this is a go‑to fix​

When one PC shows “limited” or “no internet” while others on the same network work, or when pages randomly hang, the problem is often local: stale DNS entries, corrupted Winsock catalog entries left by VPNs or network filtering software, or a misconfigured TCP/IP registry state. Resetting the DNS cache, Winsock catalog, and TCP/IP stack in sequence often clears the issue quickly. This is the exact sequence I use as a safe, standard first step.

Commands to run (in an elevated prompt)​

• Flush DNS cache:
  ipconfig /flushdns
• Reset Winsock:
  netsh winsock reset
• Reset TCP/IP stack:
  netsh int ip reset
• Restart the PC after running the commands.

What each step does​

• ipconfig /flushdns clears the local DNS name lookups are re‑queried from upstream DNS servers; it’s quick and safe and often resolves name resolution issues caused by stale cached records.
• netsh winsock reset rebuilds the Winsock catalog to default, removing third‑party Layered Service Providers (LSPs) that can break socket behavior (VPN clients, filtering drivers). Microsoft documents the winsock context and the reset operation. You’ll typically need to reboot for changes to take effect.
• netsh int ip reset overwrites the TCP/IP registry keys and effectively reinstalls the TCP/IP stack; Microsoft’s support article shows the exact registry keys affected and recommends running the command as admin with a log file.

(I often run ipconfig /release and ipconfig /renew before or after when dealing with DHCP, but for many symptomatic fixes the three commands above + reboot are enough.) Community troubleshooting notes and IT KBs mirror this workflow and recommend the same order for practical troubleshooting.

Risks and caveats​

• Any installed network filters or VPN clients may need to be reinstalled or reconfigured after a winsock reset if they installed LSPs or custom providers. Keep setup information handy for corporate VPNs.
• netsh int ip reset writes registry changes; although safe for routine troubleshooting, it’s effectively the same as removing and reinstalling TCP/IP. Microsoft explicitly notes the registry keys it overwrites; if your system uses complex manual TCP/IP customizations, document them before running the reset.

---

See what’s eating CPU and memory — and act​

Why this matters​

“My PC is slow” is a vague symptom. PowerShell gives you a sortable list of processes by total CPU time or memory footprint so you can move from vague complaint to specific culprit fast. The standard approach is to run Get-Process and sort by CPU or WorkingSet, then decide: kill, investigate, or adjust startup behavior.

Commands to run​

• Top CPU consumers (by processor time):
  Get-Process | Sort-Object CPU -Descending | Select-Object -First 10
• Top memory consumers (working set):
  Get-Process | Sort-Object WorkingSet -Descending | Select-Object -First 10

What to look for and next steps​

• Short, sharp CPU spikes often come from a process performing work (indexing, update installers, antivirus scans). If a process has consistently high CPU time, research what it is and whether it’s expected (browser tabs, rendering jobs).
• Large WorkingSet values indicate memory pressure; when you find an offender, check whether it’s a known service, a browser tab with a runaway extension, or a background updater.
• Get-Process shows a subset of useful properties by default; if you need the command line or owner, combine with WMI/CIM or use Process Explorer (Sysinternals) for deep inspection and thread‑level view. Process Explorer is authored by the Sysinternals team and gives thread stacks and handles — it’s the natural next tool after Get-Process.

Safety measures before killing processes​

• Confirm process identity (path, command line) before Stop-Process.
• Avoid killing system processes (svchost) without understanding service implications.
• If the process is a service, restart it via Restart-Service or use Services MMC so dependencies are handled.

---

A “toolbox” script — copy, paste, and triage​

Below is a small, annotated toolbox you can drop into a troubleshooting session. Run each block separately and read the output before doing the destructive steps.
1.) Quick folder size glance (top 10 folders under path):

Get-ChildItem "C:\Users\YourName" -Directory |
  ForEach-Object {
    $size = (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum).Sum
    [PSCustomObject]@{Folder=$_.FullName; SizeGB=[math]::Round($size/1GB,2)}
  } | Sort-Object SizeGB -Descending | Select-Object -First 10

2.) Enumerate Store packages (inspect before removal):

Get-Appxt Name, PackageFullName | Out-GridView
# Use Out-GridView to visually filter; then pipe exact PackageFullName to Remove-AppxPackage if you know what you are doing.

3.) Network quick reset (run in an elevated prompt):

ipconfig /flushdns
netsh winsock reset
netsh int ip reset
# Reboot after running these

4.) Top processes by CPU and memory:

Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 | Format-Table -AutoSize
Get-Process | Sort-Object WorkingSet -Descending | Select-Object -First 10 | Format-Table -AutoSize

---

Critical analysis — strengths and risks​

What I like about this approach​

• Speed: one‑liners give focused answers quickly — which folder is largest, which process is the troublemaker, which Store app is installed. That reduces time wasted guessing. The underlying Microsoft docs show these cmdlets are supported and intended for exactly these tasks.
• Repeatability: scripts can be copied to multiple machines, producing consistent results that are easier to audit than ad‑hoc clicks.
• Low learning curve: you don’t need to be a PowerShell guru to benefit; copy‑paste and inspect outputs is powerful.

What to watch out for​

• Running as Administrator: many helpful commands require elevation; running removal or reset commands at admin level can change system state irreversibly, so always inspect output first.
• Removing the wrong Appx package can break Start menu, Search, or in‑box features. Some packages are tied to system functionality and can cause side effects if removed without re‑provisioning. Community experience shows removing packages sometimes leaves a “pending removal” state or requires additional registry cleanup. Be conservative and record what you remove.
• Network resets can disrupt third‑party VPNs or network filters; expect to reconfigure corporate VPN clients or reinstall drivers if they rely on LSPs. Microsoft documentation warns that netsh resets overwrite TCP/IP registry keys (effectively reinstalling TCP/IP), and that netsh contexts are being moved toward PowerShell equivalents, so keep configuration notes handy.
• Long runs and resource use: recursive folder scans can tax slow disks and produce large output sets; narrow the scan when possible. Measure‑Object is accurate but can be slow when enumerating millions of files.

---

Best practices and a short safety checklist​

• Always inspect before you remove:
• Use Get-AppxPackage alone or with Out-GridView to visually confirm a package before removing.
• Use Get-ChildItem + Measure-Object on a subfolder before scanning an entire drive.
• Create a system restore point or backup critical data on machines you manage regularly, especially before running resets or mass removals.
• If you run the network reset on a corporate laptop, have VPN credentials and drivers handy — and inform the user that a reboot will be required.
• For recurring maintenance, wrap these commands into idempotent scripts (check conditions before acting) and log every change.

---

Final thoughts​

PowerShell is not a magic wand — but a small set of well‑chosen one‑liners is an excellent troubleshooting toolkit. These four approaches (scan storage, enumerate/remove Store apps, reset networking, and surface resource‑hogging processes) convert vague problems into specific, actionable items. Use them as the first step in a disciplined triage: inspect, confirm, act, and then document. Over time you’ll find the same patterns recur, and those quick commands will save you hours compared with fishing through nested Settings panes.
If you keep one short list of commands in a notes app and a recovery plan (backup + restore point) nearby, you’ll handle most of the routine headaches in minutes instead of hours. The objective is simple: fewer interruptions, less guesswork, and faster returns to productivity.

---

Source: How-To Geek 4 PowerShell commands that fix common Windows problems fast