Complete tutorial on netsh trace in Windows

If you work with Windows and you're dealing with network problems, the command netsh trace It's one of those tools that's worth having on hand. It allows you to capture traffic, log internal system events, and generate comprehensive reports without installing anything extra—perfect for corporate environments or locked-down systems where you can't use Wireshark or similar tools.

Throughout this tutorial we will see, in considerable detail, how it works netsh trace on WindowsThis article explains what each subcommand does, how to use predefined scenarios, which parameters are truly important for day-to-day operations, how to reduce the size of trace files with filters, and how to leverage the generated ETL and CAB files. The goal is for you to finish the article knowing not only what to type in the console, but also why certain options are used and what to expect from each one.

What exactly is netsh trace and what is it used for?

The command netsh trace It is part of the online utility of commands netsh.exe, present in Windows for many years. Within netsh, the context trace It relies on the infrastructure of Event Tracing for Windows (ETW) to record very detailed system events and, optionally, capture network packets. This gives you a very deep view of what is happening in the network stack and other related components.

With this command you can start and stop tracking sessionsConvert the resulting ETL files to other formats (TXT, CSV, XML, EVTX, etc.), correlate multiple traces, export scenarios to Windows Performance Recorder profiles, and much more. It does all this without installing any additional agents or tools, making it a key resource for support, forensics, or troubleshooting on production servers.

In systems such as Windows 7 and Windows Server 2008 R2 and later versions, this means it's no longer mandatory to set up tools like Wireshark or Network Monitor to make a decent capture: you can use netsh trace from a console with administrator privileges and obtain both network traffic and a broad context of the system state during the incident.

General syntax of the netsh trace command

Subcommands: netsh trace

The netsh trace context exposes a series of subcommands, all accessible with a very simple base syntax. Generally speaking, it works something like this: netsh trace <subcomando> These are the most important subcommands it offers:

Convert: netsh trace convert tracefilename.etl filename CSV|XML|EVTX|TXT|No yes|no yes|no yes|no pathname pathname

Correlation: netsh trace correlate tracefilename.etl newtracefilename.etl Activity_ID yes|no yes|no yes|no yes|no

Diagnosis: netsh trace diagnose <scenarioname> <attributeValue> <yes|no> <yes|no> <yes|no>

Dump: netsh trace dump

To export: netsh trace export <scenarioname> <filename>

To combine: netsh trace merge

Restore: netsh trace postreset

Display: netsh trace show <capturefilterhelp> <globalkeywordsandlevels> <helperclass> <helperclassname> <interfaces> <provider> <providerIdOrName> <providerfilerhelp> <providers> <scenario> <scenarioname> <scenarios> <status>

Home: netsh trace start =<sessionname> <scenario1,scenario2> keywords level yes|no] physical|vmswitch|both yes|no|disabled yes|no path\filename filemaxsize single|circular|append yes|no yes|no|disabled providerIdOrName keywordMaskOrSet level <bufferSize> provider2IdOrName yes|no keyword2MaskOrSet yes|no level2 ...

With this in mind, We're going to break down what each command does. And what parameters are really important to you on a daily basis, without losing sight of the advanced details that sometimes make the difference when the problem is serious.

The `convert` subcommand transforms ETL files into other formats.

The command netsh trace convert It's used to transform an ETL trace file into other formats that are easier to query or analyze with scripts. Additionally, it can generate a complete HTML report and add extra metadata if needed for advanced debugging.

We've already seen the basic syntax, but it's worth reviewing what each important parameter means. convert and how it affects the final conversion result.

input: indicates the file input ETL that you want to process. It's the trace file previously generated by a session of netsh trace startWithout this parameter there is nothing to convert.

output: defines the output file name and pathIf you do not specify anything, the command uses the same name as the input file, with the extension corresponding to the type of dump you have chosen.

dump: specifies the dump format that you want to generate: you can choose between CSV, XML, EVTX, TXT o NoIf you leave the default value, the command generates a standard text dump, very useful for a quick review or for loading into simple tools.

report: determines whether or not a HTML report starting from the trace. If you put it to yesYou will obtain an HTML file with graphics and added information that greatly helps in diagnostic tasks.

overwrite: check if they can overwrite existing filesIf you fix it on yesThe command will replace the output file if it already exists with the same name; with no That overwriting will be avoided.

metadata: indicates whether you want to include it in the result metadata trackingBy activating it (yes) additional context traces are added which are useful when working with advanced decoding or WPP-type providers.

tmfpath: here you define the route to the TMF files (Trace Message Format) used to decode traces generated by WPP (Windows Software Trace Preprocessor). This is necessary if you are analyzing custom WPP providers.

manpathSimilar to the previous one, but targeting the manifest files that describe classic ETW events. It helps to display events in a readable way when the system does not already have all the vendor information recorded.

correlate subcommand: filter and normalize traces

The command netsh trace correlate It allows you to take one or more ETL files and generate a new filtered or normalized output file. This is especially useful when you want to focus on a specific activity identified by an activity GUID, or when you are handling very large traces and need to narrow down the information.

The most interesting option is filter, which lets you specify a Activity_ID in GUID format (for example {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}and generates a new trace that only contains events related to that identifier. This drastically reduces noise when investigating a very specific request or session.

Addition activity filterThere other parameters that control what type of information is kept in the resulting trace and what is deleted, something very relevant in scenarios where personal data or global system information is handled.

retaincorrelationevents: if you define it as yesThe new archive preserves the correlation events Used internally to link events together. They are useful for reconstructing the logical sequence of a complex operation.

retainpii: allows you to decide whether to keep them events involving personal data (PII). Its default value is usually yeswhich preserves all the information, but in sensitive environments you could set it to no to avoid revealing certain details.

retainglobalevents: checks if the global system eventsBy default, it is usually enabled, which helps to provide context about what was happening on the computer while the network problem was occurring.

diagnose subcommand: guided diagnostic scenarios

The subcommand netsh trace diagnose It is designed to launch automated diagnostic sessions based on preconfigured scenarios. Instead of having to choose ETW providers, levels, and filters one by one, you select a scenario like InternetClient and you let Windows enable everything necessary.

The key parameter is scenario, where you indicate the name of the diagnostic scenario that you want to run. For example, for internet connectivity problems, you would choose InternetClientFor other problems, there may be specific scenarios for LAN, WLAN, FileSharing, DirectAccess, etc.

The option namedAttribute It's used to pass scenario-specific additional optionsFor example, specific details that the scenario itself can use to focus the diagnosis. The set of available attributes changes depending on the selected scenario.

With saveSessionTrace you decide whether the trace generated during the diagnosis is save for later analysisIt is usually linked to the parameter reportwhich controls the generation of a report. If report=yes, usually saveSessionTrace is activated by default yes so that you have both the report and the raw trace.

Parameter report allows you to activate the creation of a diagnostic report at the end of the scene. If you set it to noThe system will not generate that report, even if the ETL trace was saved as indicated in saveSessionTrace.

Finally, the option capture decide if, in addition to ETW event registration, you want capture real network traffic during diagnosis. With capture=yes You will get network packets in the ETL, at the cost of generating a larger and potentially more sensitive file.

Other key subcommands: dump, export, merge, postreset, show, and help

Beyond login, conversion, and diagnostic commands, netsh trace It includes other subcommands that are useful to know because they facilitate the management of trace configurations or the subsequent analysis of data.

Use dump: netsh trace dump

Export usage: netsh trace export

Use merge: netsh trace merge

Use of postreset: netsh trace postreset

Show details: netsh trace show

The classic help o ? within the context trace muestra the list of commands and their descriptions In that specific context, something that always comes in handy when you don't remember the exact syntax of a parameter or want to see what new options are available in the version of Windows you're using.

Start subcommand: Start a network monitoring session

The heart of the whole system is netsh trace start, which is responsible for start a trace sessionThis is where you choose the scenario, enable or disable packet capture, define the output file, the maximum size, the file mode, and a bunch of advanced options to adjust the level of detail.

One of the key parameters is sessionnamewhich allows you to assign a session identifier nameIt's not mandatory, but it helps distinguish between different sessions when checking settings or status with netsh trace show status.

With scenario You can select one or more predefined scenarios diagnostic, such as LAN, InternetClient, FileSharing o DirectAccessA scenario is simply a set of ETW providers and configurations designed for a specific type of problem, and it saves you from having to go provider by provider.

Parameters globalKeywords y globalLevel control the global event filter which will apply to all suppliers. globalKeywords defines which ETW “keywords” are taken into account, while globalLevel Set the minimum level of severity or detail you want to record.

The value of globalLevel It usually ranges from 1 to 5, each with a fairly clear meaning:

• 1 (Critical)Only critical events, typically serious failures, are recorded.
• 2 (Error): includes critical events and errors.
• 3 (Warning): adds warnings to critics and errors.
• 4 (Informative): adds informational events.
• 5 (Detailed): records absolutely all events, including debugging details.

If you activate capture a yesThe session will not only record ETW events, but also real network packetsYou can control the scope of that capture with capturetypewhich accepts values ​​such as physical (physical adapters), vmswitch (Hyper-V virtual switches) or both if you want to cover everything.

With the parameter report you decide if the system should Generate an HTML report at the end of the session. Typical values ​​are yes, no o disabledDepending on whether you want to always report, never, or leave this functionality completely disabled.

The option persistent It is especially interesting in long-term diagnoses, because it allows the tracking session survives a reboot of the team. If you activate it with persistent=yesThe trace will continue after the restart until you explicitly stop it with netsh trace stop.

With traceFile you establish the ETL file path and name where the trace will be stored, for example traceFile=C:\Logs\networktrace.etlIf you don't specify, default names like nettrace.etl in the current working directory.

Parameter maxSize fix the maximum size in MB of the ETL fileIt is closely linked to the parameter fileModewhich defines how the file behaves when that maximum size is reached: single (a single file until the limit is reached), circular (the oldest data is overwritten, acting as a circular buffer) or append (Data is added to the end of an existing file).

The option overwrite check if possible overwrite an existing ETL fileIf you want to make sure you don't accidentally lose old traces, you can leave it in noIf you prefer that the same filename is always used and replaced when necessary, you put it in yes.

With correlation you decide whether or not to enable the correlation of events within the trace, which can help reconstruct call chains or complex workflows. Possible values ​​are yes, no o disabled, depending on the level of support you want.

The capturefilters allow to apply specific filters for captured packetsFor example, to limit traffic to a specific IP address, TCP port, protocol, etc. This reduces the volume of data and focuses the analysis on what you're really interested in.

Parameters provider, Keyword y level They let you fine-tune the trace even further at the level of individual ETW providerYou can specify a particular provider by GUID or name, assign it a set of keywords and a level of detail different from the overall one, and repeat this combination for multiple providers within the same session.

The adjustment bufferSize determines the trace buffer size in memory. A small buffer can cause event loss in high-load scenarios, while a buffer that is too large can consume more memory than necessary, so it should be adjusted according to the environment.

Lastly, providerFilter y perfMerge They add an extra layer of control: the first one activates vendor-specific filters (when available), and the second indicates whether they should be combine performance data with the main trace, which is very useful when analyzing bottlenecks or network performance problems.

Practical examples of using netsh trace

To see in practice how all these parameters are applied, it is worth reviewing some real commandos which you can use as a template. From there, it's easy to adjust small things to adapt them to your environment.

Example Convert: netsh trace convert input="C:\Logs\mytrace.etl" output="C:\Logs\mytrace.xml" dump=XML

Example Correlation: netsh trace correlate input="C:\Logs\trace1.etl,C:\Logs\trace2.etl" output="C:\Logs\correlated_trace.etl"

Create TXT: netsh trace convert input="C:\Logs\mytrace.etl" output="C:\Logs\mytrace.txt" dump=TXT

Example Merge: netsh trace merge input="C:\Logs\trace1.etl,C:\Logs\trace2.etl" output="C:\Logs\merged_trace.etl"

List interfaces: netsh trace show interfaces

Log in: netsh trace start capture=yes tracefile="C:\Logs\networktrace.etl" report=yes persistent=yes

Scenarios, persistence, and circular logging in Windows 7/2008 R2 and later

In environments such as Windows 7 and Windows Server 2008 R2 It's no longer essential to use external tools to analyze traffic. With an administrator console, you can simply run something like this: netsh trace start with the appropriate parameters to obtain a useful capture, even persistently. They are also useful for analyze Windows startup when combined with system-specific tools.

Run: C:\Windows\system32> netsh trace start capture=YES report=YES persistent=YES

Stop: C:\Windows\system32> netsh trace stop

When you no longer need to record information, you stop monitoring with:

Upon completion, they are generated by default. two very important files: a file with the extension . .ETL (Event Trace Log), which is where the events and packets are stored, and a file .CAB which groups additional information, such as details of the hardwarenetwork adapters, operating system version, and wireless configuration.

The use of netsh trace to "snort" traffic It is especially practical in forensic analysis or on systems where installing new software is not permitted. Besides being convenient, it offers advantages such as the ability to configure persistent traces that survive reboots and the option to use circular recording modeWith this, you can leave a session active indefinitely until the event you are looking for occurs, without the trace file growing without limits.

Another strong point is the specific predefined scenariosWith commands like netsh trace show scenarios You can see what network scenarios are available, and then start a trace focused on a specific case, for example:

netsh trace start scenario=InternetClient

If you want to expand the information even further, you can combine several scenarios or add individual providers to a main scenario. For example, to follow the scenario wlan and, in addition, the DHCP client provider:

netsh trace start scenario=wlan provider=Microsoft-Windows-Dhcp-Client

To delve deeper into a specific provider and see what keywords and levels it displays, you can use:

netsh trace show provider Microsoft-Windows-TCPIP

Consult help: netsh trace start /?

Output files: ETL, CAB and HTML reports

When you stop a trace session, Windows generates at least two types of file. On the one hand, the ETL file main (default) nettrace.etl, unless you have defined another name with tracefile=), which contains the ETW events and, if you enabled capture, the network packets.

That ETL file can be opened with various analysis tools, such as the old Network Monitor, Windows Performance Analyzer or even PowerShell using Get-WinEvent to extract information programmatically. Furthermore, through netsh trace convert You can obtain CSV, XML, EVTX or TXT versions to process it with other systems.

On the other hand, you have the .CAB file, normally called by default nettrace.cabThis file includes rich system information, such as hardware data, network adapters, operating system versions, wireless parameters, and generally everything that provides context for the diagnosis. Within this CAB file, you will typically find a Report.etl (copy of the main information) and a report.html with a generated report if you activated report=yes upon logging in.

To obtain the greatest possible amount of detail in this report, it is recommended Start the trace with report generation enabledSomething as simple as adding report=yes in command netsh trace startThis way, when you close the session you will have not only the raw ETL trace, but also a consolidated analysis that is much more readable for an initial review.

Using filters to reduce the size and noise of traces

When you leave a capture running for a long time or when you enable multiple ETW providers at once, the result is usually a huge ETL fileThis not only complicates manual review but can also lead to lost events if ETW buffers become saturated. That's why it's so important to learn how to use the filters it offers. netsh trace.

On one hand, you have the ETW levels and keywords As we mentioned earlier, this applies both globally and by provider. By reducing the level (for example, from 5 Detailed to 3 Warning), or by filtering by only a few keywords, you drastically limit the number of events logged.

Filter help: netsh trace start /?

A typical example of an advanced filter would be something like:

netsh trace start scenario=InternetClient provider=Microsoft-Windows-TCPIP level=5 keywords=ut:ReceivePath,ut:SendPath

Here you are telling the system that outline the InternetClient scenariobut that, for the supplier Microsoft-Windows-TCPIP, use Level 5 (Detailed) and only record events associated with the keywords ut:ReceivePath y ut:SendPathThis excludes many events from that provider that are not related to receiving or sending, reducing noise without losing detail where it matters.

The levels available for this and other providers follow the same general logic (Critical, Errors, Warnings, Informative, Detailed), so you can combine them with specific keywords for even greater refinement. The complete list of keywords supported by a provider can be obtained with netsh trace show provider <nombre>.

In addition to ETW event-based filtering, netsh trace also supports packet filterssimilar to those of Network Monitor, provided that packet capture is enabled with capture=yesFor example, to limit capture to IPv4 traffic related to a specific IP address:

netsh trace start capture=yes ipv4.address=x.x.x.x

With this filter, only those registered will be registered. IPv4 packets whose source or destination matches the specified IPThis is great when you want to track traffic from a specific host without the rest of the network "cluttering" the ETL file.

If you need to delve deeper into the packet filtering language, you can jump straight to:

Filter help: netsh trace show capturefilterHelp

There you'll find a description of the valid filters and usage examples for different protocols and fields, from simple IP or port filters to more complex conditions. Mastering these filters allows you to run long sessions without fear of the file becoming unmanageable.

Advanced visualization and analysis of ETL traces

Once you have the ETL and CAB files generated, the next step is really analyze the informationThis is where tools like Network Monitor, Windows Performance Analyzer, or even Wireshark come into play, although in some environments you may not have permission to install them.

If you have access to Network Monitor (or the built-in traffic analyzer in some versions of Windows), you can Open the ETL file with the Windows parser to view packets and events in a more structured way, with decoded fields that make it easier to understand what is happening in each network flow.

In scenarios where you want to use Wireshark, one option is Convert the ETL to a compatible CAP format using Microsoft Message Analyzer (at the time available as Beta 3). After conversion, you can load the file into Wireshark and take advantage of all its filters and advanced protocol analysis features.

If, on the other hand, you are in very restricted environments where you cannot install anything, you still have the option of taking advantage of netsh trace convert Already PowerShell. For example, you can convert the trace to EVTX or CSV and then use Get-WinEvent or CSV import cmdlets to work with data from scripts, filtering events by fields, times, etc.

It's important to keep in mind that if you see messages like this in your analysis "Packet fragment (54 bytes)" Without fields like source or destination IP, the problem might be that the trace wasn't captured with capture=yes or that the supplier used (such as Microsoft-Windows-NDIS-PacketCapture) requires specific tools to fully decode the content. In many cases, combining capture=yes Using well-defined packet filters and then converting to a suitable format (such as CAP or a well-structured TXT) solves that apparent lack of detail.

netsh trace It's a Swiss Army knife for diagnosing networks in Windows: it offers packet capture without additional software, predefined scenarios for different types of problems, persistence options and circular logging to avoid missing critical moments, powerful filters to keep file sizes under control, and conversion and correlation commands that facilitate subsequent analysis, whether with graphical tools, scripts, or a mix of both.