Collect a useful baseline

Decide what the baseline must prove

Microsoft's freeze-troubleshooting guidance begins with scope questions: which computer is affected, what operation was happening, how often the issue occurs and how many systems are affected. Those questions turn a complaint into a comparable state rather than a guess about the cause.

A good baseline answers four questions. What was the user doing? What did Windows report at that moment? What changed shortly before the problem began? What result would count as improvement? For a slow launch, elapsed time and resource use matter. For a crash, the exact time, stop code and recent driver change matter. For a battery complaint, charge level, workload and full-charge capacity matter. Collect only evidence connected to the symptom.

Capture identity and time before the state changes

Record the local date and time, Windows edition, version and OS build, device model when available, and whether the PC had just started, resumed from sleep or been running for hours. Time is essential because Event Viewer, update history and reliability records are organized around timestamps. A note such as 'around lunchtime' is difficult to correlate; 14:37 local time is useful.

Protect privacy while recording. User names can appear in file paths, screenshots and exported reports. Redact email addresses, device IDs, serial numbers and document names before sharing evidence publicly. The baseline should identify the technical environment without becoming an inventory of personal information.

1. 1

   Press Windows + I and record Windows edition, version and OS build from System > About.

2. 2

   Write the local date and exact time at the start of the observation.

3. 3

   Note whether Windows was freshly started, resumed from sleep or already under load.

4. 4

   Record the app, file, website, peripheral or network action involved.

5. 5

   List updates, drivers, applications or hardware changed shortly before the symptom began.

Measure idle and problem states separately

Microsoft training on Windows client performance treats a baseline as the normal performance reference used to identify deviations. Task Manager is suitable for a quick snapshot, while Performance Monitor or specialist traces are used when a short snapshot cannot capture an intermittent issue.

Wait one quiet minute and record overall CPU, memory and disk use. Then reproduce one normal workload that triggers the issue, if doing so is safe, and record the same values. Also measure the user-visible result: launch time, copy speed, disconnect count, freeze duration or battery percentage change. A percentage without the workload context is weak evidence; the same percentage connected to a repeatable delay is meaningful.

1. 1

   Open Task Manager with Ctrl + Shift + Esc and wait one minute without launching new work.

2. 2

   Record overall CPU, memory and disk percentages and the highest-using process in each relevant column.

3. 3

   Start the exact task associated with the symptom.

4. 4

   Record elapsed time and the resource value that changes with the symptom.

5. 5

   Repeat once under the same conditions to see whether the pattern is consistent.

6. 6

   Save one screenshot or note with the timestamp and workload description.

Define the comparison before testing a change

Write the pass condition before changing anything. For example: 'After disabling one startup application, sign-in to a usable desktop should fall from 95 seconds to below 60 seconds on two consecutive restarts.' This prevents moving the goal after the test. If the result improves once but not again, treat it as inconclusive.

Keep a change log with one row per test: time, change, reason, result and reversal. If a repair requires several commands, preserve their output separately. A baseline is valuable only when the after-state is measured using the same workload and timing method.

Stop collecting when the evidence is sufficient or the risk rises

More data is not always better. Once the symptom, scope, timing and one relevant measurement are clear, move to a low-risk hypothesis. Do not install multiple monitoring tools simply because they produce attractive charts. Every tool can change system load and create additional privacy or security questions.

Stop reproduction immediately if the drive reports a critical warning, the battery is swollen, the machine smells hot or electrical, files are disappearing, or each test increases instability. Preserve data first and escalate to qualified service.

Common mistakes to avoid

• Collecting screenshots without timestamps or workload context.
• Changing several settings before recording the original state.
• Calling a process suspicious solely because its name is unfamiliar.
• Continuing a test after storage, battery or temperature warning signs appear.