Logman Command: Ultimate Guide to Windows Performance Logging

The logman command is a built-in Windows utility that creates and manages Event Trace Sessions and Performance logs from the command line. It serves as the command-line equivalent to the Windows Performance Monitor (perfmon) graphical interface, allowing administrators to programmatically configure, start, stop, and query data collector sets that track system health.

Whether you are capturing high-resolution metrics during an application load test, diagnosing an intermittent memory leak on a production server, or establishing automated performance baselines, mastering logman gives you the scriptable power to diagnose Windows performance issues effectively. IT professionals and DevOps engineers rely on this command for generating detailed CSV or binary log files without relying on manual GUI setups.

This comprehensive guide covers logman syntax, the core operations (create, start, stop, query), practical examples for common scenarios, troubleshooting tips, and frequently asked questions. By the end, you'll confidently manage performance monitoring from the command line.

What Is the Logman Command?

The logman command acts as the central hub for managing Windows Performance Data Collector Sets from the command prompt or PowerShell. Instead of manually clicking through complex snap-ins to select specific performance counters (like % Processor Time, Pages/sec, or Disk Queue Length), logman allows these sets to be defined, scheduled, and triggered via a single text command.

It runs locally on the server you are measuring but can also manage remote servers (using the -s parameter). The outputs are typically saved as .blg (Binary Log), .csv (Comma Separated Values), or .etw (Event Trace) files, which can then be parsed and analyzed by tools like Windows Performance Analyzer or Excel.

To use logman effectively, you need administrative privileges as interacting with Event Tracing for Windows (ETW) and system-wide performance counters requires elevated rights.

Syntax

The basic syntax for the logman command involves the base command, a specific operation (verb), the name of the data collector set, and numerous optional parameters.

logman [create | query | start | stop | delete | update | import | export] [collection_name] [options]

Operations and Output Table

Command	Purpose
create	Creates a new data collector set (counter, trace, or alert).
query	Queries data collector set properties or status.
start	Starts the specified data collector set.
stop	Stops the running data collector set.
delete	Deletes the specified data collector set.
update	Updates an existing data collector set with new parameters.
import	Imports a data collector set from an XML file.
export	Exports a data collector set to an XML file.

Parameters and Options Explored

The create Command

The create command requires specifying the type of data collector: counter (for performance counters), trace (for ETW providers), or api (for API tracing).

The -b and -e Options

These parameters allow you to schedule when the collector should begin (-b in M/d/yyyy h:mm:ss[AM|PM] format) and when it should end (-e). This is ideal for capturing performance data during off-hours maintenance windows.

The -c Option

When creating a counter collector, the -c option specifies what counters to log. You can specify precise paths like "\Processor(_Total)\% Processor Time".

The -si Option

The -si option dictates the sample interval (how often data is collected) for performance counters. Setting -si 15 collects a data point every 15 seconds.

Examples

In this section, we will look at robust, copy-pasteable examples of using the logman command to automate your performance monitoring workflows. Ensure you run these from an elevated command prompt.

1. View All Existing Data Collector Sets

Before creating new sets, you should see what is already configured on the system.

logman query

Output:

Data Collector Set                      Type                          Status
-------------------------------------------------------------------------------
System Diagnostics                      Trace                         Finished
System Performance                      Trace                         Finished

The command completed successfully.

Explanation: This command lists the major data collector sets currently defined on the server along with their runtime status (e.g., Running, Stopped, or Finished).

2. Create a Basic CPU & Memory Counter Log

If a server experiences intermittent slowdowns, you might want to log overall CPU and memory usage every 10 seconds.

logman create counter "BasicPerfLog" -c "\Processor(_Total)\% Processor Time" "\Memory\Available MBytes" -si 10 -v mmddhhmm -f csv -o "C:\PerfLogs\BasicPerfLog"

Output:

The command completed successfully.

Explanation: This creates a collector set named BasicPerfLog. It collects CPU percentage and available memory every 10 seconds (-si 10). It formats the output as a CSV file (-f csv) and stores it in C:\PerfLogs with a timestamped filename (-v mmddhhmm).

3. Start a Data Collector Set

Creating a set does not automatically start recording data. You must manually invoke the start command.

logman start "BasicPerfLog"

Output:

The command completed successfully.

Explanation: The collector set begins polling the registered performance counters and immediately starts writing data to the CSV file defined during the creation phase.

4. Stop a Running Collector Set

Once you have enough data or the problematic event has passed, you must stop the logging process to finalize the log file and free system resources.

logman stop "BasicPerfLog"

Output:

The command completed successfully.

Explanation: This flushes the final buffers to the file and sets the status of BasicPerfLog to Stopped.

5. Query Specific Details of a Collector Set

To quickly view what counters a set is configured to capture without opening the graphical Performance Monitor, use the query command with the set name.

logman query "BasicPerfLog"

Explanation: This displays detailed properties of the BasicPerfLog set, including the root output path, the specific counter paths (like \Processor(_Total)\% Processor Time), and the sample interval.

6. Create an Event Trace Session

For deep diagnostic troubleshooting of Windows components (like networking or disk I/O), you capture data from ETW providers rather than performance counters.

logman create trace "NetTrace" -p "Microsoft-Windows-TCPIP" -o "C:\PerfLogs\NetTrace.etl"

Output:

The command completed successfully.

Explanation: This creates an Event Trace session that listens to the Microsoft-Windows-TCPIP provider. When started, it generates an .etl (Event Trace Log) file, which is an extremely detailed binary log used by advanced network analyzers and Microsoft Support.

7. Delete a Data Collector Set

To clean up your system after finishing an investigation, use the delete command to remove the set definitions (this does not delete the generated log files).

logman delete "BasicPerfLog"

Explanation: The definition of the data collector set is removed from the system. If the set is currently running, it will automatically be stopped before it is deleted.

8. Manage Performance Logs on a Remote Server

You can manage data collector sets on a different server on your domain using the -s parameter.

logman start "AppServerStressLog" -s \\APP-SRV-01

Explanation: This issues a command to start the AppServerStressLog data collector set that was previously defined on the machine named APP-SRV-01.

Common Use Cases

Here are the most common scenarios where IT professionals use the logman command.

1. Automated Server Baselining: Scripting the creation and daily start/stop of a logging set to gather historical CPU and RAM usage trends.
2. Intermittent Crash Diagnosis: Setting up a trace session that overwrites a circular buffer, and manually stopping it only when an application crashes, preserving the seconds leading up to the failure.
3. Application Load Testing: Automatically starting high-frequency counters right before invoking a load test script, and stopping them immediately upon completion.
4. Network Drop Investigations: Utilizing the create trace capability to monitor TCP/IP and NDIS providers deeply during network latency spikes without flooding a GUI viewer.
5. Disk I/O Bottleneck Hunting: Establishing a performance log targeting \PhysicalDisk(*)\* to identify precisely which logical drive is slowing down a database server.
6. Remote Administration: Starting identical logging sets simultaneously across an entire cluster of web servers to correlate distributed performance.
7. Scheduled Troubleshooting: Using the -b and -e parameters to automatically capture logs during a known busy window (e.g., end-of-month reporting runs at 2 AM) without an admin staying awake.
8. Export/Import Configurations: Reusing the exact same performance tuning setups by exporting a collector set to XML and importing it onto dozens of new virtual machines.

Tips and Best Practices

To get the most out of logman while maintaining server stability, follow these proven best practices:

• Watch Disk Space: High-frequency performance logging (sampling every 1 second) and Event Tracing can generate massive files (gigabytes per hour). Always monitor your C:\PerfLogs drive capacity or use a secondary drive for the -o parameter.
• Use Circular Logging for Traces: For long-term troubleshooting of intermittent issues, use the -max parameter combined with -f bincirc to create a capped circular log that constantly overwrites the oldest data until you manually stop it.
• Test Counter Names Locally First: Performance counter paths can be extremely finicky. Always verify the correct naming convention by running typeperf -q before embedding them into a lengthy logman script.
• Automate the Stop Process: Always include a mechanism to reliably stop the logger, either via a scheduled task or the -e (end time) parameter. Forgotten performance logs will eventually consume an entire partition.
• Format as CSV for Easy Analysis: If you plan on producing reports for management or using custom Python data sci-scripts, specify -f csv. The default binary (.blg) format is tightly coupled to the perfmon tool.
• Group Logical Counters: Do not create separate collector sets for CPU, RAM, and Disk if they correlate to the same issue. Group them into one set so that the timestamps in the CSV align perfectly.
• Run as Administrator: In almost all scenarios, logman commands interact with low-level kernel tracing facilities and system-wide counters; they will immediately fail with "Access Denied" if not executed in an elevated session.

Troubleshooting Common Issues

Even experienced administrators face hurdles when orchestrating performance logs.

Counter Path Not Found Error

Problem: When issuing the logman create counter command, the system states a specific path was not found. Solution: A slight typo in a performance counter path (e.g., \Processor\% Processor Time instead of \Processor(_Total)\% Processor Time) will trigger a failure. Prevention tip: Use the typeperf -q command to output all valid counter paths on the target machine and copy-paste the exact string.

Access is Denied

Problem: The command immediately fails citing permission bounds restricting execution. Solution: This typically occurs if your command prompt is not elevated, or if you are using the -s proxy against a remote server where your current credentials lack local admin parity. Prevention tip: Always run Command Prompt as Administrator, or explicitly supply alternate administrative credentials if executing across untrusted domains.

Large Log File Growth

Problem: You started a trace and the .etl log file consumed 50 GB in an hour. Solution: Deep Event Trace Sessions (ETW) capture thousands of events per second. You must define a maximum file size using the -max parameter. Prevention tip: Define a file limit like -max 500 (for 500MB) or use the -si parameter heavily if strictly working with counter polling to keep intervals at 15 or 30 seconds.

The Collector Cannot Be Started

Problem: Issuing logman start throws an error indicating the set didn't launch. Solution: Ensure that the output directory specified (e.g., C:\PerfLogs) physically exists and the SYSTEM account has write permissions to it. Second, verify there isn't another collector running under the same output filename holding an exclusive lock.

Related Commands

Here are some commands closely related to logman that you should also add to your system administration toolbox:

typeperf – Display Performance Data in Terminal

While logman sets up background loggers that dump into files, typeperf outputs performance counter data directly into the active console window. It is perfect for rapid, real-time pulse checks without generating static files.

diskperf – Disk Performance Counters Manager

Used to enable or disable disk performance counters on a system globally. If a server is failing to produce logical disk metrics to an established logman set, you might need to run diskperf -y to turn the counters physically back on.

wevtutil – Windows Event Command Line Utility

While logman is designed for performance numerical metrics and deep ETW session .etl files, wevtutil handles the reading, exporting, and management of standard administrative Windows Event logs (Application, System, Security).

perfmon – Performance Monitor GUI

Not technically a command line utility, but executing perfmon launches the graphical interface which seamlessly reads the .blg files generated by logman commands.

Frequently Asked Questions

What does the logman command do?

The logman command creates, starts, stops, and manages performance data collector sets and ETW (Event Trace for Windows) sessions from the command line, enabling automated server health monitoring.

Where does logman save the log files?

By default, unless specified with the -o parameter, collector sets will normally dump data into the %systemdrive%\PerfLogs directory structure.

How do I view the generated log files?

If you created a binary log (.blg), use the Windows Performance Monitor (perfmon.exe) application to open the file graphically. If you specified -f csv, you can open the file in Microsoft Excel or parse it using standard scripting tools. For .etl files, use the Windows Performance Analyzer.

Can logman monitor remote computers?

Yes. Using the -s \\ComputerName parameter allows you to create, query, start, and stop collector sets on remote servers, provided you have adequate administrative privileges on the target node.

Does logman cause high CPU utilization?

It depends purely on the configuration. Creating a standard counter set reporting CPU and Memory every 15 seconds consumes virtually zero resources. Capturing a deep Kernel trace session for every disk I/O and network packet might consume 5-10% CPU and heavily impact disk write latency.

How do I list the exact names of performance counters?

To see exactly what strings logman requires for the -c parameter, run the typeperf -q command, which dumps all active performance counters natively available on the local operating system installation.

How do I prevent a log from running forever?

When initiating the create or update command, utilize the -e switch to specify an explicit end date/time. Once the system clock hits that benchmark, the logging process ceases and releases the file handle safely.

What is the difference between logman trace and logman counter?

A counter polls mathematical metrics (like CPU % or bytes sent) at a fixed sample interval (like every 10 seconds). A trace blindly streams low-level event firing data natively directly from the operating system kernel components, capturing irregular triggers on demand.

Can logman trigger alerts instead of logging data?

Yes. Using the logman create alert subsystem allows you to configure limits (e.g., if CPU stays above 90% for a duration) to trigger an executable script or event log entry rather than generating continuous files.

Quick Reference Card

Here is a quick reference table of vital logman commands that busy administrators frequently use.

Command	Purpose	Example
logman query	View all active data collectors	Check if any long-running logs are eating up resources
logman create counter "CpuLog"	Create a basic CPU logger	Establish a structural script framework to be reused
logman start "CpuLog"	Initiate the log gathering	Begin actively writing metrics to a file
logman stop "CpuLog"	Safely stop log gathering	Conclude a test session and finalize the log output file
logman delete "CpuLog"	Remove the configuration entirely	Clean your server base image after intensive troubleshooting

Summary

The logman command is the definitive tool for automating Windows server performance metrics and deep diagnostics gathering. It exposes the massive power of the Windows Event Trace and Performance Counter engines natively to scripts and standard remote command prompts without demanding cumbersome graphical navigation.

We covered the core syntax and the essential sub-commands such as query, create, start, and stop. Through practical examples, we looked at how to specify counter paths exactly, schedule logging instances, manage trace configurations, and handle remote servers—ensuring your server administration toolbox remains automated.

Whether you're baselining a new clustered server deployment, hunting down an intermittent midnight workload spike, or tracking down an unpredictable memory leak, a strong functional knowledge of logman is your prime diagnostic lifesaver. Properly gathered and analyzed numbers solve arguments that guesswork cannot.

Ready to test your logman skills? Try using the interactive simulator on our platform to build muscle memory without risking writing endless logs to a production web server. You can also explore our Commands Reference for deeper dives into related administrative utilities.