Diagnose and Fix a Broken Windows PC

Use built-in Windows tools to diagnose a slow PC and fix a DNS issue.

Introduction

30 Second Summary

When someone reports their computer is slow and websites won't load, the first instinct is to restart everything and hope for the best. A real IT support technician follows a structured diagnostic process to isolate the exact problem.

In this project, you will play the role of a Level 1 IT Support Technician responding to a help desk ticket. You will use built-in Windows tools to diagnose a PC layer by layer and write a professional support ticket documenting your findings.

What You'll Build

You will run the same diagnostic commands real technicians use, watch your PC's health stats update in real time, and produce a professional ticket file on your Desktop that any Level 2 engineer could pick up and act on.

By the end of this project, you'll have:

A complete hardware diagnosis showing your PC's resource usage, top processes, and whether CPU or RAM is the bottleneck.
A network investigation proving layer-by-layer connectivity from your machine to the internet using ipconfig, ping, nslookup, and tracert.
A professional support ticket on your Desktop documenting the full investigation from reported symptom to root cause to resolution.
Secret Mission: Flush a stale DNS cache and document before/after evidence proving the fix.

Are there any prerequisites?

You need a Windows 10 or Windows 11 computer with internet access. All tools used in this project are built into Windows, so there is nothing to install.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Set Up Your Diagnostic Workspace

Before you can diagnose anything, you need your tools open and ready. A real IT technician always starts by launching their diagnostic toolkit before touching anything else.

In this step, you'll launch two built-in Windows tools: Command Prompt for running diagnostic commands, and Task Manager for monitoring system resources in real time.

In this step, get ready to:

Open Command Prompt as an administrator.
Open Task Manager in detailed view.
Run your first diagnostic command to inspect your system.

Open Command Prompt as administrator

Some diagnostic commands need elevated privileges to access all system information. Running Command Prompt as an administrator ensures you have full access to every tool you'll use in this project.

Press the Windows key on your keyboard to open the Start menu.
Type cmd into the search bar.
Right-click Command Prompt in the search results.
Select Run as administrator.

What is the pop-up that appears?

Windows will show a User Account Control (UAC) prompt asking if you want to allow this app to make changes to your device. Click Yes to proceed.

This prompt is a security feature that prevents programs from gaining admin access without your permission.

A black Command Prompt window opens. Look at the title bar at the top of the window.

You should see the word Administrator in the title. This confirms you have full diagnostic access.

Don't see Administrator in the title bar?

If your Command Prompt title does not include "Administrator", close the window and try again. Make sure you right-click the Command Prompt result and choose Run as administrator instead of left-clicking it.

If you clicked No on the UAC pop-up, the window won't open at all. Repeat the steps and click Yes when prompted.

Still stuck? Help me open Command Prompt as administrator on Windows.

Open Task Manager

Task Manager shows you exactly what is running on your PC right now. You'll use it in the next step to check whether hardware resources are the bottleneck.

Press Ctrl + Shift + Esc on your keyboard to open Task Manager.

Task Manager may open in a compact, simplified view showing only running apps.

If you are on Windows 10 and see a small window with no tabs, click More details at the bottom of the window to expand it.
If you are on Windows 11, Task Manager opens in the full detailed view by default with a navigation bar on the left side.

You should now see multiple tabs or sections such as Processes, Performance, and Details.

Task Manager won't open?

If the keyboard shortcut doesn't work, try right-clicking the Start button (Windows icon in the taskbar) and selecting Task Manager from the menu.

Need more help? Help me open Task Manager on my Windows PC.

Run your first diagnostic command

The systeminfo command dumps detailed configuration information about your computer. It displays everything from your OS version to your hardware specs in one shot.

Before you run it, what do you think you'll see? A single line, or something more?

Run your first diagnostic by typing this command in Command Prompt and pressing Enter:

systeminfo

A wall of text scrolls through your window. This is your machine's full profile.

Scroll up through the output and locate these five fields:

OS Name (e.g., Microsoft Windows 11 Pro).
System Manufacturer (e.g., Dell Inc., Lenovo).
System Model (e.g., XPS 15 9520).
Total Physical Memory (your RAM, e.g., 16,384 MB).
Processor(s) (your CPU model and speed).

What does systeminfo show?

This command displays detailed configuration information about your computer and its operating system. It includes hardware properties like RAM and processor details, plus OS configuration and network card information.

In a real support scenario, this is one of the first things you'd run to understand what kind of machine you're working with. It answers the question: what are we dealing with?

🙋‍♀️ Command takes a long time or shows an error?

The systeminfo command can take 10-30 seconds to complete while it gathers data. Wait for it to finish before scrolling.

If you see an "access denied" message, make sure your Command Prompt title includes "Administrator". Close the window and reopen it using the Run as administrator option from the first substep.

Still having trouble? Help me run systeminfo in Command Prompt.

Your diagnostic workspace is ready. You have Command Prompt with full admin access and Task Manager standing by. Next up, you'll put these tools to work investigating the "slow PC" complaint by checking hardware resources and running processes.

Investigate the Slow PC

Your diagnostic workspace is ready. Now it is time to play detective and investigate the user's first complaint: their PC feels slow.

Before blaming the network, a good technician checks the machine itself. If CPU or RAM is maxed out, that explains the sluggishness without ever touching networking.

In this step, get ready to:

Check live CPU and memory usage in Task Manager's Performance tab.
Identify the top resource-consuming process on your machine.
Record your hardware baseline and document whether hardware is the bottleneck.

Check live resource usage in Task Manager

Task Manager gives you a live view of how hard your PC is working right now. The Performance tab shows overall system health. The Processes tab shows which individual programs are consuming the most resources.

Switch to Task Manager (it should already be open from Step 1).
Click the Performance tab on the left sidebar.
Observe the CPU graph and note the current usage percentage displayed at the top.
Click Memory in the sidebar and note the usage shown (for example, "8.2 GB / 16.0 GB").

You now have a snapshot of your system's overall health. Next, find out which specific program is using the most resources.

Click the Processes tab on the left sidebar.
Click the CPU column header to sort all processes by CPU usage (highest first).
Look at the top entry. Note down the process name and its CPU percentage.
Also note the memory value next to that process.

What does the Performance tab tell you?

The Performance tab shows overall CPU load across all your processors consolidated into one graph. The Memory section shows how much of your installed RAM is currently in use versus how much is available.

The Processes tab breaks this down per-program. Sorting by CPU reveals the biggest resource hog on your machine right now.

You should now see your CPU usage percentage and memory usage (for example, "8.2 GB / 16.0 GB") in the Performance tab. You can also name the top resource-consuming process on your machine.

Don't see the Performance tab?

If Task Manager looks small with only a list of apps, click More details at the bottom to expand it into the full view with all tabs.

On Windows 11, the tabs appear as icons in the left sidebar. On Windows 10, they appear as text labels across the top.

Help me find the Performance tab in Task Manager.

Record your hardware baseline from Command Prompt

You already ran systeminfo in Step 1 and saw a wall of text. Now you will filter that output to show only the RAM and processor details you need for your ticket.

Before you run the next command, think about this: based on what you just saw in Task Manager, do you expect your PC to be memory-starved or comfortable?

Return to your Command Prompt window and run this command to filter your hardware details:

systeminfo | findstr /C:"Total Physical Memory" /C:"Available Physical Memory" /C:"Processor"

You should see a short output listing your processor, total physical memory, and available physical memory.

What does this command do?

The | (pipe) takes the full output of systeminfo and feeds it into findstr. The /C: flag tells findstr to match the exact phrase in quotes. This filters a wall of text down to just the three lines you care about.

Compare your Available Physical Memory against your Total Physical Memory. If available memory is less than 10% of total, the machine is memory-starved.

🙋‍♀️ Seeing no output or an error?

Make sure each /C: flag is followed by the phrase in double quotes with no extra spaces. The text inside the quotes must match the exact casing that systeminfo produces (e.g., "Total Physical Memory" with capital letters).

Help me fix my findstr command so it shows results.

Document your first troubleshooting entry

A real technician writes down findings as they go. This prevents forgetting details and builds the professional ticket you will create later.

Open a note on your computer (Notepad, Sticky Notes, or any text file).
Write one sentence summarizing your hardware investigation using the real values you just observed.

Your sentence should include: total RAM, available RAM, current CPU usage percentage, the name of the top process and its percentage, and whether hardware is or is not the bottleneck.

What a good entry looks like

Here is an example of the format to follow: "The PC has 16 GB total RAM with 9 GB available. CPU usage is at 12%. Top process: msedge.exe at 8%. Hardware is not the bottleneck." Replace every value with your own real numbers.

💡 Why document as you go?

In IT support, you will often investigate multiple layers before finding the root cause. If you wait until the end to write everything down, you will forget exact numbers and command outputs. Writing as you go builds a reliable evidence trail.

You have confirmed whether the hardware is struggling or healthy. But Task Manager only shows what's happening right now. Next, you'll check Event Viewer for hidden errors the user never sees, like driver crashes or services failing in the background.

Check Event Viewer for System Errors

You now know your hardware resources are not the bottleneck. But a PC can feel sluggish for reasons that don't show up in Task Manager, like a driver crashing silently in the background or a service failing to start.

Windows logs every significant system event behind the scenes. Event Viewer is where technicians go to find errors and warnings the user never sees. A recurring error in the system log often points to the real root cause of a "slow PC" complaint.

In this step, get ready to:

Open Event Viewer from Command Prompt.
Filter the System log for recent Warning and Error events.
Read a log entry and document what it tells you.

Open Event Viewer

You can launch Event Viewer directly from Command Prompt. This is faster than searching for it in the Start menu and reinforces the habit of controlling your machine from the command line.

Open Event Viewer by running this command in your Command Prompt:

eventvwr.msc

A new window opens with a tree menu on the left and a summary in the center.

What does this command do?

The .msc extension launches a Microsoft Management Console snap-in. Running eventvwr.msc opens Event Viewer the same way a shortcut would, but directly from the command line.

🙋‍♀️ Event Viewer didn't open?

If you see an error, confirm your Command Prompt title still includes "Administrator". Some systems require admin privileges to launch management consoles.

Help me open Event Viewer on Windows.

Filter the System log for recent errors

Event Viewer stores thousands of entries. Scrolling through all of them would take forever. Instead, you will filter to show only Warning and Error events from the System log.

In the left panel, expand Windows Logs.
Click System.
In the right panel (Actions), click Filter Current Log....
In the filter dialog, check the boxes for Warning and Error.
In the Logged dropdown at the top, select Last hour.
Click OK.

The log now shows only Warning and Error events from the past hour. You may see a few entries, dozens, or none at all.

What if I see zero events?

Zero errors in the last hour is a good sign. It means nothing has gone wrong at the system level recently. In your ticket, you would note: "Event Viewer System log: no Warning or Error events in the last hour." That's still useful evidence because it rules out background driver crashes or service failures.

🙋‍♀️ Don't see Filter Current Log in the right panel?

Make sure you clicked directly on System under Windows Logs in the left panel first. The Actions panel on the right only shows filtering options when a specific log is selected.

Help me find the filter option in Event Viewer.

Read a log entry and document your finding

Each event entry tells you four things: when it happened, which component reported it, a unique Event ID, and a plain-language description of what went wrong.

Click any Warning or Error entry in the filtered list (if you have entries). The details appear in the bottom pane.
Note these four fields from the entry:

Date and Time (when the event occurred).
Source (which Windows component reported the event).
Event ID (a unique number you can search online for more details).
Description (a plain-language explanation of what happened).

Why do Event IDs matter?

Every Windows error has a unique Event ID. When you include this number in a support ticket, a Level 2 engineer can instantly search Microsoft's documentation or community forums for that exact issue. It is the fastest way to communicate a specific problem.

Add a third entry to your notes. Write one sentence summarizing what Event Viewer showed you.

Your entry should follow this pattern: "Event Viewer System log: [number] Warning/Error events in the last hour. Most recent: [Source] Event ID [number] at [time] — [one-line description]." If you had zero events, note that instead.

What a good entry looks like

Example: "Event Viewer System log: 2 Warning events in the last hour. Most recent: Kernel-Power Event ID 137 at 14:22 — The system firmware has changed the processor's memory type range registers." Replace every value with your own real findings.

You have checked the system logs for hidden problems. Combined with your hardware check from the previous step, you can now confidently say whether the local machine is healthy or has underlying issues. Next, you will move beyond the machine itself and investigate the network layer.

Investigate the Network

You've confirmed the hardware isn't the bottleneck and Event Viewer showed no critical system errors. The user also reported they "can't load a website." That points to a potential network issue.

The structured approach is to work from the inside out. First, confirm your machine has a valid network configuration. Then, test whether packets can actually leave the machine and reach the internet.

In this step, get ready to:

Check your network configuration using ipconfig /all.
Test internet connectivity by pinging Google's public DNS server.
Isolate whether a failure is between your PC and router, or beyond your router.

Check your network configuration

Every device on a network needs four key values to communicate. Your IPv4 Address identifies your machine. The Subnet Mask defines your local network boundary. The Default Gateway is your router's address. DNS Servers translate domain names into IP addresses.

In your Command Prompt, display your full network configuration by running this command:

ipconfig /all

What does this command do?

The ipconfig command displays your network adapter settings. The /all flag shows the full TCP/IP configuration, including DNS servers and DHCP information.

Without /all, you only see IP address, subnet mask, and default gateway. With it, you get the complete picture a technician needs.

You should see a wall of text listing every network adapter on your machine. Look for the adapter that is actively connected (it will have actual values, not blank lines).

Locate and write down these four values from the output:
IPv4 Address (looks like 192.168.1.110).
Subnet Mask (usually 255.255.255.0).
Default Gateway (your router's IP, like 192.168.1.1).
DNS Servers (one or two IP addresses listed).

What if I see 169.254.x.x?

An address starting with 169.254 is an APIPA address. It means your machine could not reach a DHCP server and assigned itself a temporary local address. This indicates no valid network connection. Your router may be off, or your network cable or Wi-Fi is disconnected.

🙋‍♀️ Seeing all blank values or no active adapter?

If every adapter shows "Media disconnected," your machine has no active network connection. Check that your Wi-Fi is turned on or your Ethernet cable is plugged in. Re-run ipconfig /all after reconnecting.

help me figure out why ipconfig /all shows no active network adapter

Test basic internet connectivity

You have your network configuration values. Now you need to confirm your machine can actually send traffic out to the internet. The key insight here: you will ping an IP address directly, not a website name. This tests raw network connectivity without involving DNS.

Before you run the next command, make a prediction. Based on your network configuration values, do you think your machine will successfully reach Google's DNS server at 8.8.8.8? Why or why not?

Test whether your machine can reach the internet by running:

ping 8.8.8.8

If connectivity is working, you will see replies with round-trip times. Something like: Reply from 8.8.8.8: bytes=32 time=14ms TTL=118.

What does this command do?

The ping command sends ICMP Echo Request messages to the target IP and measures the round-trip time. It proves your machine can send packets to a destination and receive responses.

Using 8.8.8.8 (Google's public DNS server) is deliberate. By pinging a raw IP address, you test the network layer alone. If this works but a website won't load, you know the problem is DNS, not connectivity.

🙋‍♀️ Seeing Request timed out?

If you get Request timed out or Destination host unreachable, there is a network-layer problem between your machine and the internet. Check that your Wi-Fi or Ethernet is connected, and that your router is powered on. If your gateway IP from the previous step was valid, the issue may be with your ISP or router's internet connection.

ping 8.8.8.8 is timing out, how do I diagnose the problem?

Test your default gateway

You now know whether your machine can reach the internet. The final diagnostic narrows down where a problem lives. If internet ping fails, is the break between your PC and your router, or between your router and the wider internet?

Ping your default gateway (the router IP you recorded from ipconfig /all) by running:

ping [[GATEWAY_IP="your Default Gateway IP (e.g. 192.168.1.1)"]]

What does the gateway ping tell you?

If the gateway ping fails, the problem is between your PC and your router. Your cable might be loose, your Wi-Fi signal might be too weak, or the router itself might be down.

If the gateway ping succeeds but ping 8.8.8.8 fails, the problem is beyond your router. Your ISP connection might be down, or the router's WAN link might be disconnected.

Document your second ticket entry. Write a sentence summarizing your network findings:

Your entry should cover: the four network values you recorded, the ping 8.8.8.8 result (replies or timeout), the gateway ping result, and whether the network layer is healthy, degraded, or down.

Layer-by-layer thinking

This inside-out approach (gateway first, then internet) is how real L1 technicians isolate problems. Each test eliminates one layer. If your gateway responds but the internet doesn't, you've immediately cut the possible causes in half.

🙋‍♀️ Gateway ping fails too?

If both ping 8.8.8.8 and your gateway ping fail, the problem is local. Check your physical connection (Ethernet plugged in, Wi-Fi enabled and connected to your network). Try disabling and re-enabling your network adapter in Windows Settings.

both ping 8.8.8.8 and my gateway ping fail, what should I check?

Your network layer is mapped. You can reach the internet by IP address. Next up: you'll test whether DNS is working, because if pinging an IP works but websites won't load, the translation from domain names to IP addresses is the likely culprit.

Isolate the Problem — DNS or Network?

Isolate the Problem - DNS or Network?

Your ping to 8.8.8.8 succeeded in the last step, proving your machine can reach the internet by raw IP address. But the user's original complaint was about loading a website, not pinging an IP.

Websites use domain names like google.com, not IP addresses like 8.8.8.8. If pinging by IP works but a website won't load, the problem lives in DNS, the system that translates domain names into IP addresses. This is one of the most common scenarios you'll encounter in L1 support.

In this step, get ready to:

Test DNS resolution with nslookup.
Trace the network route with tracert.
Document your complete network diagnosis.

Test DNS resolution

The nslookup command queries your configured DNS server and asks it to translate a domain name into an IP address. If this works, DNS is functioning correctly. If it fails, you've found the culprit.

Before you run this, think: based on your ping results from the last step, do you expect DNS to be working or broken?

Test DNS resolution by running this command in your Command Prompt:

nslookup google.com

You should see output showing which DNS server was queried (listed after "Server:") and the resolved IP address(es) for google.com (listed under "Non-authoritative answer:").

What does this output mean?

The output has two sections. The first two lines ("Server:" and "Address:") show which DNS server your machine queried. This is the DNS server you recorded from ipconfig /all earlier.

The second section ("Non-authoritative answer:") shows the resolved IP addresses for google.com. "Non-authoritative" means the answer came from your DNS server's cache, not directly from Google's own DNS servers. This is completely normal.

Record the DNS server name and at least one resolved IP address from the output.

Seeing "DNS request timed out" or "Server: UnKnown"?

If you get a timeout or unknown server error, your DNS configuration may be the problem. Check the DNS Servers value from your earlier ipconfig /all output. If it was blank or pointed to an unreachable server, that explains the failure.

Try running nslookup google.com 8.8.8.8 to query Google's public DNS directly. If this works but the default fails, your configured DNS server is the issue.

help me troubleshoot why nslookup is timing out on my Windows PC

Test with a different DNS server

Your default DNS server resolved google.com successfully. But what if it hadn't? A real technician's next move is to test against a known-good public DNS server. This isolates whether the problem is your configured DNS or DNS resolution itself.

Query Google's public DNS server directly by running:

nslookup google.com 8.8.8.8

You should see output similar to the previous nslookup, but the "Server:" line now shows 8.8.8.8 instead of your local DNS server.

What does adding 8.8.8.8 at the end do?

When you add an IP address after the domain name in nslookup, you tell it to query that specific DNS server instead of your configured default. 8.8.8.8 is Google's free public DNS server.

If your default DNS fails but nslookup google.com 8.8.8.8 succeeds, the root cause is your configured DNS server. Switching to a public DNS (like Google's or Cloudflare's 1.1.1.1) is a common L1 fix.

Compare the resolved IP address from both queries. Note whether they returned the same IP or different ones.

Trace the route to the destination

Now that you know DNS works, you can map the exact path your packets take from your PC to Google's servers. The tracert command reveals every router (called a "hop") between you and the destination.

Trace the route to google.com by running this command:

tracert /d google.com

Why the /d flag?

The /d flag stops attempts to resolve the IP addresses of intermediate routers to their names. This speeds up the return of results significantly. Without it, tracert pauses at each hop trying to look up hostnames, which can make the command take several minutes.

This command takes 30 seconds to a few minutes to complete. Watch the output scroll as each hop appears.

You should see numbered lines, each representing a router between you and Google. Each line shows the hop number, three round-trip times in milliseconds, and the router's IP address.

How do I read this output?

The first column is the hop number (1, 2, 3, etc.) starting from your local network.
The three middle columns show round-trip times in milliseconds for three separate probes to that router.
The last column shows the IP address of the router at that hop.
If a hop shows asterisks (*) instead of times, that router did not respond. This is common and does not always indicate a problem. Some routers are configured to ignore these probes.
The final hop should be Google's server. The total number of hops tells you how many routers your data crosses.

Count the total number of hops (the last number in the first column).
Note whether any hops showed asterisks (*) or unusually high round-trip times.

Seeing all asterisks with no final destination?

If every single hop shows asterisks and the trace never reaches the destination, a firewall may be blocking ICMP packets. This does not necessarily mean your internet is broken. Try loading google.com in a browser to confirm actual connectivity.

help me understand why my tracert shows all asterisks

Document your network diagnosis

You now have all the evidence you need to write a complete network diagnosis. This becomes the second entry in your troubleshooting ticket.

Write your second ticket entry using your real findings. Follow this format:

Network connectivity confirmed via ping to 8.8.8.8 ([your round-trip time]ms).
DNS resolution to google.com returned [IP address from nslookup].
Route to destination is [number] hops.
Network layer: healthy / degraded / down.

How do I choose healthy, degraded, or down?

Healthy: ping succeeds with low latency, DNS resolves, tracert reaches the destination with consistent times.
Degraded: ping succeeds but with high latency, or tracert shows some hops timing out or with spikes in round-trip time.
Down: ping fails, DNS fails to resolve, or tracert cannot reach the destination at all.

Save this entry somewhere you can access later (a text file, sticky note, or your notepad). You will use it in Step 5 when you write your full support ticket.

You now have evidence-based findings, not guesses. You can state exactly what works, how fast it works, and how many routers your data crosses to reach the destination.

Your network investigation is complete. You've confirmed connectivity at every layer: hardware, IP, and DNS. Next up, you'll pull all of these findings together into a professional support ticket that any Level 2 engineer could act on.

Write Your Professional Support Ticket

You have investigated the hardware, tested connectivity layer by layer, and traced the network path to its destination. Every diagnostic came back with real data you can point to.

A diagnosis without documentation is useless in real IT support. Every investigation gets logged in a ticket system so other technicians can pick up where you left off. Writing clear, structured tickets is what separates a technician who solves problems from one who creates confusion.

In this step, get ready to:

Create a support ticket file on your Desktop using Command Prompt.
Fill in the ticket with your real diagnostic findings from this investigation.
Review your ticket for completeness as if handing it to a Level 2 engineer.

Create the ticket file

Instead of opening Notepad from the Start menu, you can launch it directly from Command Prompt with a file path. This creates the file exactly where you want it.

Open your ticket file in Notepad by running this command in Command Prompt:

notepad %USERPROFILE%\Desktop\support-ticket.txt

Notepad will ask if you want to create a new file. Click Yes.

A blank Notepad window opens, ready for you to write your ticket. The file is already pointed at your Desktop.

What does this command do?

The %USERPROFILE% part is a Windows environment variable that points to your user folder (e.g. C:\Users\YourName). By appending \Desktop\support-ticket.txt, you tell Notepad to create and save the file directly on your Desktop.

🙋‍♀️ Notepad didn't open?

Make sure you typed the command exactly as shown, including the percent signs around USERPROFILE. If you see an error, confirm you are in the administrator Command Prompt window from earlier.

help me troubleshoot why Notepad won't open from Command Prompt

Fill in the ticket template

A professional support ticket has a clear structure that any other technician can follow. You will write several sections using the real data from your investigation.

In the blank Notepad window, type the following template and replace each placeholder with your actual findings:

Ticket Number: INC-001
Date: [[TODAYS_DATE="today's date, e.g. 20 July 2026"]]
Reported Issue: PC is slow and cannot load a website

DIAGNOSTIC STEPS TAKEN:
1. systeminfo - checked OS and hardware specs
2. Task Manager - checked live CPU and memory usage
3. Event Viewer - filtered System log for Warnings and Errors
4. ipconfig /all - checked network configuration
5. ping 8.8.8.8 - tested internet connectivity
6. ping [[GATEWAY_IP="your Default Gateway IP from earlier"]] - tested local network
7. nslookup google.com - tested DNS resolution
8. nslookup google.com 8.8.8.8 - tested against public DNS server
9. tracert /d google.com - traced route to destination

What goes in the diagnostic steps section?

This section lists every command and tool you used, in order. A Level 2 engineer reading your ticket needs to know exactly what was already tested so they do not repeat your work.

Now add the findings section below the diagnostic steps. This is where your real data goes.

Below the diagnostic steps, type a FINDINGS: heading and add one line for each diagnostic area:

FINDINGS:
Hardware: [[HW_STATS="your RAM total/available and CPU %, top process name and %"]]
System Logs: [[EVENT_VIEWER="number of Warning/Error events in last hour, most recent Source and Event ID"]]
Network Config: [[NET_CONFIG="your IPv4 address, gateway, DNS server"]]
Connectivity: [[PING_RESULT="ping 8.8.8.8 result and time, gateway ping result"]]
DNS: [[DNS_RESULT="nslookup result from default and public DNS, IP address resolved"]]
Route: [[ROUTE_RESULT="number of hops from tracert, any timeouts seen"]]

Where do I find these values?

Scroll up in your Command Prompt window to find the output from each command you ran in the previous steps. Your Task Manager is also still open with live stats. Use the exact numbers from your machine.

Finally, add the root cause and resolution sections. This is your professional conclusion based on the evidence.

Below your findings, type the final two sections:

ROOT CAUSE:
[[ROOT_CAUSE="your evidence-based conclusion about the reported issue"]]

RESOLUTION / NEXT STEPS:
[[RESOLUTION="what you would do next to resolve the issue"]]

What should I write for root cause and resolution?

Base your root cause on the evidence. If hardware was normal, connectivity worked, and DNS resolved, the issue is likely browser-level or transient. State that clearly.

For resolution, recommend a concrete next action. For example: clear the DNS cache as a precaution, and if the issue persists, escalate to Level 2 for browser or proxy investigation.

🙋‍♀️ Not sure what to write?

If your diagnostics all came back healthy, a valid root cause is: "Hardware resources normal. Network connectivity confirmed. DNS resolution functional. Issue likely browser-level or transient." There is no wrong answer here as long as your conclusion matches your evidence.

help me write a root cause statement for my support ticket based on my diagnostic findings

Save and review your ticket

Your ticket is complete. Before you call this done, review it the way a Level 2 engineer would.

Press Ctrl+S to save the file.
Read through your ticket from top to bottom.
Ask yourself: if a Level 2 engineer received this ticket, would they know exactly what was tested and what was found without asking you a single follow-up question?
If any section is vague or missing real numbers, go back and add detail from your Command Prompt history.

Before you check your Desktop, what do you expect to find there?

Minimize Notepad and look at your Desktop. You should see a file called support-ticket.txt.
Double-click it to reopen and confirm all sections are present: Ticket Info, Diagnostic Steps Taken, Findings, Root Cause, and Resolution.

Don't see the file on your Desktop?

Make sure you pressed Ctrl+S in Notepad before minimizing. If you closed Notepad without saving, rerun the notepad %USERPROFILE%\Desktop\support-ticket.txt command and rewrite your content.

help me find where my support-ticket.txt file was saved on Windows

✔️ Awesome, I've got everything!

Great. Double-check that your ticket has real numbers from your machine in every section, not placeholder text.

ⓧ I'd like to double check the full ticket

Your completed ticket should have these six parts, in order:

Ticket Number (INC-001) and Reported Issue.
Diagnostic Steps Taken listing all 9 commands/tools.
Findings with real data for Hardware, System Logs, Network Config, Connectivity, DNS, and Route.
Root Cause with an evidence-based conclusion.
Resolution / Next Steps with a concrete recommendation.
User Communication with a plain-language summary for the end user.

If any section is missing, add it now and press Ctrl+S again.

Write a plain-language summary for the user

Your ticket is written for a Level 2 engineer. But the user who reported the problem also needs a response. They don't speak in ping times and Event IDs. Translating technical findings into plain language is a core IT support skill.

At the bottom of your support-ticket.txt file, add a new section:

USER COMMUNICATION:
Hi [user name],

I've looked into the slow PC and website issue you reported.
[[USER_SUMMARY="2-3 sentences explaining what you found and what you did, in plain language the user would understand"]]

Please let me know if the issue comes back.

Thanks,
[Your name]

What makes a good user response?

A good response avoids jargon. Instead of "DNS resolution was functional and tracert completed in 12 hops," write something like: "I tested your internet connection and it's working correctly. The slowness may have been caused by a temporary issue that has since resolved."

Name what you checked, what you found, and what happens next. The user should feel informed, not confused.

Replace the placeholder with your own plain-language summary based on your real findings.
Press Ctrl+S to save.

Secret mission

Fix a DNS Issue with Evidence

You've proven DNS works for google.com. But what happens when a cached record goes stale and a site won't load? In this mission, you'll flush the DNS cache and capture before/after evidence of the fix. This is one of the most common quick fixes in real IT support.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally using built-in Windows tools, so there are no ongoing costs.

Resources you used:

support-ticket.txt file on your Desktop.
Command Prompt window (open as administrator).
Task Manager window.

Keep everything running

No action needed. Choose this if you're still actively exploring the diagnostic commands or want to keep experimenting.

Your support-ticket.txt stays on your Desktop as a reference for future troubleshooting.
Command Prompt and Task Manager remain open for further practice.
No built-in Windows tools were installed during this project, so nothing new is sitting on your machine.

Pause - I'll come back to this later

Shut down open windows to free up memory, but keep your ticket file for when you return.

Close Task Manager by clicking the X in the top right corner.
Close Command Prompt by typing the following and pressing Enter:

exit

Your support-ticket.txt file remains on your Desktop, ready for you to pick up where you left off.

Delete - I don't want to use this again

Remove all project files and close everything. This cleans your Desktop completely.

Delete support-ticket.txt by running this command in Command Prompt:

del %USERPROFILE%\Desktop\support-ticket.txt

Confirm deletion by running:

dir %USERPROFILE%\Desktop\support-ticket.txt

You should see "File Not Found" confirming the file is gone.

Close Task Manager by clicking the X in the top right corner.
Close Command Prompt by typing exit and pressing Enter.

Nice Work!

You just completed a full IT support investigation using nothing but built-in Windows tools. You diagnosed a PC from hardware to network to DNS, and documented the whole thing like a professional technician.

Here's what you learned:

Used Task Manager, Event Viewer, and systeminfo to assess hardware health, identify top processes, and check for hidden system errors.
Used ipconfig /all, ping, nslookup (including testing against a public DNS server), and tracert to diagnose network connectivity layer by layer.
Wrote a professional IT support ticket with structured documentation and a plain-language user response that any Level 2 engineer or end user could act on.
Used ipconfig /flushdns to fix a stale DNS cache and documented the fix with before/after evidence (Secret Mission).

Ready to quiz yourself?