The Call That Changed How We Handle Network Troubleshooting
The call came in at 11pm. A manufacturing client had intermittent network drops hitting their production floor — three times in two weeks, no pattern, no clear cause. Their team had been staring at dashboards for days. What they needed was a packet capture running exactly when the fault occurred. What they had was a manual process: remote into the server, open Wireshark or netsh trace, watch it run, stop it, export the file, send it over. That works once. It doesn’t work when the problem happens again 10 minutes after you’ve stopped watching.
This is where Start-NetEventSession and Stop-NetEventSession earn their keep. These two cmdlets, part of the NetEventPacketCapture module in Windows Server, turn a reactive manual process into something you can schedule, script, and walk away from.
What These Cmdlets Actually Do
Before going further: if you haven’t set up a network event session before, read the primers on New-NetEventSession and Add-NetEventPacketCaptureProvider. Those cover the groundwork. This article is about controlling the capture lifecycle — starting and stopping it — in a way that runs without anyone watching.
Start-NetEventSession starts event and packet capture for a configured network event session. Stop-NetEventSession stops it. Network traffic is logged as Event Tracing for Windows (ETW) events and written to an .etl file. The session must have at least one provider attached before you start it — a session with no provider runs but captures nothing useful.
One hard constraint: only one session can exist on a host at a time. That’s not a performance tuning parameter; it’s a fixed rule. If a previous session wasn’t cleaned up, your next New-NetEventSession call fails. Cleanup is not optional.
Version 1: The Quick and Dirty Script
Here’s the manual flow — the starting point before we automate anything:
# V1 - Manual, single-run. You're still watching it.
New-NetEventSession -Name "QuickCapture" -LocalFilePath "C:\Captures\quick.etl"
Add-NetEventPacketCaptureProvider -SessionName "QuickCapture"
Start-NetEventSession -Name "QuickCapture"
# ... wait around ...
Stop-NetEventSession -Name "QuickCapture"
Remove-NetEventSession -Name "QuickCapture"Ugly but works. The problem is “wait around.” In an incident at 2am, that’s a person sitting at a console half-awake. There’s a better way.
Version 2: Timed Capture (Set It and Walk Away)
Add a duration variable and Start-Sleep and you have a capture that stops itself:
# V2 - Timed capture with timestamped output file
$SessionName = "TimedCapture"
$CapturePath = "C:\Captures\timed_$(Get-Date -Format 'yyyyMMdd_HHmm').etl"
$CaptureDuration = 300 # seconds
New-NetEventSession -Name $SessionName -LocalFilePath $CapturePath
Add-NetEventPacketCaptureProvider -SessionName $SessionName
Start-NetEventSession -Name $SessionName
Start-Sleep -Seconds $CaptureDuration
Stop-NetEventSession -Name $SessionName
Remove-NetEventSession -Name $SessionName
Write-Host "Capture complete. File: $CapturePath"The timestamp in the filename isn’t decoration. When you’re running captures every two hours overnight, you need to know which file is which without opening each one. Name them like you’ll be debugging them at 3am — because you will be.
This is the version we deployed for that manufacturing client. Scheduled via Task Scheduler, running every two hours overnight, capturing five-minute windows across a 48-hour troubleshooting window. The .etl file from 2:14am showed exactly what was happening — a misconfigured NIC driver causing retransmission storms that only appeared under specific load conditions. Found in a file that ran and stopped without anyone touching it.
Version 3: WFP Capture for Firewall and Layer-Level Inspection
When Standard Packet Capture Isn’t Deep Enough
The Remote Packet Capture provider handles most scenarios. But when you’re chasing IPsec negotiation failures, host firewall behavior, or connection drops that don’t appear in standard captures, the Windows Filtering Platform (WFP) capture provider goes further. It captures at specific network stack layers and filters by direction — inbound, outbound, or both. For incident response work involving traffic patterns tied to known CVE exploits, the layer-specific detail is exactly what security teams need to build a timeline.
# V3 - WFP capture with directional layer filtering
$SessionName = "WFPCapture"
New-NetEventSession -Name $SessionName -LocalFilePath "C:\Captures\wfp_capture.etl"
Add-NetEventWFPCaptureProvider -SessionName $SessionName
Set-NetEventWFPCaptureProvider -SessionName $SessionName `
-CaptureLayerSet IPv4Inbound, IPv4Outbound
Start-NetEventSession -Name $SessionName
# Run test traffic while capture is active
ping 127.0.0.1 -n 4
ping ::1 -n 4
Stop-NetEventSession -Name $SessionName
Remove-NetEventSession -Name $SessionNameThe WFP provider captures both IPv4 and IPv6 connections. The loopback pings confirm both are being caught before you use this in a real scenario. This workflow maps directly to the Windows Server 2025 documentation — configure the provider, start the session, run your test traffic, stop and clean up.
We ran a variation of this during a compliance audit for a financial services client. They needed to demonstrate that host-based firewall rules were correctly filtering specific traffic flows — a requirement tied to their ISO 27001 certification scope. The WFP captures gave us reproducible, timestamped ETW event data showing exactly which connections were allowed and which were dropped. No third-party tools, no agent installs, no change management overhead.
Making It Production-Ready: Error Handling and Cleanup
Scripts that fail silently in production are worse than scripts that fail loudly. A session left running fills disk. A session that wasn’t removed blocks the next run. Wrap everything in try/finally:
# V3 Production - cleanup guard, error handling, timestamped output
$SessionName = "AutoCapture"
$CapturePath = "C:\Captures\auto_$(Get-Date -Format 'yyyyMMdd_HHmmss').etl"
$CaptureDuration = 180
try {
# Remove any leftover session from a previous failed run
if (Get-NetEventSession -Name $SessionName -ErrorAction SilentlyContinue) {
Stop-NetEventSession -Name $SessionName -ErrorAction SilentlyContinue
Remove-NetEventSession -Name $SessionName
Write-Warning "Found and removed existing session before starting."
}
New-NetEventSession -Name $SessionName -LocalFilePath $CapturePath
Add-NetEventPacketCaptureProvider -SessionName $SessionName
Start-NetEventSession -Name $SessionName
Write-Host "Capture running for $CaptureDuration seconds..."
Start-Sleep -Seconds $CaptureDuration
} finally {
# Always runs - even if the try block throws
Stop-NetEventSession -Name $SessionName -ErrorAction SilentlyContinue
Remove-NetEventSession -Name $SessionName -ErrorAction SilentlyContinue
Write-Host "Session cleaned up. ETL file: $CapturePath"
}The try/finally block means Stop-NetEventSession and Remove-NetEventSession execute even when something throws mid-capture. The pre-run check handles the case where a previous run crashed without cleanup. Both scenarios will happen in production. Plan for them.
If you’re orchestrating captures across multiple hosts from a management machine, PowerShell ThrottleLimit controls how many concurrent operations run at once. For captures embedded in longer automation workflows, PowerShell -AsJob lets you run them in the background without blocking the console.
My Take: This Module Is Underused in Windows Shops
Here’s the opinion: most Windows environments reach for Wireshark or netsh trace by reflex, and those tools are fine for interactive troubleshooting. For scheduled, automated, or condition-triggered captures — the ones that run when nobody’s watching — the NetEventPacketCapture module is the better answer. It’s built into Windows Server, requires no third-party installs, and integrates cleanly with Task Scheduler, PowerShell workflows, and monitoring pipelines.
The ETW-based output isn’t frictionless. The .etl format requires specific tools to read — Microsoft Network Monitor, or Wireshark with an ETL plugin. Teams unfamiliar with ETW will hit that friction early. But for production environments where you need automated, tamper-evident capture logs, the format is actually an asset. ETW events carry precise timestamps, process IDs, and thread context that raw packet captures don’t include. In an incident response context, that extra detail matters.
Caveats Worth Knowing
One session at a time. This isn’t tunable. If you need concurrent captures on the same host, you’re looking at a different tool. Build your cleanup logic around this constraint from the start.
No built-in file size cap by default. Use -MaxFileSize in New-NetEventSession to limit how large the .etl file grows. On a busy host, an uncapped capture fills a drive fast. Make sure the capture output directory is covered by your retention policy — a reliable cloud backup service that includes the capture archive path will matter when you need to retrieve a file from three weeks ago during a post-incident review.
You can’t stop a session that isn’t running. Stop-NetEventSession throws an error if the session isn’t in a started state. Always pair it with -ErrorAction SilentlyContinue in cleanup blocks.
Provider must be added before starting. A session with no provider starts without error and logs nothing. Add the provider first, every time.
The Practical Takeaway
The pattern is four steps: create the session, add a provider, start it, stop and clean up. Everything else — error handling, scheduling, file naming — is wrapping that pattern so it works when you’re not watching.
The manufacturing client capture that identified the NIC retransmission storm at 2:14am? Ran untouched. The compliance captures for the financial services audit? Scripted, reproducible, and documented exactly the way auditors want to see them. That’s the use case this module was built for.
If you want help building automated capture workflows into your environment, or need someone to interpret what an .etl file is actually telling you, get in touch with the SSE team. We build and analyze these in production environments regularly.
