Windows can create a Wi-Fi report that helps you match a disconnection to a time and a recorded reason. Use it to organise evidence before changing drivers, router settings or power options. It is a history of your computer’s wireless connection, not a test of your internet plan or a guarantee that a named component caused the problem.
The useful question is specific: did the wireless connection end when the call froze, or did the call fail while Wi-Fi stayed connected? Those observations lead to different checks. If you want a broader repair guide after collecting evidence, see our guide to Wi-Fi that keeps disconnecting.
Create the Windows Wi-Fi report
Microsoft documents this process for Windows 10 and Windows 11 in Analyze the wireless network report. Open Command Prompt as administrator and run:
netsh wlan show wlanreportOpen the HTML report at the location the command displays. It covers recent wireless sessions, normally the previous three days, and includes adapter and system information. Check the report’s own date and coverage before looking for an older incident. If elevation is blocked on a managed computer, give the incident time to IT rather than trying to work around the restriction.
Start with the incident you actually noticed
Before reading every event, write down the approximate time, timezone and symptom. “The meeting stopped at about 10:15” is useful. “The internet is bad” makes it difficult to select the relevant session. Include whether the laptop moved, woke from sleep or switched networks around that time, but label anything you cannot remember as unknown.
Use the report’s session chart to find the matching period. Microsoft explains that an error marker can be selected for further information. Read the surrounding session as well as the highlighted event. A report can contain historical errors unrelated to today’s complaint; selecting the most dramatic red marker is not a diagnosis.
Copy the short reason text into your private notes without rewriting it as a conclusion. Keep three columns: what you experienced, what Windows recorded, and what still needs checking. This preserves the distinction between an observation and your interpretation when you later compare another incident.
A filled Wi-Fi incident report: worked example
Illustrative data, not a real test. Every time and outcome below is invented to demonstrate how to read a report. This is an annotated teaching table, not a Windows screenshot or copied event log. It supplies no test date, device model or driver-version claim.
| Report or observation | Filled example | What to do with it |
|---|---|---|
| Report coverage | Report created at 10:30; its three-day coverage includes the incident. | Check coverage before concluding that a missing event never happened. |
| User’s incident note | At about 10:15, incoming speech stopped and the call reconnected. | This is the experienced symptom, separate from Windows events. |
| Wireless session | The chart’s selected session runs from 09:58 to about 10:15, roughly 17 minutes. | Follow that session’s event list rather than an unrelated error elsewhere in the report. |
| Disconnection reason | The example reason indicates a driver-initiated disconnection. This is a paraphrase, not a verbatim Windows reason string or event ID. | In your private record, retain the actual wording. It does not prove the driver software is defective. |
| Next wireless session | A new session starts at about 10:15:06 on the same network. | The timing supports a brief wireless interruption overlapping the call symptom; it does not establish why it happened. |
| One later comparison | The same activity on a supported Ethernet connection has no observed interruption during a separate 15-minute check. | Record this outside the Wi-Fi report. Wired activity is not a new wireless session, and a short quiet comparison does not prove a permanent repair. |
Useful interpretation: the report and symptom overlap closely enough to investigate the wireless connection first. Save the matching session and reason, note any sleep/wake or adapter change, and pass the adapter/driver identity privately to support if requested. Do not turn driver-related wording into an instruction to delete profiles or replace the router.
The opposite branch matters: if the selected wireless session instead spans 09:58–10:40 with no matching disconnect, the same 10:15 call symptom needs application or wider-path evidence. Wi-Fi association alone does not establish internet access. Check the call’s own diagnostics and record other affected services before choosing a repair.
The field selection follows Microsoft’s report guide. Report coverage, available adapters and reason text vary by computer and event; the example’s approximate times are not a universal reconnect duration.
Compare a disconnect with a slow connection
If the session ends near the incident, investigate the loss of that connection. If the session remains active, the problem may require a different line of evidence. Remaining associated with Wi-Fi does not prove that a website, internet route or application was working normally. Equally, a speed test completed later cannot demonstrate what happened during a brief interruption.
For a current snapshot, the official netsh wlan reference documents read-only commands including netsh wlan show interfaces and netsh wlan show drivers. Record the interface and driver identity if support requests them. Avoid copying nearby commands that delete profiles or change settings simply because they appear in the same reference.
A baseline internet speed test can complement these notes when you are back online. Label its time and connection type. Its download or HTTP timing result does not replace a wireless session record, and it cannot establish the exact cause of an earlier disconnection.
Make the next comparison small enough to interpret
- Choose one repeatable activity. Use the same meeting app, normal browsing task or other activity that exposes the problem. Do not start several bandwidth tests while trying to observe a brief disconnect.
- Keep the location stable for the first observation. Note whether the laptop is plugged in and whether a dock or external adapter is involved. These are conditions to record, not reasons to assume a cause.
- Change one relevant condition. For a location-related complaint, compare a second location. For a problem seen only on Wi-Fi, a supported wired connection can provide another comparison. Keep the rest of the task similar.
- Record the outcome even if nothing changes. An unsuccessful comparison narrows the evidence too. Avoid adding three more changes before checking whether the first one affected the symptom.
If only one room produces the issue, the Wi-Fi dead-zone guide provides a separate coverage investigation. If only this computer struggles while another remains usable, the one-device troubleshooting guide is a better next step than immediately replacing the household router.
Review the report before sharing it
The report contains more than a disconnect timeline. Microsoft lists user, computer, adapter and network information among its sections. Treat the complete archive as a private support document. Review screenshots for network names, account or computer identifiers and addresses; send only the relevant section through the support channel you intended to use.
For escalation, supply the incident time, the affected activity, the matching session/reason text, adapter and driver identity, and the one comparison you performed. Explain what stayed connected and what did not. Do not describe a reason string as proof of an ISP fault or include passwords. The report is most useful when it helps someone ask the next focused question, rather than when it is presented as a verdict.