Profile Explorer is a Windows desktop tool for viewing CPU profiling traces captured with Event Tracing for Windows. It turns large captures into hot function lists, flame graphs, call trees, and code-level detail so developers can find performance bottlenecks faster.
Profile Explorer is a Windows desktop application that reads CPU profiling traces collected through Event Tracing for Windows and turns them into views you can actually navigate. After loading a capture, it builds profile samples and call stacks, then presents the slowest parts of the workload through a hot function list, flame graph, timeline, call tree, and caller/callee breakdown. From any function you can jump into disassembly, mapped source lines, or a control-flow graph. The purpose is straightforward: shorten the distance between a heavy trace file and the specific line of code responsible for the delay, without waiting on a slow or cluttered interface.
A useful way to think about the tool is as a companion to Windows Performance Analyzer rather than a replacement for it. It concentrates on applications and adds binary analysis that many trace viewers skip: assembly is parsed into an intermediate representation, addresses map back to source lines, and a function's control flow can be drawn as a graph. You can record a session inside the app or load traces you already have. Teams that routinely move files between storage clients such as Microsoft OneLake file explorer for Windows will recognize the same principle here: bring the heavy data in once, and make exploring it feel immediate.
The clearest benefit of Profile Explorer is speed. Large captures open quickly, most processing runs multi-threaded, and the interface stays responsive because analysis work does not block it. That changes how you investigate: instead of trimming a capture before you can look at it, you can open the whole thing and follow the evidence. The second benefit is depth. Hot function lists and flame graphs answer where time goes, while assembly, source file, and flow graph views answer why, all in the same window and without juggling separate disassemblers. Marking, searching, and filtering isolate one function or stack while comparisons stay visible, and several functions can be examined side by side. Debug symbol files resolve in parallel and source lines load on demand, so symbol handling rarely becomes its own bottleneck. For compiler, runtime, and application developers who need reproducible performance data, that mix of fast loading, binary-level insight, and an IDE-style layout is hard to match.
Key capabilities and highlights.
The summary report ranks the functions consuming the most CPU time so you can identify the worst offenders within seconds of opening a trace. Each entry links straight into flame graph, call tree, and code views, so you can confirm a suspicion immediately instead of hunting through raw events.
The flame graph shows how time is distributed across the call hierarchy, while the timeline exposes bursts and idle gaps across the recording. Used together they distinguish a cost that runs constantly from a short, expensive spike that only appears under load.
Expand or collapse stacks to see which parents lead into an expensive function and which children it spends time in. This is how you trace the real caller behind a hot leaf instead of patching a symptom that keeps returning after every release.
Disassembly is parsed into an internal representation, so instructions can be read interactively, addresses and branches followed, and a function's control-flow graph viewed as a diagram rather than a flat listing. This makes hand-tuned or heavily optimized code far easier to reason about.
Debug symbol files are resolved in parallel and source lines are read on demand for the function you are inspecting. Navigation therefore stays quick while individual instructions still connect back to the exact lines of code that produced them, shortening the path from a hot loop to a concrete fix.
Collect a profiling trace from inside the application and analyze it straight away, with no handoff between separate capture and viewing utilities. Skipping that extra step shortens the loop between reproducing a slowdown and understanding which code path is responsible for it.
Multi-threaded algorithms keep interaction smooth even with captures running beyond ten gigabytes, and background processing does not block the interface. Files you would otherwise have to split or trim can be opened whole, so no useful evidence is discarded before you begin investigating.
Filtering narrows a trace to a single module, thread, or call path, and marks tag the functions worth returning to later. Comparing several functions at once keeps related findings in one place instead of scattered notes across separate sessions.
Browse historical releases and previous builds.
Common questions about Profile Explorer.
It is a viewer for CPU profiling traces captured with Event Tracing for Windows. Instead of leaving you with a wall of raw events, it turns a capture into ranked functions, graphs, and code-level detail so you can work out why an application is slow and where optimization will pay off.
Yes. You can load a profiling trace created previously, or start and stop a recording session inside the application, then open and analyze that capture in the same interface.
The two are complementary. Windows Performance Analyzer is a general-purpose front end for system-wide traces, while this tool concentrates on application CPU work and adds binary analysis, such as parsing assembly, mapping addresses to source, and drawing control-flow graphs, behind an IDE-like interface.
No. You can identify hot functions and read their assembly without any source. When symbol and source information is available it is resolved, and additional views then connect individual instructions back to specific lines, which makes fixes easier to plan.
Yes. Opening binaries independently of a trace is supported, which is useful when you want to examine a compiled module's code or explore a library before deciding what to profile.
Large captures are processed with multi-threaded algorithms and the interface updates asynchronously, so traces of many gigabytes remain navigable. Loading and initial processing are the demanding steps; interaction afterwards feels close to instant.
Yes. Several views can stay open, and more than one function can be inspected side by side. Search, filtering, and marking help you keep the functions you care about visible while moving between call tree, flame graph, and code views.
Yes. Most views have a help button in the upper corner that opens the matching documentation page in a built-in help panel, so you can read how a view works without leaving the trace you are analyzing.
Profile Explorer is a Windows desktop tool for viewing CPU profiling traces captured with Event Tracing for Windows. It turns large captures into hot function lists, flame graphs, call trees, and code-level detail so developers can find performance bottlenecks faster.
Progress Telerik Fiddler Classic is the original web debugging proxy: it logs HTTP and HTTPS traffic between an app and a server, then lets you inspect each request, build new ones, and mock responses while you work out why something fails.
Fiddler Everywhere is a web debugging proxy that captures HTTP and HTTPS traffic between an application and the internet, letting developers inspect requests, edit responses, mock endpoints, and replay API calls from a single desktop workspace.
ProjectTelescope is a local-first observability tool for AI coding agents. It records tool calls, file changes, token usage and decisions in one dashboard and CLI, so developers can see what an agent actually did.
Process Explorer is a Windows Sysinternals utility for inspecting running processes, open handles, and loaded DLLs, helping administrators and developers investigate locked files, resource usage, and application problems.
Comments