Open an administrator Command Prompt and run netsh wlan show wlanreport. Open the HTML report at the path shown, find the time of the interruption, and compare the wireless session events with what you observed. Use the report to pick the next test before changing any network settings.
Record the time and scope of the fault
Write down the approximate time you noticed the interruption, the room you were in, and whether the computer was stationary or moving. Check whether Windows still showed a wireless connection. If possible, use another device on the same network during the interruption. A video call that freezes while another device keeps working is a different starting point from a whole household losing internet access. Record what you saw before relying on the report to fill in what happened.
A useful record is specific. For example, write that a call froze at 10:17 while the laptop was on a desk in the back room, and that the phone continued loading new pages. Add whether the laptop had just woken from sleep or switched from a dock to Wi-Fi. Those details make it easier to find the right event and avoid confusing a normal reconnect with a failure that needs attention.
Generate and open the report
Search Start for Command Prompt, open it as administrator, and enter netsh wlan show wlanreport. Windows prints the location of the generated file. Open that location using File Explorer or a browser. Microsoft’s wireless report guide explains how the HTML report groups recent wireless events and system information. Use a fresh report soon after reproducing the issue. An earlier report reflects the history available when it was generated.
The report can contain device details, network names, profile names and other information that can identify your setup. Read it before sharing it with a support provider. A time, relevant disconnect reason and a description of the symptoms may be sufficient for a first request. Avoid posting the entire report publicly. On a managed machine, follow your organization’s process if you need permission to run the command or pass the resulting file to IT.
Find the relevant wireless session
Start with the summary chart and find the period you wrote down. Follow the events into the session details. Look at the adapter and network involved, whether a connection was established, and the order in which the disconnect and reconnect events appeared. A reason shown after you manually switched networks may describe your action. Compare it with events immediately before the symptom. Treat the reason as a clue to reproduce rather than as proof that a named component has failed.
If several similar events appear, compare a normal session with a bad one. Look for a change in duration or a repeated sequence at the point where work was interrupted. If a session ends around the time a laptop sleeps, repeat while it remains awake. If you move between two access points, repeat the same route and note where the issue occurs. A repeated sequence after a specific action gives you a stronger basis for the next test than a count of all events combined.
Choose the next test based on what stayed connected
If the report records a disconnect on only the laptop, start with a comparison near the router or with a known-good access point you control. Keep the laptop in one position for the first test. If a near-router session is reliable while the normal desk repeatedly drops, use our router placement guide to compare positions. If the fault appears when moving between mesh nodes, repeat a stationary test as a control before changing the network design.
If the wireless session remains connected but a particular website fails, check another site and another device. Try the tests in our Windows DNS troubleshooting guide when the symptoms point to name resolution. A disconnected wireless session and a failed name lookup can both stop a page from opening, but they leave different evidence. When multiple devices fail together, compare a wired device if available before assuming the laptop’s wireless adapter is responsible.
Check the adapter without losing your baseline
Review the adapter listed in the report, especially if you sometimes use a USB Wi-Fi adapter or a docking station with its own network hardware. Check Device Manager and the computer maker’s support information for the exact adapter and driver. Record the current version before updating it. If the problem appeared after an update, consult the manufacturer for a supported recovery path. Keep another way to reach support or the internet if the wireless adapter is your only connection.
When a router uses several bands, note which band or access point the client is using during each test. Our Wi-Fi band guide explains why a shorter-range band may work well near the router and differently behind a wall. If you change the driver, location and network at the same time, it becomes harder to identify the cause. Start with the least disruptive comparison and generate another report after you can reproduce the difference.
Verify the result with the same workload
Repeat the task that was failing. If the issue appeared during a video call in one room, use that room and a comparable call length. Record whether the computer remained connected and whether the application recovered. A few quick page loads cannot establish that an intermittent problem has disappeared. Check more than one normal session if failures occurred only occasionally before the change.
Keep a short summary containing the time, symptom, relevant report event and the result of your controlled test. If you ask for help, tell the provider what remained working as well as what failed. For example, a stable Ethernet test during the same interruption can help narrow the investigation. Save reports only as long as they remain useful and in a location suitable for the details they contain.
For a fault that happens after sleep, run two tests on the same network. First leave the laptop awake for the length of a normal session. Then put it to sleep, wake it and repeat the same task. Write down when connectivity returns in each case. A repeatable wake-related delay is more specific information than saying the wireless connection is unreliable all day.
If your work depends on a VPN, also record whether it dropped while Wi-Fi stayed associated. Check the VPN client’s own connection history and share the two timestamps with your support team if appropriate. That comparison can show whether the wireless interruption happened before or after the tunnel stopped passing traffic.
Frequently asked questions
Does the report fix the connection?
It records events and adapter details. Use that evidence to select and verify a change.
What if it shows no disconnect?
Test whether other apps and devices still work. The problem may be with DNS, the upstream internet connection or a particular service.
Can I compare two reports?
Yes. Record the conditions for each one and compare the session around the same kind of event rather than total disconnect counts alone.
