DEV Community: Ivan Li

A safer Windows slowdown triage: 30 minutes before you reinstall

Ivan Li — Wed, 26 Aug 2026 16:46:08 +0000

When a Windows machine becomes slow, reinstalling the operating system is often treated as the first move. It should usually be much later in the process.

A reinstall changes many variables at once, creates avoidable recovery work, and can hide the real cause: a failing disk, too little free space, an aggressive startup application, an incomplete update, thermal throttling, or a workload that has simply outgrown the hardware.

Here is the read-only triage sequence I use before making changes.

1. Confirm scope, ownership, and recovery options

Before opening an administrative shell, answer four questions:

Is this the owner's device, or do they have written authority to manage it?
Is important data backed up, and has the backup been tested recently?
What must not be changed during this session?
What is the observed symptom: slow boot, slow login, high disk usage, application lag, update failure, or random freezes?

Write down the Windows version, device model, approximate age, time of the last known-good state, and any recent software or driver changes. A short timeline is more useful than “it has been slow for months.”

2. Establish a baseline

Start with built-in tools and capture findings before changing anything.

Get-ComputerInfo |
  Select-Object WindowsProductName, WindowsVersion, OsBuildNumber,
    CsModel, CsTotalPhysicalMemory

Get-Volume |
  Select-Object DriveLetter, FileSystemLabel, FileSystem,
    HealthStatus, SizeRemaining, Size

Low free space is a common contributor, but do not delete files merely because a drive is full. Identify what owns the space, confirm retention requirements, and agree on what may be removed.

Check the storage device's reported health:

Get-PhysicalDisk |
  Select-Object FriendlyName, MediaType, HealthStatus,
    OperationalStatus, Size

This is not a complete hardware diagnostic. If the disk reports an unhealthy state, the priority becomes backup and replacement planning—not “cleanup.”

3. Inventory startup pressure

Use Task Manager's Startup Apps page for impact estimates, then collect the configured startup entries:

Get-CimInstance Win32_StartupCommand |
  Select-Object Name, Command, Location, User

Do not disable everything. Security tools, accessibility software, device utilities, synchronization clients, and business agents may be required. For each candidate, record the owner, purpose, and rollback action before disabling it.

4. Look for a time-correlated system error

Instead of scrolling through every event, limit the initial sample to recent high-severity events:

$start = (Get-Date).AddDays(-7)

Get-WinEvent -FilterHashtable @{
  LogName   = 'System'
  Level     = 2
  StartTime = $start
} -MaxEvents 50 |
  Select-Object TimeCreated, ProviderName, Id, Message

An error in the log is not automatically the cause. Look for repetition and correlation with the user's timeline. Record event IDs and providers; avoid pasting logs containing personal or company data into public tools.

5. Verify system files without repairing yet

These commands are useful when corruption is plausible and you want evidence before repair:

DISM.exe /Online /Cleanup-Image /ScanHealth
sfc.exe /verifyonly

ScanHealth and verifyonly are diagnostic choices. Repair commands change system state and should come later, after backup status and rollback expectations are clear.

6. Separate software limits from hardware limits

During a controlled reproduction of the problem, watch CPU, memory, disk active time, and the specific process involved. A machine with 4 GB of RAM running a modern browser, conferencing software, security agents, and development tools may be behaving exactly as its hardware allows.

That distinction matters. Software cleanup cannot honestly promise to turn insufficient hardware into a fast workstation.

7. Finish with a written decision

A useful triage session should end with one of these outcomes:

No change: evidence is insufficient or the risk is too high.
Low-risk change: a small, reversible action with an explicit rollback.
Escalation: hardware diagnostics, vendor support, data recovery, or a specialist is required.
Rebuild plan: a reinstall is justified, with backups, license information, required applications, and restore testing prepared first.

The deliverable is not “I ran a cleaner.” It is a record of observations, actions, exclusions, and next steps.

A transparent service note

I currently offer a fixed-scope remote Windows health check: up to 75 minutes covering storage, startup items, updates, and basic security state, followed by written findings. The price is CNY 499 per device.

I only work on devices the client owns or is authorized to manage. Backup status and scope are confirmed first. I do not install pirated software, bypass licenses, access unrelated files, or provide network-restriction circumvention. Hardware repair and guaranteed speed improvements are outside the scope.

If that scope fits your situation, the intake form is here: https://docs.google.com/forms/d/e/1FAIpQLSc_qNpMHC0IAQWhqw2LTDflcfJ7s-3hyL0q-VkzyjT4YbqaFw/viewform

The first deliverable of a software rescue is not more code

Ivan Li — Wed, 26 Aug 2026 16:36:55 +0000

When a software project is late, “add another developer” sounds like the fastest answer. Sometimes it is. Often it makes the project later because the new person inherits the same uncertainty plus a communication cost.

Before writing more code, I use a short stabilization phase to turn an ambiguous rescue into a testable piece of work.

1. Name the one release path that matters

“The app needs to work” is not a release path.

A release path is a concrete journey such as:

An invited user signs in, uploads one supported video, runs one AI action, previews the result, and exports a playable file.

Write the path as observable steps. If the team cannot agree on the path, the current blocker is product scope, not implementation speed.

Everything outside this path goes into one of three buckets:

required for safety or data integrity;
useful after the release;
explicitly excluded from the rescue.

That last bucket matters. A rescue without exclusions quietly becomes a rewrite.

2. Build an evidence pack, not a blame document

The minimum useful evidence pack contains:

exact reproduction steps;
expected and actual behavior;
the smallest failing input, with sensitive data removed;
relevant logs and timestamps;
the last known working version;
build, test, and deploy instructions;
environment differences;
changes made just before the failure appeared.

Avoid screenshots without context and messages like “it randomly fails.” A screenshot can prove that a symptom happened. It usually cannot explain the state that produced it.

Do not send production passwords, private keys, customer data, or unrestricted cloud credentials in chat. Create temporary, least-privilege access and revoke it after the engagement.

3. Restore one known build and deployment path

Before changing the product, answer four questions:

Can a clean machine build it?
Can the current test suite run?
Can a non-production environment be deployed?
Can that deployment be rolled back?

If the answer is no, fixing a product bug may create a build or deployment incident instead. The team needs a reproducible baseline before it needs more changes.

For small teams, a one-page runbook is enough. Record the commands, required runtime versions, configuration source, health check, and rollback step. The goal is not perfect documentation. The goal is for a second person to repeat the path.

4. Separate the symptom from the constraint

The visible failure may not be the actual constraint.

An export button that “does nothing” could be caused by:

a frontend state transition that never fires;
a rejected API request;
a background job that is not consuming the queue;
an expired media URL;
a codec or platform mismatch;
a permissions problem;
missing observability that hides a successful-but-slow job.

Create hypotheses that can be disproved. “The queue is broken” is weak. “Jobs created after version X stay in pending for more than 60 seconds and no worker claims them” gives you something to test.

5. Define go/no-go acceptance before implementation

A rescue should have an objective end. For the example release path, acceptance might be:

the supported test asset completes the full path three times;
a deliberately invalid asset produces a clear, recoverable error;
a failed AI request can be retried without creating duplicate output;
the exported file plays in the agreed target environment;
logs contain a traceable job identifier;
the deployment and rollback notes have been tested by someone other than the author.

Notice what is missing: “feels stable,” “looks better,” and “should be production ready.” Those phrases invite disagreement at the end of the project.

6. Make the first paid milestone a map of reality

When the system is unfamiliar or the problem is intermittent, promising a full fix before diagnosis is guesswork.

A useful first milestone can be small:

reproduce the blocker;
map the critical path and dependencies;
rank the top risks by delivery impact and reversibility;
propose the narrowest repair options;
define acceptance and exclusions;
provide a fixed implementation quote only if the evidence supports one.

This milestone has value even if the original implementation estimate turns out to be wrong. The client receives a testable decision document instead of another vague opinion.

A compact rescue brief

If you need to bring someone into a delayed project, send this before the first call:

Critical user journey:
Current blocker:
Exact reproduction steps:
Expected / actual result:
Evidence and logs (secrets removed):
Last known working version:
Build / test / deploy status:
Deadline and reason:
What may be cut:
Decision owner:

The first deliverable of a rescue is not more code. It is a shared, testable map of reality. Once that map exists, you can decide whether the constraint is code, infrastructure, product scope, ownership, or missing information.

I’m Ivan Li, a technical lead and frontend engineer working around AI-powered video products. I publish practical notes about product rescue, AI workflows, and small-team operations. If you are triaging a delayed release, you can use the brief above for free. For a fixed-scope diagnostic or 5–7 day rescue sprint, see https://ivan-product-rescue.yingong0014.chatgpt.site or email ivan@zstun.com.