VMware ESXi and vSphere Cluster Management

Using the Threads Tab in Process Explorer

Learn how to inspect Process Explorer threads, interpret CPU and Cycles Delta, analyze stacks and modules, and use thread controls safely.

The Threads tab in Process Explorer helps you investigate what individual threads are doing inside a selected process. You can use it to find threads consuming CPU, waiting on synchronization or I/O, suspended, or otherwise associated with an application problem.

This guide assumes basic familiarity with Windows processes, CPU utilization, Process Explorer process properties, and administrative permissions.

What the Threads Tab Shows

The Threads tab is part of a selected process's Properties dialog. It displays one row for every thread currently belonging to that process.

A process is a running instance of a program. It has its own virtual address space and operating-system resources. A thread is a schedulable execution path within that process. Windows schedules threads on processors, and a process normally begins with one initial thread before creating additional threads as needed.

Thread-level activity contributes to the process's overall behavior and CPU usage. Looking at individual threads can therefore narrow a process-wide symptom to a particular execution path.

Opening and Navigating to the Threads Tab

Select the process you want to investigate in Process Explorer.
Open the process's Properties dialog.
Choose the Threads tab.
Select a thread row before using a thread-specific control such as Stack, Module, Suspend, or Kill.

The available information and controls can depend on the target process, your permissions, and whether the process is protected or otherwise restricted.

Threads Tab Column Reference

Field	What It Identifies or Measures	How to Interpret It	Caveats
TID	The Windows-assigned thread identifier.	Use it to record and distinguish a specific thread while it exists.	The identifier is unique while that thread exists, but should not be treated as a permanent identity after the thread ends.
CPU	The thread's share of total processor activity during the latest refresh period.	Useful for spotting a currently busy thread.	It is interval-based and can change substantially at the next refresh. It is not cumulative CPU usage.
Cycles Delta	Processor cycles used since the preceding display update.	Compare threads during the same update interval to identify which one performed more work.	A high value is evidence of activity, not proof of a persistent problem. Check multiple intervals.
Start Address	The virtual-memory address designated as the thread's entry point when it was created.	A symbol or module-associated name can make the originating code easier to recognize.	The thread may now be executing elsewhere. The current call stack is needed to understand its present execution context.

Interpreting CPU and Cycles Delta

CPU is a sample covering the time since the previous refresh. For example, a thread that was busy during one interval may show a high value and then show little activity after it blocks or finishes its work. A momentary value therefore differs from cumulative process or thread CPU usage.

Cycles Delta reports processor cycles consumed since the preceding update. Comparing this value across threads during the same interval can help identify which thread performed the most processor work. Observe several refreshes before drawing a conclusion:

A repeatedly high CPU and Cycles Delta value suggests sustained computation.
A value that spikes only once may represent a short-lived operation, a refresh artifact, or a burst of work that has already ended.
A process can appear unresponsive even when no thread has high CPU, because the important thread may be blocked or waiting.

Understanding Start Addresses

A thread's start address identifies the code location supplied when the thread was created. When symbol or module resolution is available, Process Explorer can display a function-like name or an association with an executable image or DLL instead of only a numeric address.

An unresolved start address may appear as a raw address or another less descriptive value. This can occur when symbols are unavailable, the image cannot be resolved, or access to process information is limited.

The start address is not necessarily the code executing at the instant you inspect the thread. A thread can begin in a runtime or system routine and later call application code, or it can move through many functions. Use the current stack to identify its present execution path.

Inspecting the Associated Module

Select a thread and use the Module control to open Windows file properties for the image containing the selected thread's start address.

Inspect details such as:

File location and file name.
Publisher and digital-signature information.
File and product version.
Product name and other descriptive metadata.

Module information helps identify ownership and installation context. It does not, by itself, prove that a module is malicious, defective, or responsible for the symptom. Compare the module details with the stack, application behavior, expected installation, and other evidence.

Viewing a Thread's Current Stack

Select a thread and open its current Stack. A call stack is the active chain of function calls leading to the thread's present execution point. Each frame represents a function or transition that is still part of the current call path.

Stack frames can help distinguish among:

Application code responsible for computation or a loop.
Windows system routines handling operating-system work.
Runtime libraries used by languages and frameworks.
Third-party modules involved in encryption, graphics, drivers, plugins, or other services.

Symbols are debugging metadata that maps code addresses to meaningful function and module names. Resolved symbols make a stack much easier to interpret. Without them, the stack may contain module names, offsets, or raw addresses. Symbol configuration is optional and tool-specific; the Threads tab remains useful without completely resolved symbols.

Common Stack Patterns

Observed Pattern	Possible Meaning	Next Investigation Step
Repeatedly high CPU with application frames	A busy loop, expensive calculation, or repeated application operation.	Capture several samples, identify the recurring functions, and review the relevant application code or workload.
Wait or synchronization-related frames	The thread may be waiting for a lock, event, condition, or another thread.	Compare other thread stacks and investigate lock ownership, contention, or a possible deadlock.
I/O-related frames	The thread may be waiting for disk, network, device, or other input/output work.	Correlate the stack with storage, network, device, and application activity.
Third-party module frames	A library, plugin, security component, driver-related component, or other dependency may be involved.	Inspect the module's path, publisher, version, signature, and relationship to the affected application.
Unresolved symbols or raw addresses	Symbols or module information are unavailable, or access is limited.	Review module names and addresses, verify permissions, and configure symbols where permitted.

Thread Management Actions

Action	Effect	Potential Use	Primary Risks	Recommended Precautions
View Stack	Shows the selected thread's current call stack.	Non-disruptive investigation of computation, waits, I/O, and module involvement.	Stacks can be incomplete or difficult to interpret without symbols or sufficient access.	Record the TID, timestamp, CPU values, and stack before changing the process.
Open Module Properties	Opens Windows file properties for the image containing the start address.	Identifies path, publisher, signature, version, and product metadata.	Module ownership alone does not establish causation or maliciousness.	Evaluate the file information together with stack and application evidence.
Suspend Thread	Pauses the selected thread until it is resumed or the process exits.	A controlled experiment in a test or maintenance environment.	The thread may hold locks, own resources, or be performing critical work, destabilizing the process.	Assess impact, document the state, and prefer a reversible test with a recovery plan.
Kill Thread	Terminates only the selected thread; it does not directly terminate the entire process.	Rare, controlled troubleshooting when the consequences are understood.	Locks may remain held, cleanup may not run, data may be corrupted, and the process may become unstable.	Do not use as routine remediation. When recovery is required, ending the entire process is often safer than killing an arbitrary thread, although unsaved work can still be lost.

Safe Diagnostic Workflow

Identify the symptom. Choose the process whose CPU use, responsiveness, or behavior needs investigation.
Observe several intervals. Watch CPU and Cycles Delta across multiple refreshes rather than relying on one display update.
Select a candidate thread. Choose a thread that repeatedly shows activity or matches the known symptom.
Inspect its start address. Determine whether the entry point resolves to an expected executable or library.
Inspect the module. Review the image path, publisher, version, signature, and product information.
Review the current stack. Determine whether the thread is computing, waiting, contending for synchronization, performing I/O, or passing through a third-party component.
Record findings. Save the process identity, TID, observed metrics, start address, module details, stack observations, and timestamps before taking action.
Choose the least disruptive next step. Use suspension or termination only after considering impact and, ideally, after reproducing the issue in a test or maintenance environment.

Practical Investigation Examples

Finding the Thread Behind Sustained CPU Usage

Open the target process's Threads tab.
Watch CPU and Cycles Delta across several updates.
Identify the thread that repeatedly remains active.
Inspect its start address and associated module.
Open its stack and determine whether the activity is in application code, a dependency, or system code.

Per-thread sampling narrows a high-CPU process investigation to a particular execution path, but the stack and repeated observations are needed before assigning responsibility.

Investigating a Suspected Third-Party Component

Select a thread with a relevant start address or suspicious stack frame.
Open the associated module's file properties.
Review the file path, publisher, version, and signature information.
Compare those details with stack frames and the affected application's behavior.

Module properties and stack evidence should be evaluated together. An unfamiliar module requires context; it is not automatically evidence of a threat or defect.

Examining an Unresponsive Process

Review thread stacks before immediately terminating the process.
Look for waits on synchronization objects, I/O operations, or system routines.
Compare several threads to determine whether the application is busy, blocked, or idle.
Capture findings before restarting or terminating the application.

A stack can provide evidence about an apparent hang without making disruptive changes.

Testing the Effect of One Thread

In a non-production environment, record the selected thread's TID, metrics, module, and stack.
Suspend the thread only after assessing the risks.
Observe whether the application's symptom changes.
Resume the thread when appropriate, or restart the application to return to a known state.

Suspension is a controlled diagnostic experiment, not a general-purpose fix.

Troubleshooting Common Problems

High CPU Has No Obvious Cause

Compare CPU and Cycles Delta for every thread over several refreshes, then inspect the stack of the consistently active thread. Do not conclude that a thread is permanently responsible from one sample.

The Start Address Is Unfamiliar or Numeric

Use Module to identify the containing image and verify or configure symbols before relying on stack function names. An unfamiliar module is not automatically malicious or faulty.

The Application Is Frozen or Slow

Review several stacks for waits, lock contention, I/O activity, and active computation. Killing a thread can corrupt application state or leave the process unable to recover.

Controls Fail or Information Is Incomplete

Check whether Process Explorer has sufficient permissions and whether the target is protected or otherwise restricted. Use elevated access only according to organizational security policy.

Stack Frames Lack Function Names

Review available module names and addresses, and configure symbols where permitted. Incomplete symbols reduce precision but do not prevent comparison of thread behavior and module involvement.

Interpretation Limits

A start address identifies the thread's entry point, not necessarily its current code location.
CPU readings are refresh-period samples rather than permanent rankings.
Cycles Delta is most useful when comparing threads during the same interval.
Stack usefulness depends on symbol availability, process state, and permissions.
Protected, elevated, or inaccessible processes may expose limited information or prevent actions.
A single high-CPU sample should never be the sole basis for a conclusion.

Exam- and Operations-Relevant Notes

A process contains one or more threads; Windows schedules the threads, not the process as one indivisible execution path.
TID means thread identifier and is assigned by Windows.
CPU is interval-based, while Cycles Delta measures cycles since the preceding update.
The start address and current stack answer different questions: where the thread began versus what calls are active now.
Symbols translate addresses into useful function names.
Module properties help establish ownership and identity but do not prove cause.
Suspend and Kill can destabilize a process and should be treated as controlled troubleshooting actions.

For a focused reference, return to the Threads tab guide while comparing a process's thread metrics, module information, and stacks.