If WiFi disconnects and then reconnects by itself, Windows can help you reconstruct what happened. The command netsh wlan show wlanreport creates a report covering recent wireless sessions. Its value is in matching the time of the interruption to events recorded by your computer. The report does not repair the connection, and it will not always identify a single cause.
This guide focuses on Windows 11, although the command also exists in Windows 10. You need a WiFi adapter and administrator permission to generate the report. Run it soon after the problem: the default report covers the last three days rather than your computer’s entire connection history.
Record the symptom before generating the report
During the next interruption, note the time and what stopped working. Check whether Windows lost its connection to the wireless network or stayed connected while a website failed to load. Also record whether you had just opened the lid, moved away from the router, or started a download. Those details help separate relevant events from ordinary disconnections.
Consider a hypothetical example: a meeting stops at 6:42 p.m., but Windows still shows a WiFi connection and your phone also loses Internet access. That deserves a different investigation from a laptop that leaves the network immediately after waking while every other device continues browsing. Treating both situations as the same fault can send you toward the wrong component.
Generate and open the HTML file
- Open Start, search for Command Prompt, and select Run as administrator. Approve the Windows prompt if you are authorized to administer the computer.
- Enter the command below and press Enter. Wait for it to finish; you do not need a separate diagnostic application.
- Copy the HTML file location shown in the console. Paste it into File Explorer’s address bar and open the file in your browser.
- Save a dated copy if you want to preserve this diagnosis before generating another report.
netsh wlan show wlanreport
If you receive a permissions error, check that Command Prompt is elevated. A computer without a wireless interface cannot use this report to diagnose Ethernet. If another error appears, preserve its full message. Running network reset commands is not a useful substitute for understanding why the report could not be created.
Find the session that matches the interruption
Check the creation date and the time period covered by the report. In the chart near the top, select a session to jump to its details. Events marked as errors deserve attention, but their presence alone does not prove they caused your particular interruption. Start with the time you wrote down rather than the most dramatic-looking item.
Within that session, identify the network name, duration, and disconnect reason. Expand events close to the interruption and read them in sequence. The summary of disconnect reasons can reveal repeated patterns. The adapter section provides the device identity, driver version, and any recorded problems associated with that adapter.
Keep different networks separate. If you used the laptop at home and then elsewhere, a disconnection between those sessions is expected. Similarly, a session ending when you shut down the computer is not evidence against the router. Context turns an error list into a sequence that you can investigate.
Turn the evidence into a useful next check
| What you observe | Useful next check |
| Repeated interruptions in one location | Repeat the same task closer to the router. |
| A problem immediately after waking | Compare operation before and after sleep. |
| Trouble establishing the connection | Check whether access to that network changed. |
| Several devices fail at the same time | Check the router and Internet service. |
| The wireless session continues during the failure | Investigate the application or Internet access. |
These relationships are working hypotheses. A disconnect message associated with the adapter does not necessarily mean you need to replace it. An authentication message does not prove someone changed the password. You may need to review network settings or, on a work network, ask the administrator. Look for a repeatable pattern before making a decision.
For example, imagine six short sessions at a desk in the back room and one long session beside the router. Location becomes a useful variable to test. If the same laptop misbehaves on two unrelated networks, the computer deserves closer attention. Either comparison tells you more than changing five settings at once.
Choose one test and keep a baseline
- If coverage looks suspicious, use the same computer near the router with a similar task. Keep the application and other conditions as consistent as practical.
- If the failure follows wake-up, perform a controlled sleep and resume. Note when connectivity returns and whether other devices stay connected.
- If only this computer fails, record its adapter model and check Windows Update or the computer manufacturer’s support page. Compare driver versions before installing anything.
- If multiple devices lose access together, check the router’s status and your provider’s service notices. One laptop’s report cannot establish that its driver caused a network-wide problem.
Avoid uninstalling the adapter as your first experiment. Losing your only Internet connection can make it harder to obtain the correct driver afterward. If you later need to investigate a driver regression, keep the existing version number and the manufacturer’s compatible installer available before making the change.
Check whether the change actually worked
After changing one variable, repeat the original scenario and generate another report. Compare the period after the change rather than historical errors that remain in the file. Five quiet minutes do not establish that an interruption occurring once an hour has disappeared. Observe a period that represents your normal use.
If the wireless link stays active while browsing fails, change the question you are investigating. You are no longer looking for why WiFi disconnects, but for which part of Internet access stops responding. A DNS comparison can be useful when name resolution is the specific symptom, but it should follow the evidence rather than replace the wireless investigation automatically.
Prepare useful information when asking for help
Collect the failure time, network used, relevant event message, adapter model, and results of your comparisons. The HTML can contain user, computer, and network names, network addresses, and other configuration details. For a public forum, share relevant excerpts with identifying details hidden rather than uploading the entire report without reviewing it.
A useful outcome is a concrete distinction: the failure depends on location, resume from sleep, one computer, or the whole network. If you cannot yet tell which, preserve the report and your observations. That record lets the next investigation build on the first interruption instead of starting from scratch.
