- Sep 17, 2013
- 1,492
Sysinternals Process Explorer
Official Link :
https://technet.microsoft.com/en-in/sysinternals/bb896653.aspx
Online ebook : https://books.google.co.in/books?id=0KZCAwAAQBAJ&printsec=frontcover#v=onepage&q&f=false
FEATURES
Process Explorer also provides easy access to information in one place, such as:
Process explorer requires administrative rights to access and show some data. So run it with administrative rights.
Toolbar buttons
System information
INTERFACE
DLL View
As you would expect, DLL view displays all the DLLs loaded by the selected process. It also displays other memory-mapped files, including the data files and the image file (EXE) being run. For the System process, DLL view lists the image files mapped into kernel memory, including ntoskrnl.exe and all the loaded device drivers. DLL view is empty for the System Idle Process and Interrupts pseudo-processes.
Procexp requires administrative rights to list DLLs loaded in processes running as a different user, but not to list the images loaded in the System process.
Handle View
Procexp’s Handle view lists the object handles belonging to the process selected in the upper pane. Object handles are what programs use to manipulate system objects managed by kernel-mode code, such as files, registry keys, synchronization objects, memory sections, window stations, and desktops. Even though disparate types of resources are involved, all kernel object types use this consistent mechanism for managing access.
When a process tries to create or open an object, it also requests specific access rights for the operations it intends to perform, such as read or write. If the create or open action is successful, the process acquires a handle to the object that includes the access rights that were granted. That handle can then be used for subsequent operations on the object, but only for the access rights that were granted. Even if the user could have been granted Full Control access to the object, if only Read access were requested, the handle could only be used for Read operations.
Although programs treat handles as opaque, at the program’s level a handle is simply an integer. That integer serves as a byte offset into the process’ handle table, which is managed in kernel memory. Information in the handle table includes the object’s type, the access granted, and a pointer to the data structure representing the actual object.
Note that loading a DLL or mapping another file type into a process’ address space normally does not also add a handle to the process’ handle table. Such files can therefore be in use and not be able to be deleted, even though a handle search might come up empty. This is why Procexp’s Find feature searches both DLLs and handles.
Customizing Handle View
To change the column selection that appears in Handle view, press Ctrl+H to open Handle view, and then right-click on the column header in the lower pane and choose Select Columns.
These attributes remain constant for as long as the handle is open:
If Show Unnamed Handles And Mappings is selected in the View menu, Handle view also lists objects that do not have a name associated with them. (Note that some types of objects are always unnamed, and others are sometimes but not always unnamed.) Unnamed objects are typically created by the process for its own use. They can also be inherited and used by child processes, as long as the child process has a way to identify which inherited handle value it should use. Handles can also be duplicated from one process to another, provided that the process performing the handle duplication has the necessary access to the target process.
When Handle view is open, the Handle menu appears on the menu bar, offering the Properties and Close Handle options. Close Handle forces a handle to be closed. This is typically risky. Because the process that owns the handle is not aware that its handle has been closed, using this feature can lead to data corruption or crash the application; closing a handle in the System process or a critical user-mode process such as Csrss can lead to a system crash.
Double-clicking a handle or choosing Properties from the Handle menu displays the Properties dialog box for the selected handle. The References group box indicates how many open handles and references still exist for the object. Because each handle includes a reference to the object, the reference count is never smaller than the handle count. The difference between the two figures is the number of direct references to the object structure from within kernel mode rather than indirectly through a handle. An object can be closed only when its reference count drops to zero—that is, when it has been closed as many times as it has been opened. The quota charges show how much paged and nonpaged pool is charged to the process’ quota when it creates the object.
Process Details
With its customizable column sets, the Procexp main window process list can show a tremendous amount of information about all processes on the system. To view even more detailed information about a specific process, double-click it in the Procexp main window to display its Properties dialog box. Procexp categorizes the data into a number of tabs: Image, Performance, Performance Graph, Threads, TCP/IP, Security, Environment, and Strings. It adds a Disk And Network tab if running with administrative rights. Extra tabs are added for processes that are services, are associated with a job, or use the .NET Framework.
COLUMNS
What various columns signifies.
Monitor resource usage by processes
Monitor which application is consuming the computer resources.
Disk Read Bytes
Disk Write Bytes
Shows which processes has written most data bytes on the hard disk
Network Receive Bytes
Show which processes has received the most that data bytes from network
Network Sent Bytes
Show which processes has sent the most that data bytes from network
Cycles
Shows which processes has consume the most CPU cycles.
Process, Threads, Jobs, handles, stack
Configuring Symbols
Using find handle & Dll
Detecting & Removing active malwares
Official Link :
https://technet.microsoft.com/en-in/sysinternals/bb896653.aspx
Online ebook : https://books.google.co.in/books?id=0KZCAwAAQBAJ&printsec=frontcover#v=onepage&q&f=false
FEATURES
- Tree view shows parent/child process relationships.
- Color coding identifies the process type, such as services, .NET processes, processes running as the same user as Procexp, processes that are part of a job, and packed images.
- Tooltips show command-line and other process information.
- Highlighting to call attention to new and recently exited processes.
- Fractional CPU so that processes consuming less than 1 percent of CPU time do not appear completely inactive.
- More accurate indication of CPU consumption based on CPU cycle counts or context switches.
- Task Manager replacement—you can have Process Explorer run whenever Task Manager is requested.
- Identify which process owns any visible window on your desktop.
- Identify a top-level window belonging to a given process, and bring it forward or close it.
- Identify all dynamic-link libraries (DLLs) and mapped files loaded by a process and all handles to kernel objects opened by a process.
- Find which processes have open handles to kernel objects such as files or folders.
- Find which processes have loaded a DLL, and identify its path and other attributes.
- Graphical representations of CPU activity, memory usage, and I/O activity, both systemwide and per-process.
- Detailed metrics of memory usage and I/O activity.
- Detailed information about a process security context.
- Detailed information about process TCP/IP endpoints.
- View process threads, including their start addresses and stacks.
- Create process dumps.
- Process security token (such as lists of groups and privileges and the virtualization state)
Highlighting to show changes in the process and thread list - List of services inside service-hosting processes, including the display name and description
Processes that are part of a job and job details - Processes hosting .NET applications and .NET-specific details (such as the list of AppDomains, loaded assemblies, and CLR performance counters)
- Start time for processes and threads
- Complete list of memory-mapped files (not just DLLs)
- Ability to suspend a process or a thread
- Ability to kill an individual thread
- Easy identification of which processes were consuming the most CPU time over a period of time (The Performance Monitor can display process CPU utilization for a given set of processes, but it won’t automatically show processes created after the performance monitoring session has started—only a manual trace in binary output format can do that .)
Process Explorer also provides easy access to information in one place, such as:
- Process tree (with the ability to collapse parts of the tree)
- Open handles in a process (including unnamed handles)
- List of DLLs (and memory-mapped files) in a process
- Thread activity within a process
- User-mode and kernel-mode thread stacks (including the mapping of addresses to names using the Dbghelp .dll that comes with the Debugging Tools for Windows)
- More accurate CPU percentage using the thread cycle count
- Integrity level
- Memory manager details such as peak commit charge and kernel memory paged and nonpaged pool limits (other tools show only current size)
Process explorer requires administrative rights to access and show some data. So run it with administrative rights.
Toolbar buttons
System information
The Summary tab of the dialog box features several pairs of graphs representing system wide metrics that are shown in more detail on the CPU, Memory, and I/O,GPU tabs
CPU Tab
In the CPU Usage graphs, the red area displays the percentage of time spent executing in kernel mode; the area under the green line represents total CPU utilization as a percentage. If the computer has multiple logical CPUs, selecting the Show One Graph Per CPU check box in the lower left of the CPU tab splits the CPU Usage History graph on that tab into separate per-CPU graphs. The CPU graphs are always scaled against a 100 percent peak.
The lower area of the CPU tab shows the systemwide total numbers of open object handles, threads, and processes, and the number of CPU context switches, interrupts, and DPCs since the previous data refresh.
The Memory tab
Shows the Commit and Physical Memory graphs. In the Commit graphs, the area under the yellow line indicates the commit charge—the total amount of private bytes committed across all processes, plus paged pool. The graph is scaled against the commit limit—the maximum amount of private bytes that can be committed without increasing pagefile size. The graph shows a series of snapshots captured at each update, and it does not show what happens between updates.
The lower part of the Memory tab shows a number of memory-related metrics:
The I/O tab
Shows I/O Bytes and, if Procexp is running with administrative rights, Network Bytes and Disk Bytes. I/O Bytes represents the amount of file and device I/O throughput, Network Bytes represents network I/O, and Disk Bytes represents I/O throughput to local disks. All three are scaled against their peak levels since Procexp started monitoring them. The pink areas represent write traffic, while the light blue indicates total I/O bytes since the previous update. In contrast to the commit charge graph, at each update the I/O graphs show the number of bytes since the previous update. If you pause updating for a while, the next update will include all the I/O traffic that occurred while Procexp was paused. This will likely appear as spikes and possibly change the measured peaks, and thus the graph scales.
The lower part of the I/O tab shows the number of I/O and Disk Read, Write, and Other operations and Network Receive, Send, and Other operations since the previous data refresh, and the number of bytes involved in those operations.
GPU Tab
CPU Tab
In the CPU Usage graphs, the red area displays the percentage of time spent executing in kernel mode; the area under the green line represents total CPU utilization as a percentage. If the computer has multiple logical CPUs, selecting the Show One Graph Per CPU check box in the lower left of the CPU tab splits the CPU Usage History graph on that tab into separate per-CPU graphs. The CPU graphs are always scaled against a 100 percent peak.
The lower area of the CPU tab shows the systemwide total numbers of open object handles, threads, and processes, and the number of CPU context switches, interrupts, and DPCs since the previous data refresh.
The Memory tab
Shows the Commit and Physical Memory graphs. In the Commit graphs, the area under the yellow line indicates the commit charge—the total amount of private bytes committed across all processes, plus paged pool. The graph is scaled against the commit limit—the maximum amount of private bytes that can be committed without increasing pagefile size. The graph shows a series of snapshots captured at each update, and it does not show what happens between updates.
The lower part of the Memory tab shows a number of memory-related metrics:
- Commit Charge (K) The current commit charge, the limit at which no more private bytes can be allocated without increasing pagefile size, and the peak commit charge incurred on the system since its last boot. This group also shows the percentage of peak commit vs. the limit and the current charge vs. the limit.
- Physical Memory (K) Total physical memory available to Windows in KB, available RAM that is not in use, and the sizes of the cache, kernel, and driver working sets.
- Kernel Memory (K) Paged WS is the amount of paged pool in KB that is present in RAM. Paged Virtual is the total amount of allocated paged pool, including bytes that have been swapped out to the pagefile. Paged Limit is the maximum amount of paged pool that the system will allow to be allocated. Nonpaged is the amount of allocated nonpaged pool, in KB; Nonpaged Limit is the maximum amount of nonpaged pool that can be allocated. Procexp requires administrative rights and symbols to be correctly configured in order to display Paged Limit and Nonpaged Limit.
- Paging The number of page faults since the previous data refresh, the number of paging I/O reads to a mapped file or the paging file, the number of writes to the paging file, and the number of writes to mapped files.
- Paging Lists (K) This column of items appears only on Windows Vista and newer. It shows the amount of memory in KB in the various page lists maintained by the memory manager.
The I/O tab
Shows I/O Bytes and, if Procexp is running with administrative rights, Network Bytes and Disk Bytes. I/O Bytes represents the amount of file and device I/O throughput, Network Bytes represents network I/O, and Disk Bytes represents I/O throughput to local disks. All three are scaled against their peak levels since Procexp started monitoring them. The pink areas represent write traffic, while the light blue indicates total I/O bytes since the previous update. In contrast to the commit charge graph, at each update the I/O graphs show the number of bytes since the previous update. If you pause updating for a while, the next update will include all the I/O traffic that occurred while Procexp was paused. This will likely appear as spikes and possibly change the measured peaks, and thus the graph scales.
The lower part of the I/O tab shows the number of I/O and Disk Read, Write, and Other operations and Network Receive, Send, and Other operations since the previous data refresh, and the number of bytes involved in those operations.
GPU Tab
INTERFACE
Procexp can split the main window into an upper pane and lower pane, with the process list in the upper pane and either DLL view or Handle view in the lower pane. DLL view lets you drill down into the DLLs and mapped files loaded by the process selected in the upper pane. Handle view lets you inspect all the kernel objects currently opened by the selected process, including (but not limited to) files, folders, registry keys, window stations, desktops, network endpoints, and synchronization objects.
The process list is a table in which each row represents a process on the system, and the columns represent continually updated attributes of those processes. You can change which attributes are displayed, resize and reorder the columns, and save column sets for later use. The Procexp toolbar includes buttons for performing common actions and graphs representing systemwide metrics. Finally, the status bar shows user-selectable system metrics.
There are some patterns you can always expect to see in Procexp on a normal Windows system. Some processes and parent/child relationships will always appear, as well as some pseudo-processes that Procexp uses to distinguish categories of kernel-mode activity.
System processes The first three rows in the Process Tree view are System Idle Process, System, and Interrupts. System Idle Process and Interrupts are not real operating system processes, and the System process does not run user-mode code.
The System Idle Process (called just “Idle” by some utilities) has one “thread” per CPU and is used to account for CPU idle time when Windows is not running any program code. Because it isn’t a real process, it doesn’t have a PID—there is no PID 0 in Windows. However, because Task Manager shows an artificial System Idle Process and displays 0 in its PID column, Procexp follows suit and assigns it PID 0.
The System process hosts only kernel-mode system threads, which only ever run (as you might expect) in kernel mode. These threads typically execute operating system code from Ntoskrnl.exe and device driver code.
Process Actions
You can perform a number of actions on a process by right-clicking on it, or by selecting it
and choosing any of the following options from the Process menu:
Window submenu : If the process owns a visible window on the desktop, the window submenu lets you bring it to the foreground, or restore, minimize, maximize, or close it. The window submenu is disabled if the process owns no visible windows.
Set Affinity : On multi-CPU systems, you can set processor affinity for a process so that its threads will run only on the CPU or CPUs you specify. This can be useful if you have a runaway CPU-hogging process that must be allowed to keep running but throttled back so that you can troubleshoot it. You can use Set Affinity to restrict the process to a single core temporarily and free up other CPUs so that the system is still usable. (If a particular process should always be restricted to a single CPU and you can’t modify its source code, use the SingleProcAffinity application compatibility shim, or as a last resort, modify the file’s PE header to specify affinity.)
Set Priority : View or set the base scheduling priority for the process.
Kill Process : You can forcibly terminate a process by choosing Kill Process or by clicking the Kill Process button in the toolbar. By default, Procexp prompts you for confirmation before terminating the process. You can disable that prompt by clearing Confirm Kill in the Options menu.
Kill Process Tree : When Procexp is in the process-tree sorting mode, this menu item is available and allows you to forcibly terminate a process and all its descendants. If the Confirm Kill option is enabled, you will be prompted for confirmation first.
Restart : When you select this item, Procexp terminates the highlighted process (after optional confirmation) and starts the same image using the same command-line arguments. Note that the new instance might fail to work correctly if the original process depended on other operating characteristics, such as the security context, environment variables, or inherited object handles.
Suspend : If you want a process to become temporarily inactive so that a system resource—such as a network, CPU, or disk—becomes available for other processes, you can suspend the process’ threads. To resume a suspended process, choose the Resume item from the process context menu.
Create Dump submenu : The options on this submenu let you capture a minidump or a full memory dump of the selected process to a file location of your choosing. Capturing a dump does not terminate the process.
Properties : This menu item displays the Properties dialog box for the selected process, which displays a wealth of information about the process.
Search Online : Procexp will launch a search for the selected executable name using your default browser and search engine. This option can be useful when researching malware or identifying the source of an unrecognized process.
Refresh Speed
Update speed settings decide the time interval after which process explorer refreshes the data.
The process list is a table in which each row represents a process on the system, and the columns represent continually updated attributes of those processes. You can change which attributes are displayed, resize and reorder the columns, and save column sets for later use. The Procexp toolbar includes buttons for performing common actions and graphs representing systemwide metrics. Finally, the status bar shows user-selectable system metrics.
There are some patterns you can always expect to see in Procexp on a normal Windows system. Some processes and parent/child relationships will always appear, as well as some pseudo-processes that Procexp uses to distinguish categories of kernel-mode activity.
System processes The first three rows in the Process Tree view are System Idle Process, System, and Interrupts. System Idle Process and Interrupts are not real operating system processes, and the System process does not run user-mode code.
The System Idle Process (called just “Idle” by some utilities) has one “thread” per CPU and is used to account for CPU idle time when Windows is not running any program code. Because it isn’t a real process, it doesn’t have a PID—there is no PID 0 in Windows. However, because Task Manager shows an artificial System Idle Process and displays 0 in its PID column, Procexp follows suit and assigns it PID 0.
The System process hosts only kernel-mode system threads, which only ever run (as you might expect) in kernel mode. These threads typically execute operating system code from Ntoskrnl.exe and device driver code.
- Tick “Verify Image Signatures”
- Tick “Check Virustotal.com”
Process Actions
You can perform a number of actions on a process by right-clicking on it, or by selecting it
and choosing any of the following options from the Process menu:
Window submenu : If the process owns a visible window on the desktop, the window submenu lets you bring it to the foreground, or restore, minimize, maximize, or close it. The window submenu is disabled if the process owns no visible windows.
Set Affinity : On multi-CPU systems, you can set processor affinity for a process so that its threads will run only on the CPU or CPUs you specify. This can be useful if you have a runaway CPU-hogging process that must be allowed to keep running but throttled back so that you can troubleshoot it. You can use Set Affinity to restrict the process to a single core temporarily and free up other CPUs so that the system is still usable. (If a particular process should always be restricted to a single CPU and you can’t modify its source code, use the SingleProcAffinity application compatibility shim, or as a last resort, modify the file’s PE header to specify affinity.)
Set Priority : View or set the base scheduling priority for the process.
Kill Process : You can forcibly terminate a process by choosing Kill Process or by clicking the Kill Process button in the toolbar. By default, Procexp prompts you for confirmation before terminating the process. You can disable that prompt by clearing Confirm Kill in the Options menu.
Kill Process Tree : When Procexp is in the process-tree sorting mode, this menu item is available and allows you to forcibly terminate a process and all its descendants. If the Confirm Kill option is enabled, you will be prompted for confirmation first.
Restart : When you select this item, Procexp terminates the highlighted process (after optional confirmation) and starts the same image using the same command-line arguments. Note that the new instance might fail to work correctly if the original process depended on other operating characteristics, such as the security context, environment variables, or inherited object handles.
Suspend : If you want a process to become temporarily inactive so that a system resource—such as a network, CPU, or disk—becomes available for other processes, you can suspend the process’ threads. To resume a suspended process, choose the Resume item from the process context menu.
Create Dump submenu : The options on this submenu let you capture a minidump or a full memory dump of the selected process to a file location of your choosing. Capturing a dump does not terminate the process.
Properties : This menu item displays the Properties dialog box for the selected process, which displays a wealth of information about the process.
Search Online : Procexp will launch a search for the selected executable name using your default browser and search engine. This option can be useful when researching malware or identifying the source of an unrecognized process.
Refresh Speed
Update speed settings decide the time interval after which process explorer refreshes the data.
- By default update speed is set to 1 second. This affects the data which keeps refreshing. You must have notices that after every 1 second some of the data changes. It keeps refreshing at set interval of time.
- Some of the data are Cumulative. It will keep adding the data obtained in each given time interval.
- While other are delta. It will show the data accumulated in the given time interval.
DLL View
As you would expect, DLL view displays all the DLLs loaded by the selected process. It also displays other memory-mapped files, including the data files and the image file (EXE) being run. For the System process, DLL view lists the image files mapped into kernel memory, including ntoskrnl.exe and all the loaded device drivers. DLL view is empty for the System Idle Process and Interrupts pseudo-processes.
Procexp requires administrative rights to list DLLs loaded in processes running as a different user, but not to list the images loaded in the System process.
Customizing DLL View
With DLL view open, right-click on the column header in the lower pane and choose Select Columns to display the DLL tab of the Select Columns dialog box. The DLL tab lists attributes of DLLs and mapped files that can be selected to appear when Procexp’s DLL view is open.
The following describes the columns that can be displayed in DLL view:
When DLL view is open, the DLL menu offers the following options for named files:
The Image tab displays information about the mapped file such as Description, Company, Version, Path, base address and size in the process’ memory, and (on x64) whether it is 32-bit or 64-bit. Several of these fields can be selected and copied to the clipboard.
The Company field is also used to indicate whether the executable file has been verified as digitally signed by a trusted publisher. (See the “Verifying Image Signatures” section later in this chapter for more information.) If the mapped file is an executable file type with a Company Name version resource and signature verification has not already been attempted, click the Verify button to perform validation. This feature can be useful to verify that a file that claims to be from a particular source is actually from that publisher and has not been modified. If the signature on the image has been verified, the Company field displays (Verified) and the subject name on the signing certificate. If verification has not been attempted, the field displays (Not verified) with the company name from the image’s version resource. If the image is not signed or a signature check has failed, the column shows (Unable to verify) with the company name.
With DLL view open, right-click on the column header in the lower pane and choose Select Columns to display the DLL tab of the Select Columns dialog box. The DLL tab lists attributes of DLLs and mapped files that can be selected to appear when Procexp’s DLL view is open.
The following describes the columns that can be displayed in DLL view:
- Description Extracted from the file’s version resource, if present.
- Version The file version extracted from the file’s version resource, if present.
- Time Stamp The last modification time of the file, as reported by the file system.
- Name The file name of the DLL or mapped file, or <Pagefile Backed> for an unnamed file mapping. Hover the mouse pointer over the name to display its full path in a tooltip.
- Path The full path to the DLL or mapped file, or <Pagefile Backed> for an unnamed file mapping.
- Company Name Extracted from the file’s version resource, if present.
- Verified Signer Indicates whether the file has been verified as digitally signed by a certificate that chains to a root authority trusted by the computer. See the “Verifying Image Signatures” section later in this chapter for more information.
- Image Base Address For files loaded as executable images, the virtual memory address from the executable image header that indicates where the image should be loaded. If any of the necessary memory range is already in use, the image will need to be relocated to another address.
- Base Address The virtual memory address where the file is actually loaded.
- Mapped Size The number of contiguous bytes, starting from the base address, consumed by the file mapping.
- Mapping Type The Mapping Type column displays “Image” for executable image files or “Data” for data files, including DLLs loaded for resources only (such as icons or localized text) and unnamed file mappings.
- WS Total Bytes The total amount of working set (physical memory) currently consumed by the file mapping.
- WS Private Bytes The amount of physical memory consumed by the file mapping that belongs solely to this process and cannot be shared with other processes.
- WS Shareable Bytes The amount of physical memory consumed by the file mapping that can be shared with other processes.
- WS Shared Bytes The amount of physical memory consumed by the file mapping that is also mapped into the address space of one or more other processes.
- Image Type (64 vs 32-bit) (64-bit versions of Windows only) For executable image files, indicates whether the file’s header specifies 64-bit or 32-bit code.
- ASLR Enabled (Windows Vista and newer) For executable image files, displays ASLR if the file’s header indicates support for Address Space Layout Randomization. The column is blank if the image does not support ASLR and n/a for data files.
When DLL view is open, the DLL menu offers the following options for named files:
- Properties : Displays a Properties dialog box for the selected file. See the “Peering Deeper into DLLs” section for more information.
- Search Online : Procexp will launch a search for the selected file name using your default browser and search engine. This option can be useful when researching malware or identifying the source of an unrecognized DLL.
- Check virustotal : Scans the file using online scanning service from virustotal. The result of scan will be shown under column "Virus Total"
The Image tab displays information about the mapped file such as Description, Company, Version, Path, base address and size in the process’ memory, and (on x64) whether it is 32-bit or 64-bit. Several of these fields can be selected and copied to the clipboard.
The Company field is also used to indicate whether the executable file has been verified as digitally signed by a trusted publisher. (See the “Verifying Image Signatures” section later in this chapter for more information.) If the mapped file is an executable file type with a Company Name version resource and signature verification has not already been attempted, click the Verify button to perform validation. This feature can be useful to verify that a file that claims to be from a particular source is actually from that publisher and has not been modified. If the signature on the image has been verified, the Company field displays (Verified) and the subject name on the signing certificate. If verification has not been attempted, the field displays (Not verified) with the company name from the image’s version resource. If the image is not signed or a signature check has failed, the column shows (Unable to verify) with the company name.
Handle View
Procexp’s Handle view lists the object handles belonging to the process selected in the upper pane. Object handles are what programs use to manipulate system objects managed by kernel-mode code, such as files, registry keys, synchronization objects, memory sections, window stations, and desktops. Even though disparate types of resources are involved, all kernel object types use this consistent mechanism for managing access.
When a process tries to create or open an object, it also requests specific access rights for the operations it intends to perform, such as read or write. If the create or open action is successful, the process acquires a handle to the object that includes the access rights that were granted. That handle can then be used for subsequent operations on the object, but only for the access rights that were granted. Even if the user could have been granted Full Control access to the object, if only Read access were requested, the handle could only be used for Read operations.
Although programs treat handles as opaque, at the program’s level a handle is simply an integer. That integer serves as a byte offset into the process’ handle table, which is managed in kernel memory. Information in the handle table includes the object’s type, the access granted, and a pointer to the data structure representing the actual object.
Note that loading a DLL or mapping another file type into a process’ address space normally does not also add a handle to the process’ handle table. Such files can therefore be in use and not be able to be deleted, even though a handle search might come up empty. This is why Procexp’s Find feature searches both DLLs and handles.
Customizing Handle View
To change the column selection that appears in Handle view, press Ctrl+H to open Handle view, and then right-click on the column header in the lower pane and choose Select Columns.
These attributes remain constant for as long as the handle is open:
- Type The type of securable object that the handle grants access to, such as Desktop, Directory, File, Key, and Thread.
- Name The name associated with the object. For most object types, the name is an object namespace name, such as \Device\Afd. For file system and registry objects, drive letters and friendly root keys replace internal names like \Device\HarddiskVolume1 C: and \REGISTRY\MACHINE\Software\Classes (HKCR). For process handles, the process name and PID is used; thread handles append the thread ID (TID) to that. Token handles use the principal and the logon session ID. Unnamed handles are not shown by default.
- Handle Value The handle value in hexadecimal that the process passes to APIs to access the underlying object. This value is the byte offset into the process’ handle table.
- Access Mask The bitmask in hexadecimal that identifies what permissions the process is granted through the handle. Each bit that is set grants a permission specific to the object type. For example, “read” permission for a registry key is 0x00020019; for a file, it is usually 0x00120089. Full control permission for a registry key is 0x000F003F, while for a file it is usually 0x001F01FF. (For more information, search MSDN for the “Access Rights and Access Masks” topic.)
- File Share Flags For file objects, the sharing mode that was set when the handle was opened. Flags can include R, W, or D, indicating that other callers (including other threads within the same process) can open the same file for reading, writing, or deleting, respectively. If no flags are set, the file system object is opened for exclusive use through this handle.
- Object Address The memory address in kernel memory of the data structure representing the object. This information can be used with a kernel debugger to display more information about the object.
If Show Unnamed Handles And Mappings is selected in the View menu, Handle view also lists objects that do not have a name associated with them. (Note that some types of objects are always unnamed, and others are sometimes but not always unnamed.) Unnamed objects are typically created by the process for its own use. They can also be inherited and used by child processes, as long as the child process has a way to identify which inherited handle value it should use. Handles can also be duplicated from one process to another, provided that the process performing the handle duplication has the necessary access to the target process.
When Handle view is open, the Handle menu appears on the menu bar, offering the Properties and Close Handle options. Close Handle forces a handle to be closed. This is typically risky. Because the process that owns the handle is not aware that its handle has been closed, using this feature can lead to data corruption or crash the application; closing a handle in the System process or a critical user-mode process such as Csrss can lead to a system crash.
Double-clicking a handle or choosing Properties from the Handle menu displays the Properties dialog box for the selected handle. The References group box indicates how many open handles and references still exist for the object. Because each handle includes a reference to the object, the reference count is never smaller than the handle count. The difference between the two figures is the number of direct references to the object structure from within kernel mode rather than indirectly through a handle. An object can be closed only when its reference count drops to zero—that is, when it has been closed as many times as it has been opened. The quota charges show how much paged and nonpaged pool is charged to the process’ quota when it creates the object.
Process Details
With its customizable column sets, the Procexp main window process list can show a tremendous amount of information about all processes on the system. To view even more detailed information about a specific process, double-click it in the Procexp main window to display its Properties dialog box. Procexp categorizes the data into a number of tabs: Image, Performance, Performance Graph, Threads, TCP/IP, Security, Environment, and Strings. It adds a Disk And Network tab if running with administrative rights. Extra tabs are added for processes that are services, are associated with a job, or use the .NET Framework.
Image Tab
The Image tab,displays information about the process that mostly remains static for the lifetime of the process, including information collected from the executable image file’s icon and version resources, the full path to the image file, the command line that was used to start the process, the user account under which the process is running, when it started, whether DEP is enabled, whether ASLR is enabled (Windows Vista and newer), and on x64 versions of Windows, whether the process is running 32-bit or 64-bit code. Two fields that can change if you open a new Properties dialog box for the process are the current directory and the parent process. If the parent process was still running when Procexp started, the field reports the image name and the PID; if it had exited, the field reports <Non-existent Process> and the PID.
The second field in the Image tab serves as a Verified Signer field, showing the company name from the version resource or the subject name from the verified signing certificate. If signature verification has not been attempted, you can click the Verify button to perform that verification. See the “Verifying Image Signature” section in this chapter for more information.
If the process owns a visible window on the current desktop, clicking the Bring To Front button brings it to the foreground. If the process owns more than one top-level window, Bring To Front brings the one closest to the top of the z-order to the foreground. Clicking the Kill Process button forcibly terminates the process. By default, Procexp will prompt you for confirmation before terminating the process. You can disable that prompt by clearing the Confirm Kill check box in the Options menu.
Threads Tab
The Threads tab of the process’ Properties dialog box shows detailed information, including current call stacks, for each of the threads in the selected process, and it lets you kill or suspend individual threads within the process.
TCP/IP Tab
Any active TCP, TCPV6, UDP, or UDPV6 endpoints owned by the process are shown in a list on the TCP/IP tab. The tab lists the protocol, state, and local and remote addresses and port numbers for each connection. For service processes on Windows Vista and newer, the tab adds a Service column showing the service that owns the endpoint.
Thread Details
As mentioned earlier, a process doesn’t actually run code itself, but is a container for a set of resources, including a virtual address space, one or more mapped file images containing code to execute, and one or more threads of execution. A thread is the entity that actually runs code: its resources include a call stack and an instruction pointer that identifies the next executable instruction.
The Threads tab of the process’ Properties dialog box displays detailed information about each thread in the current process, with the following information appearing in the list box in the top area of the dialog box:
By default, the list is sorted by CPU time in descending order. Click on any column header to change the sort order. Columns can be resized but cannot be reordered.
Selecting a row in the list box displays more detail about that thread in the lower area of the Threads tab: when the thread started; how much CPU time it has consumed in kernel mode and in user mode; how many context switches and CPU cycles it has consumed; its base priority and dynamic priority; and on Windows Vista and newer, its I/O priority, memory priority, and ideal processor. Clicking the Permissions button displays the security descriptor for the thread—that is, who can perform which actions on the thread. Although this interface allows you to modify permissions on the thread, actually making changes is not advised and will usually lead to unpredictable results.
For the System Idle Process, the list box enumerates processors rather than threads. The processor number is shown instead of the Thread ID, and the CPU time represents the percentage of time the CPU spent idle during the refresh interval. When you select one of the processors in the list, the Kernel Time shown below the list box reports the total amount of idle time for that CPU.
Clicking the Module button displays a standard file properties dialog box for the EXE or DLL name in the selected row.
Finally, the Kill and Suspend buttons allow you to terminate or suspend the selected thread. Unless you are intimately familiar with what the threads are running (for example, you wrote the program), it is almost always a bad idea to terminate or suspend a single thread within a process.
The Stack button displays the call stack for the selected thread. The start address is the bottom-most item in the stack, and the current location of the thread is at the top. The Copy button in the Stack dialog box copies the currently selected symbolic name in the stack to the clipboard. You can select multiple rows in the standard ways, such as holding Shift and pressing the down arrow key.
The Image tab,displays information about the process that mostly remains static for the lifetime of the process, including information collected from the executable image file’s icon and version resources, the full path to the image file, the command line that was used to start the process, the user account under which the process is running, when it started, whether DEP is enabled, whether ASLR is enabled (Windows Vista and newer), and on x64 versions of Windows, whether the process is running 32-bit or 64-bit code. Two fields that can change if you open a new Properties dialog box for the process are the current directory and the parent process. If the parent process was still running when Procexp started, the field reports the image name and the PID; if it had exited, the field reports <Non-existent Process> and the PID.
The second field in the Image tab serves as a Verified Signer field, showing the company name from the version resource or the subject name from the verified signing certificate. If signature verification has not been attempted, you can click the Verify button to perform that verification. See the “Verifying Image Signature” section in this chapter for more information.
If the process owns a visible window on the current desktop, clicking the Bring To Front button brings it to the foreground. If the process owns more than one top-level window, Bring To Front brings the one closest to the top of the z-order to the foreground. Clicking the Kill Process button forcibly terminates the process. By default, Procexp will prompt you for confirmation before terminating the process. You can disable that prompt by clearing the Confirm Kill check box in the Options menu.
Threads Tab
The Threads tab of the process’ Properties dialog box shows detailed information, including current call stacks, for each of the threads in the selected process, and it lets you kill or suspend individual threads within the process.
TCP/IP Tab
Any active TCP, TCPV6, UDP, or UDPV6 endpoints owned by the process are shown in a list on the TCP/IP tab. The tab lists the protocol, state, and local and remote addresses and port numbers for each connection. For service processes on Windows Vista and newer, the tab adds a Service column showing the service that owns the endpoint.
Thread Details
As mentioned earlier, a process doesn’t actually run code itself, but is a container for a set of resources, including a virtual address space, one or more mapped file images containing code to execute, and one or more threads of execution. A thread is the entity that actually runs code: its resources include a call stack and an instruction pointer that identifies the next executable instruction.
The Threads tab of the process’ Properties dialog box displays detailed information about each thread in the current process, with the following information appearing in the list box in the top area of the dialog box:
- TID The system-assigned, unique thread identifier. While a thread identifier can be reused at some point after the thread has exited, a TID is only ever associated with one thread on the system at a time.
- CPU The percentage of total CPU time that the thread was executing during the previous refresh cycle. Note that because a thread can consume at most 100 percent of a single logical CPU, this number cannot exceed 50 percent on a two-CPU system, 25 percent on a four-CPU system, and so on.
- Cycles Delta or CSwitch Delta If on Windows Vista or newer and Procexp is running in a context that gives it full control over the process, this column displays CPU Cycles Delta; otherwise, it displays the Context Switch Delta, even for protected processes. Cycles Delta is the number of processor cycles consumed by the thread since the previous update; Context Switch Delta is the number of times that the thread has been given control and has begun executing since the previous update.
- Service This column appears on Windows Vista and newer for processes hosting one or more services, showing which service is associated with each thread. Windows tags the threads of service processes to associate threads and TCP/IP endpoints with their owning service.
- Start Address The symbolic name associated with the program-specified location in the process’ virtual memory where the thread began executing. The name is reported in module!function format. If Procexp is configured to use a symbol server, displaying this tab might introduce a lag as required symbols are downloaded. An indicator appears above the list box when this is happening.
By default, the list is sorted by CPU time in descending order. Click on any column header to change the sort order. Columns can be resized but cannot be reordered.
Selecting a row in the list box displays more detail about that thread in the lower area of the Threads tab: when the thread started; how much CPU time it has consumed in kernel mode and in user mode; how many context switches and CPU cycles it has consumed; its base priority and dynamic priority; and on Windows Vista and newer, its I/O priority, memory priority, and ideal processor. Clicking the Permissions button displays the security descriptor for the thread—that is, who can perform which actions on the thread. Although this interface allows you to modify permissions on the thread, actually making changes is not advised and will usually lead to unpredictable results.
For the System Idle Process, the list box enumerates processors rather than threads. The processor number is shown instead of the Thread ID, and the CPU time represents the percentage of time the CPU spent idle during the refresh interval. When you select one of the processors in the list, the Kernel Time shown below the list box reports the total amount of idle time for that CPU.
Clicking the Module button displays a standard file properties dialog box for the EXE or DLL name in the selected row.
Finally, the Kill and Suspend buttons allow you to terminate or suspend the selected thread. Unless you are intimately familiar with what the threads are running (for example, you wrote the program), it is almost always a bad idea to terminate or suspend a single thread within a process.
The Stack button displays the call stack for the selected thread. The start address is the bottom-most item in the stack, and the current location of the thread is at the top. The Copy button in the Stack dialog box copies the currently selected symbolic name in the stack to the clipboard. You can select multiple rows in the standard ways, such as holding Shift and pressing the down arrow key.
COLUMNS
What various columns signifies.
You can do column settings from menu View->select columns
I suggest you enable columns : verified signer,VirusTotal, DEP Enabled, ASLR Enabled, Wroking set size, Receive Bytes, Send Bytes, Read Bytes, Write Bytes
Process Image Tab
The Process Image tab contains process attributes that, for the most part, are established at process start and do not change over the life of a process.
PID (Process Identifier) : A number that uniquely identifies a process while it runs.
User Name : The user account in which the process is running, in DOMAIN\USER format.
Description : Extracted from the version resource of the executable image. If this column is not enabled, the information appears in the process name tooltip.
Company Name : Extracted from the version resource of the executable image. If this column is not enabled, the information appears in the process name tooltip.
Verified Signer : Indicates whether the executable image has been verified as digitally signed by a certificate that chains to a root authority trusted by the computer. See the “Verifying Image Signatures” section later in this chapter for more information.
Version : The file version extracted from the version resource of the executable image. Image Path : The path to the executable image. Note that when this column is enabled, the process name tooltip no longer shows the full path.
Image Type (64 vs 32-bit) : On 64-bit versions of Windows, this field indicates whether the program is running native 64-bit code or 32-bit code running in WOW64 (Windows On Windows64). On 32-bit versions of Windows, this check box is disabled.
Window Title : If the process owns any visible windows, shows the text of the title bar of a top-level window, similar to the Applications tab of Task Manager. This attribute is dynamic and changes when the application’s window title changes.
Window Status : If the process owns any visible windows, indicates whether it responds in a timely fashion to window messages (Running or Not Responding). This is similar to the Status column on the Task Manager Applications tab. This attribute is also
dynamic.
Session : Identifies the terminal services session in which the process is running. Services and most system code runs in session 0. User sessions on Windows XP and Windows Server 2003 can be in any session; user sessions on Windows Vista and newer are always in session 1 or higher.
Command Line : The command line that was used to start the process.
Comment : A user-defined comment that can be entered in the Image tab of the process’ Properties dialog box. See the “Process Details” section for more information.
DEP Status : Indicates whether Data Execution Prevention (DEP) is enabled for the process. DEP is a security feature that mitigates buffer overflow and other attacks by disallowing code execution from memory that has been marked “no-execute,” such as the stack and heap. The column text can be blank (DEP not enabled), DEP (enabled),
DEP (permanent) (DEP enabled within the executable and cannot be disabled), or <n/a> if Procexp cannot determine the DEP status of the process.
Integrity Level : On Windows Vista and newer, indicates the integrity level (IL) of the process. Services run at System level, elevated processes at High, normal user processes at Medium, and low-rights processes such as Protected Mode Internet Explorer at Low.
Virtualized : On Windows Vista and newer, indicates whether UAC file and registry virtualization is enabled. File and registry virtualization is an application=compatibility technology that intercepts attempts by legacy Medium IL processes to write to protected areas and transparently redirects them to areas owned by the user.
ASLR Enabled : On Windows Vista and newer, indicates whether Address Space Layout Randomization (ASLR) is enabled for the process. ASLR is a defense-in-depth security feature that can mitigate remote attacks that assume that function entry points are at predictable memory addresses.
Process Performance Tab
The Process Performance tab contains attributes relating to CPU usage as well as the number of threads and open handles in the process. Some of the attributes report cumulative data, while others show the delta (the difference) since the previous update.
CPU Usage : The percentage of time that a process used the CPU since the last update (listed as CPU in the column heading).
CPU History : A graphical representation of the recent CPU usage charged to each process. Kernel-mode time is shown in red and user-mode time in green.
CPU Time : The total amount of kernel-mode and user-mode CPU time charged to the process (or pseudo-process), shown as hours:minutes:seconds.milliseconds.
Start Time : The time and date that the process was started.
Base Priority : The scheduling priority for the process. A value of 8 is normal priority; numbers above 8 indicate a higher priority, and those below 8 indicate a lower priority.
Threads : The number of threads in the process.
Handle Count : The number of handles to kernel objects currently opened by the process.
CPU Cycles : On Windows Vista and newer, the total number of kernel-mode and user-mode CPU cycles consumed by the process since it started. (On Windows Vista, this number is not tracked for the Interrupts pseudo-process.)
CPU Cycles Delta : On Windows Vista and newer, the number of CPU cycles consumed by the process since the previous update. (On Windows Vista, this number is not tracked for the Interrupts pseudo-process.)
Process Memory Tab
The Process Memory tab (shown in Figure 3-9) contains attributes relating to memory usage, including virtual memory management metrics around working set and page faults, as well as counts of the windowing system’s GDI and USER objects.
Page Faults : The total number of times that the process accessed an invalid memory page, causing the memory manager fault handler to be invoked. Some reasons for pages being invalid are these: the page is on disk in a page file or a mapped file, first access requires copying or zeroing, and there was illegal access resulting in an access violation. Note that this total includes soft page faults (that is, faults resolved by referencing information not in the working set but already in physical memory).
Page Fault Delta : The number of page faults that occurred since the previous display refresh. Note that the column header is labeled “PF Delta.”
Private Bytes : The number of bytes allocated and committed by the process for its own use and not shareable with other processes. Per-process private bytes include heap and stack memory. A continual rise in this value can indicate a memory leak.
Private Delta Bytes : The amount of change—positive or negative—in the number of private bytes since the previous refresh.
Peak Private Bytes : The largest number of private bytes the process had committed at any one time since the process started.
Private Bytes History : A graphical representation of the process’ private byte commit history. The wider you make this column, the longer the timeframe it shows. Note that the graph scale is the same for all processes and is based on the maximum number of private bytes currently committed by any process.
Virtual Size : The amount of the process’ virtual memory that has been reserved or committed.
Memory Priority : In Windows Vista and newer, the default memory priority that is assigned to physical memory pages used by the process. Pages that are cached in RAM and not part of any working set get repurposed starting with the lowest priority.
Minimum Working Set : The amount of physical memory reserved for the process; the operating system guarantees that the process’ working set can always be assigned at least this amount. The process can also lock pages in the working set up to that amount minus eight pages. This minimum does not guarantee that the process’ working set will always be at least that large, unless a hard limit has been set by a resource management application.
Maximum Working Set : Indicates the maximum amount of working set assigned to the process. However, this number is ignored by Windows unless a hard limit has been configured for the process by a resource management application.
Working Set Size : The amount of physical memory assigned to the process by the
memory manager.
Peak Working Set Size : The largest working set size the process has had since its start.
WS Shareable Bytes : The portion of the process’ working set that contains memory that can be shared with other processes, such as mapped executable images.
WS Shared Bytes : The portion of the process’ working set that contains memory that is currently shared with other processes.
WS Private Bytes : The portion of the process’ working set that contains private bytes
that cannot be shared with other processes.
GDI Objects : The number of Graphics Device Interface (GDI) objects—such as brushes,
fonts, and bitmaps—owned by the process.
USER Objects : The number of USER objects—such as windows and menus—owned by
the process.
.NET Tab
The .NET tab contains performance counters that measure behaviors of processes that use the .NET framework version 1.1 or higher.
These numbers are all dynamic. Administrative rights are required to observe them in a process running in a different security context:
Methods Jitted : Displays the total number of methods just-in-time (JIT) compiled since the application started.
% Time in JIT : Displays the percentage of elapsed time spent in JIT compilation since the last JIT compilation phase.
AppDomains : Displays the current number of application domains loaded in this application.
Total AppDomains : Displays the peak number of application domains loaded since the application started.
Classes Loaded : Displays the current number of classes loaded in all assemblies.
Total Classes : Loaded Displays the cumulative number of classes loaded in all assemblies since the application started.
Assemblies : Displays the current number of assemblies loaded across all application domains in the currently running application. If this keeps increasing, it could indicate an assembly leak.
Total Assemblies : Displays the total number of assemblies loaded since the application started.
Gen 0, 1, 2 Collections : Displays the number of times that generation 0, 1, or 2 objects have been garbage collected since the application began. Generation 0 objects are the newest, most recently allocated objects, while Gen 2 collections are also called full garbage collections. Higher generation garbage collections include all lower generation collections.
% Time in GC : Displays the percentage of elapsed time that was spent performing a garbage collection since the last garbage collection cycle.
Allocated Bytes/s : Displays the number of bytes per second allocated on the garbage collection heap.
Heap Bytes : Displays the number of bytes allocated in all heaps in the process.
Runtime Checks : Displays the total number of runtime code access security checks performed since the application started.
Contentions Displays : the total number of times that threads in the runtime have attempted to acquire a managed lock unsuccessfully.
Process I/O Tab
The Process I/O tab contains attributes relating to file and device I/O, including file I/O
I/O operations : There are four metrics each for I/O Read, Write, and Other operations: the total number of operations performed by the process since it started (Reads), the total number of bytes involved in those operations (Read Bytes), the number of operations performed since the last update (Delta Reads), and the number of bytes since the last update (Delta Read Bytes).
Delta Total Bytes : Represents the number of bytes involved in I/O operations since the previous update.
I/O History : A graphical representation of the process’ recent I/O throughput. The blue line represents the total throughput, while the pink line shows write traffic.
I/O Priority : On Windows Vista and newer, shows the I/O priority for the process. I/O prioritization allows the I/O subsystem to distinguish between foreground processes and lower-priority background processes. Most processes have a priority of Normal, while others can be Low or Very Low. Only the memory manager has Critical I/O priority. A fifth level, High, is not used in current versions of Windows.
Process Network Tab
The Process Network tab lets you configure Procexp to show the numbers of TCP connect, send, receive, and disconnect operations; the number of bytes in those operations; and the deltas since the previous refresh.
Receive Bytes : Number of data bytes received by the process from network adapter
Delta Receive Bytes : Represents the Number of bytes received by the process from network adapter since
the previous refresh .
Send Bytes : Number of data bytes sent by the process from network adapter
Delta Send Bytes : Represents the Number of bytes sent by the process from network adapter since
the previous refresh.
Process Disk Tab
Enabling column displays of the attributes on the Process Disk tab shows I/O to local disks (not including CD/DVD drives).
Read Bytes : The number of bytes read from the storage device (hard disk) by the process
Delta read bytes : The number of bytes read from the storage device (hard disk) by the process since
the previous refresh .
Write bytes : The number of bytes written on the storage device (hard disk) by the process
Delta write bytes : The number of bytes read from the storage device (hard disk) by the process since
the previous refresh .
GPU usage Tab
I suggest you enable columns : verified signer,VirusTotal, DEP Enabled, ASLR Enabled, Wroking set size, Receive Bytes, Send Bytes, Read Bytes, Write Bytes
Process Image Tab
The Process Image tab contains process attributes that, for the most part, are established at process start and do not change over the life of a process.
PID (Process Identifier) : A number that uniquely identifies a process while it runs.
User Name : The user account in which the process is running, in DOMAIN\USER format.
Description : Extracted from the version resource of the executable image. If this column is not enabled, the information appears in the process name tooltip.
Company Name : Extracted from the version resource of the executable image. If this column is not enabled, the information appears in the process name tooltip.
Verified Signer : Indicates whether the executable image has been verified as digitally signed by a certificate that chains to a root authority trusted by the computer. See the “Verifying Image Signatures” section later in this chapter for more information.
Version : The file version extracted from the version resource of the executable image. Image Path : The path to the executable image. Note that when this column is enabled, the process name tooltip no longer shows the full path.
Image Type (64 vs 32-bit) : On 64-bit versions of Windows, this field indicates whether the program is running native 64-bit code or 32-bit code running in WOW64 (Windows On Windows64). On 32-bit versions of Windows, this check box is disabled.
Window Title : If the process owns any visible windows, shows the text of the title bar of a top-level window, similar to the Applications tab of Task Manager. This attribute is dynamic and changes when the application’s window title changes.
Window Status : If the process owns any visible windows, indicates whether it responds in a timely fashion to window messages (Running or Not Responding). This is similar to the Status column on the Task Manager Applications tab. This attribute is also
dynamic.
Session : Identifies the terminal services session in which the process is running. Services and most system code runs in session 0. User sessions on Windows XP and Windows Server 2003 can be in any session; user sessions on Windows Vista and newer are always in session 1 or higher.
Command Line : The command line that was used to start the process.
Comment : A user-defined comment that can be entered in the Image tab of the process’ Properties dialog box. See the “Process Details” section for more information.
DEP Status : Indicates whether Data Execution Prevention (DEP) is enabled for the process. DEP is a security feature that mitigates buffer overflow and other attacks by disallowing code execution from memory that has been marked “no-execute,” such as the stack and heap. The column text can be blank (DEP not enabled), DEP (enabled),
DEP (permanent) (DEP enabled within the executable and cannot be disabled), or <n/a> if Procexp cannot determine the DEP status of the process.
Integrity Level : On Windows Vista and newer, indicates the integrity level (IL) of the process. Services run at System level, elevated processes at High, normal user processes at Medium, and low-rights processes such as Protected Mode Internet Explorer at Low.
Virtualized : On Windows Vista and newer, indicates whether UAC file and registry virtualization is enabled. File and registry virtualization is an application=compatibility technology that intercepts attempts by legacy Medium IL processes to write to protected areas and transparently redirects them to areas owned by the user.
ASLR Enabled : On Windows Vista and newer, indicates whether Address Space Layout Randomization (ASLR) is enabled for the process. ASLR is a defense-in-depth security feature that can mitigate remote attacks that assume that function entry points are at predictable memory addresses.
Process Performance Tab
The Process Performance tab contains attributes relating to CPU usage as well as the number of threads and open handles in the process. Some of the attributes report cumulative data, while others show the delta (the difference) since the previous update.
CPU Usage : The percentage of time that a process used the CPU since the last update (listed as CPU in the column heading).
CPU History : A graphical representation of the recent CPU usage charged to each process. Kernel-mode time is shown in red and user-mode time in green.
CPU Time : The total amount of kernel-mode and user-mode CPU time charged to the process (or pseudo-process), shown as hours:minutes:seconds.milliseconds.
Start Time : The time and date that the process was started.
Base Priority : The scheduling priority for the process. A value of 8 is normal priority; numbers above 8 indicate a higher priority, and those below 8 indicate a lower priority.
Threads : The number of threads in the process.
Handle Count : The number of handles to kernel objects currently opened by the process.
CPU Cycles : On Windows Vista and newer, the total number of kernel-mode and user-mode CPU cycles consumed by the process since it started. (On Windows Vista, this number is not tracked for the Interrupts pseudo-process.)
CPU Cycles Delta : On Windows Vista and newer, the number of CPU cycles consumed by the process since the previous update. (On Windows Vista, this number is not tracked for the Interrupts pseudo-process.)
Process Memory Tab
The Process Memory tab (shown in Figure 3-9) contains attributes relating to memory usage, including virtual memory management metrics around working set and page faults, as well as counts of the windowing system’s GDI and USER objects.
Page Faults : The total number of times that the process accessed an invalid memory page, causing the memory manager fault handler to be invoked. Some reasons for pages being invalid are these: the page is on disk in a page file or a mapped file, first access requires copying or zeroing, and there was illegal access resulting in an access violation. Note that this total includes soft page faults (that is, faults resolved by referencing information not in the working set but already in physical memory).
Page Fault Delta : The number of page faults that occurred since the previous display refresh. Note that the column header is labeled “PF Delta.”
Private Bytes : The number of bytes allocated and committed by the process for its own use and not shareable with other processes. Per-process private bytes include heap and stack memory. A continual rise in this value can indicate a memory leak.
Private Delta Bytes : The amount of change—positive or negative—in the number of private bytes since the previous refresh.
Peak Private Bytes : The largest number of private bytes the process had committed at any one time since the process started.
Private Bytes History : A graphical representation of the process’ private byte commit history. The wider you make this column, the longer the timeframe it shows. Note that the graph scale is the same for all processes and is based on the maximum number of private bytes currently committed by any process.
Virtual Size : The amount of the process’ virtual memory that has been reserved or committed.
Memory Priority : In Windows Vista and newer, the default memory priority that is assigned to physical memory pages used by the process. Pages that are cached in RAM and not part of any working set get repurposed starting with the lowest priority.
Minimum Working Set : The amount of physical memory reserved for the process; the operating system guarantees that the process’ working set can always be assigned at least this amount. The process can also lock pages in the working set up to that amount minus eight pages. This minimum does not guarantee that the process’ working set will always be at least that large, unless a hard limit has been set by a resource management application.
Maximum Working Set : Indicates the maximum amount of working set assigned to the process. However, this number is ignored by Windows unless a hard limit has been configured for the process by a resource management application.
Working Set Size : The amount of physical memory assigned to the process by the
memory manager.
Peak Working Set Size : The largest working set size the process has had since its start.
WS Shareable Bytes : The portion of the process’ working set that contains memory that can be shared with other processes, such as mapped executable images.
WS Shared Bytes : The portion of the process’ working set that contains memory that is currently shared with other processes.
WS Private Bytes : The portion of the process’ working set that contains private bytes
that cannot be shared with other processes.
GDI Objects : The number of Graphics Device Interface (GDI) objects—such as brushes,
fonts, and bitmaps—owned by the process.
USER Objects : The number of USER objects—such as windows and menus—owned by
the process.
.NET Tab
The .NET tab contains performance counters that measure behaviors of processes that use the .NET framework version 1.1 or higher.
These numbers are all dynamic. Administrative rights are required to observe them in a process running in a different security context:
Methods Jitted : Displays the total number of methods just-in-time (JIT) compiled since the application started.
% Time in JIT : Displays the percentage of elapsed time spent in JIT compilation since the last JIT compilation phase.
AppDomains : Displays the current number of application domains loaded in this application.
Total AppDomains : Displays the peak number of application domains loaded since the application started.
Classes Loaded : Displays the current number of classes loaded in all assemblies.
Total Classes : Loaded Displays the cumulative number of classes loaded in all assemblies since the application started.
Assemblies : Displays the current number of assemblies loaded across all application domains in the currently running application. If this keeps increasing, it could indicate an assembly leak.
Total Assemblies : Displays the total number of assemblies loaded since the application started.
Gen 0, 1, 2 Collections : Displays the number of times that generation 0, 1, or 2 objects have been garbage collected since the application began. Generation 0 objects are the newest, most recently allocated objects, while Gen 2 collections are also called full garbage collections. Higher generation garbage collections include all lower generation collections.
% Time in GC : Displays the percentage of elapsed time that was spent performing a garbage collection since the last garbage collection cycle.
Allocated Bytes/s : Displays the number of bytes per second allocated on the garbage collection heap.
Heap Bytes : Displays the number of bytes allocated in all heaps in the process.
Runtime Checks : Displays the total number of runtime code access security checks performed since the application started.
Contentions Displays : the total number of times that threads in the runtime have attempted to acquire a managed lock unsuccessfully.
Process I/O Tab
The Process I/O tab contains attributes relating to file and device I/O, including file I/O
I/O operations : There are four metrics each for I/O Read, Write, and Other operations: the total number of operations performed by the process since it started (Reads), the total number of bytes involved in those operations (Read Bytes), the number of operations performed since the last update (Delta Reads), and the number of bytes since the last update (Delta Read Bytes).
Delta Total Bytes : Represents the number of bytes involved in I/O operations since the previous update.
I/O History : A graphical representation of the process’ recent I/O throughput. The blue line represents the total throughput, while the pink line shows write traffic.
I/O Priority : On Windows Vista and newer, shows the I/O priority for the process. I/O prioritization allows the I/O subsystem to distinguish between foreground processes and lower-priority background processes. Most processes have a priority of Normal, while others can be Low or Very Low. Only the memory manager has Critical I/O priority. A fifth level, High, is not used in current versions of Windows.
Process Network Tab
The Process Network tab lets you configure Procexp to show the numbers of TCP connect, send, receive, and disconnect operations; the number of bytes in those operations; and the deltas since the previous refresh.
Receive Bytes : Number of data bytes received by the process from network adapter
Delta Receive Bytes : Represents the Number of bytes received by the process from network adapter since
the previous refresh .
Send Bytes : Number of data bytes sent by the process from network adapter
Delta Send Bytes : Represents the Number of bytes sent by the process from network adapter since
the previous refresh.
Process Disk Tab
Enabling column displays of the attributes on the Process Disk tab shows I/O to local disks (not including CD/DVD drives).
Read Bytes : The number of bytes read from the storage device (hard disk) by the process
Delta read bytes : The number of bytes read from the storage device (hard disk) by the process since
the previous refresh .
Write bytes : The number of bytes written on the storage device (hard disk) by the process
Delta write bytes : The number of bytes read from the storage device (hard disk) by the process since
the previous refresh .
GPU usage Tab
Monitor resource usage by processes
Monitor which application is consuming the computer resources.
- Start process explorer as “Administrator” user
- Let it run for 6 hours or 12 hours and keep it minimized. During this time process explorer will log all the resource usage.
- During this time you can do your usual tasks : web browsing, run audio video contents.
- The columns that will show the hard disk, network and CPU usages are :
Disk Read Bytes
- Click “Disk read Bytes”. This will arrange it in descending order.
- Now you can see which process has read how many bytes from the hard disk the most.
- This gives you a very good idea about which processes are consuming the hard disk resource
Disk Write Bytes
Shows which processes has written most data bytes on the hard disk
Network Receive Bytes
Show which processes has received the most that data bytes from network
Network Sent Bytes
Show which processes has sent the most that data bytes from network
Cycles
Shows which processes has consume the most CPU cycles.
- You must ignore "System idle process" because it is not an actual process.
Process, Threads, Jobs, handles, stack
Process
Although programs and processes appear similar on the surface, they are fundamentally different. A program is a static sequence of instructions, whereas a process is a container for a set of resources used to execute a program. At the highest level of abstraction, a Windows process comprises the following:
Each process also has a record of the PID of its parent process. However, if the parent exits, this information is not updated. Therefore, it is possible for a process to reference a nonexistent parent or even a different process that has been assigned the original parent’s PID. A process records its parent PID only for informational purposes, however.
Windows provides an extension to the process model called a job. A job object’s main function is to allow groups of processes to be managed and manipulated as a unit. For example, a job can be used to terminate a group of processes all at once instead of one at a time and without the calling process having to know which processes are in the group. A job object also allows control of certain attributes and provides limits for the process or processes associated with the job. For example, jobs can enforce per-process or job-wide limits on user-mode execution time and committed virtual memory. Windows Management Instrumentation (WMI) loads its providers into separate host processes controlled by a job that limits memory consumption as well as the total number of WMI provider host processes that can run at one time.
Thread
As mentioned, a process is merely a container. Technically, it is not the process that runs—it is its threads. A thread is the entity within a process that Windows schedules for execution, and it includes the following essential components:
Although threads have their own execution context, every thread within a process shares the process’ virtual address space (in addition to the rest of the resources belonging to the process), meaning that all the threads in a process can write to and read from one another’s memory. Threads cannot reference the address space of another process, however, unless the other process makes available part of its private address space as a shared memory section (called a file mapping object in the Windows API) or unless one process has the right to open another process to use cross-process memory functions.
By default, threads don’t have their own access token, but they can obtain one, thus allowing individual threads to impersonate a different security context—including that of a process running on a remote Windows system—without affecting other threads in the process.
Handles
The kernel-mode core of Windows, which is implemented in Ntoskrnl.exe, consists of various subsystems such as the Memory Manager, Process Manager, I/O Manager, and Configuration Manager (registry), which are all parts of the Executive. Each of these subsystems defines one or more types with the Object Manager to represent the resources they expose to applications. For example, the Configuration Manager defines the Key object to represent an open registry key; the Memory Manager defines the Section object for shared memory; the Executive defines Semaphore, Mutant (the internal name for a mutex), and Event synchronization objects (which are objects that wrap fundamental data structures defined by the operating system’s Kernel subsystem); the I/O Manager defines the File object to represent open instances of device-driver resources, which include file system files; and the Process Manager creates Thread and Process objects. Every release of Windows introduces new object types, with Windows 7 defining a total of 42.
When an application wants to use one of these resources, it first must call the appropriate API to create or open the resource. For instance, the CreateFile function opens or creates a file, the RegOpenKeyEx function opens a registry key, and the CreateSemaphoreEx function opens or creates a semaphore. If the function succeeds, Windows allocates a reference to the object in the process’ handle table, which is maintained by the Executive, and returns the index of the new handle table entry to the application.
This handle value is what the application uses for subsequent operations on the resource. To query or manipulate the resource, the application passes the handle value to API functions such as ReadFile, SetEvent, SetThreadPriority, and MapViewOfFile. The system can look up the object the handle refers to by indexing into the handle table to locate the corresponding handle entry, which contains a pointer to the object. The handle entry also stores the accesses the process was granted at the time it opened the object, which enables the system to make sure it doesn’t allow the process to perform an operation on the object for which it didn’t ask permission. For example, if the process successfully opened a file for read access but tried to use the handle to write to the file, the function would fail.
When a process no longer needs access to an object, it can release its handle to that object, typically by passing the handle value to the CloseHandle API. (Note that some resource managers provide a different API to release its resources.) When a process exits, any handles it still possesses are closed.
Call Stacks and Symbols
Process Explorer can display details about the code paths being executed at a particular point in time called call stacks. Associating symbols with the modules in a process’ address space provides more meaningful context information about those code paths, particularly within Windows operating system code. Understanding call stacks and symbols, and how to configure them in the Sysinternals utilities, gives tremendous insight into a process’ behavior and can often lead to the root cause of a problem.
What Is a Call Stack?
Executable code in a process is normally organized as a collection of discrete functions. To perform its tasks, a function can invoke other functions (subfunctions). When a function has finished, it returns control back to the function that called it.
A made-up example, shown in Figure demonstrates this flow. MyApp.exe ships with a DLL named HelperFunctions.dll. That DLL includes a function named EncryptThisText that encrypts text passed to it. After performing some preparatory operations, EncryptThisText calls the Windows API CryptEncryptMessage in Crypt32.dll. At some point, CryptEncryptMessage needs to allocate some memory and invokes the memory-allocation function malloc in Msvcrt.dll. After malloc has done its work and allocated the requested memory, execution resumes at the point where CryptEncryptMessage had left off. And when CryptEncryptMessage has completed its task, control returns back to the point in EncryptThisText just after its call to CryptEncryptMessage.
The call stack is the construct that allows the system to know how to return control to a series of callers, as well as to pass parameters between functions and to store local function variables. It’s organized in a “last in, first out” manner, where functions remove items in the reverse order from how they add them. When a function is about to call a subfunction, it puts the memory address of the next instruction to execute upon returning from the subfunction (its “return address”) at the top of the stack. When that subfunction calls yet another function, it adds its own return address to the stack. On returning from a function, the system retrieves whatever address is at the top of the stack and begins executing code from that point.
The convention for displaying a return address in a call stack is module!function+offset, where module is the name of the executable image file containing the function, and offset is the number of bytes (in hexadecimal) past the beginning of the function. If the function name is not available, the address is shown simply as “module+offset”. While malloc is executing in the fictitious example just given, the call stack might look like this:
msvcrt!malloc+0x2a
crypt32!CryptEncryptMessage+0x9f
HelperFunctions!EncryptThisText+0x43
MyApp.exe+0x25d8
As you can see, a call stack not only tells you what piece of code is executing, it also tells you
how the program got there.
What Are Symbols?
When inspecting a thread start address or a return address on a call stack, a debugger can easily determine what module it belongs to by examining the list of loaded modules and their address ranges. However, when a compiler converts a developer’s source code into computer instructions, it does not retain the original function names. The one exception is that a DLL includes an export table that lists the names and offsets of the functions it makes available to other modules. However, the export table does not list the names of the library’s internal functions, nor does it list the names of COM entry points that are designed to be discovered at runtime.
When creating executable files, compilers and linkers can also create corresponding symbol files (with the default extension PDB). Symbol files hold a variety of data that is not needed when running the executable code but which can be useful during debugging, including the names and entry point offsets of functions within the module. With this information, a debugger can take a memory address and easily identify the function with the closest preceding address. Without symbols, the debugger is limited to using exported functions, if any, which might have no relation at all to the code being executed. In general, the larger the offset on a return address, the less likely the reported function name is to be accurate.
A symbol file must be built at the same time as its corresponding executable or it will not be correct and the debug engine might refuse to use it. Older versions of Microsoft Visual C++ created symbol files only for Debug builds unless the developer explicitly changed the build configuration. Newer versions now create symbol files for Release builds as well, writing them into the same folder with the executable files. Microsoft Visual Basic 6 can create symbol files, but it does not do so by default.
Symbol files can contain differing levels of detail. Full symbol files (sometimes called private symbol files) contain details that are not found in public symbol files, including the path to and the line number within the source file where the symbol is defined, function parameter names and types, and variable names and types. Software companies that make symbol files externally available typically release only public symbol files, while retaining the full symbol files for internal use.
The Debugging Tools for Windows make it possible to download correct symbol files on demand from a symbol server. The server can store symbol files for many different builds of a given executable file, and the Debugging Tools will download the one that matches the image you are debugging. (It uses the timestamp and checksum stored in the executable’s header as a unique identifier.)
Microsoft has a symbol server accessible over the Web that makes Windows’ public symbol files freely available. By installing the Debugging Tools for Windows and configuring the Sysinternals utilities to use the Microsoft symbol server, you can easily see what Windows functions are being invoked by your processes.
Although programs and processes appear similar on the surface, they are fundamentally different. A program is a static sequence of instructions, whereas a process is a container for a set of resources used to execute a program. At the highest level of abstraction, a Windows process comprises the following:
- A unique identifier called a process ID (PID).
- At least one thread of execution. Every thread in a process has full access to all the resources referenced by the process container
- A private virtual address space, which is a set of virtual memory addresses that the process can use to store and reference data and code
- An executable program, which defines initial code and data and is mapped into the process’ virtual address space
- A list of open handles to various system resources, such as semaphores, communication ports, and files
- A security context called an access token that identifies the user, security groups, privileges, UAC virtualization state, LSA logon session ID, and terminal services session ID
Each process also has a record of the PID of its parent process. However, if the parent exits, this information is not updated. Therefore, it is possible for a process to reference a nonexistent parent or even a different process that has been assigned the original parent’s PID. A process records its parent PID only for informational purposes, however.
Windows provides an extension to the process model called a job. A job object’s main function is to allow groups of processes to be managed and manipulated as a unit. For example, a job can be used to terminate a group of processes all at once instead of one at a time and without the calling process having to know which processes are in the group. A job object also allows control of certain attributes and provides limits for the process or processes associated with the job. For example, jobs can enforce per-process or job-wide limits on user-mode execution time and committed virtual memory. Windows Management Instrumentation (WMI) loads its providers into separate host processes controlled by a job that limits memory consumption as well as the total number of WMI provider host processes that can run at one time.
Thread
As mentioned, a process is merely a container. Technically, it is not the process that runs—it is its threads. A thread is the entity within a process that Windows schedules for execution, and it includes the following essential components:
- The contents of a set of CPU registers representing the state of the processor. These include an instruction pointer that identifies the next machine instruction the thread will execute.
- Two stacks, one for the thread to use while executing in kernel mode and one for executing in user mode.
- A private storage area called thread-local storage (TLS) for use by subsystems, run-time libraries, and dynamic-link libraries (DLLs).
- A unique identifier called a thread ID (TID). Process IDs and thread IDs are generated from the same namespace, so they never overlap.
- Threads sometimes have their own security context that is often used by multithreaded server applications that impersonate the security context of the clients they serve.
Although threads have their own execution context, every thread within a process shares the process’ virtual address space (in addition to the rest of the resources belonging to the process), meaning that all the threads in a process can write to and read from one another’s memory. Threads cannot reference the address space of another process, however, unless the other process makes available part of its private address space as a shared memory section (called a file mapping object in the Windows API) or unless one process has the right to open another process to use cross-process memory functions.
By default, threads don’t have their own access token, but they can obtain one, thus allowing individual threads to impersonate a different security context—including that of a process running on a remote Windows system—without affecting other threads in the process.
Handles
The kernel-mode core of Windows, which is implemented in Ntoskrnl.exe, consists of various subsystems such as the Memory Manager, Process Manager, I/O Manager, and Configuration Manager (registry), which are all parts of the Executive. Each of these subsystems defines one or more types with the Object Manager to represent the resources they expose to applications. For example, the Configuration Manager defines the Key object to represent an open registry key; the Memory Manager defines the Section object for shared memory; the Executive defines Semaphore, Mutant (the internal name for a mutex), and Event synchronization objects (which are objects that wrap fundamental data structures defined by the operating system’s Kernel subsystem); the I/O Manager defines the File object to represent open instances of device-driver resources, which include file system files; and the Process Manager creates Thread and Process objects. Every release of Windows introduces new object types, with Windows 7 defining a total of 42.
When an application wants to use one of these resources, it first must call the appropriate API to create or open the resource. For instance, the CreateFile function opens or creates a file, the RegOpenKeyEx function opens a registry key, and the CreateSemaphoreEx function opens or creates a semaphore. If the function succeeds, Windows allocates a reference to the object in the process’ handle table, which is maintained by the Executive, and returns the index of the new handle table entry to the application.
This handle value is what the application uses for subsequent operations on the resource. To query or manipulate the resource, the application passes the handle value to API functions such as ReadFile, SetEvent, SetThreadPriority, and MapViewOfFile. The system can look up the object the handle refers to by indexing into the handle table to locate the corresponding handle entry, which contains a pointer to the object. The handle entry also stores the accesses the process was granted at the time it opened the object, which enables the system to make sure it doesn’t allow the process to perform an operation on the object for which it didn’t ask permission. For example, if the process successfully opened a file for read access but tried to use the handle to write to the file, the function would fail.
When a process no longer needs access to an object, it can release its handle to that object, typically by passing the handle value to the CloseHandle API. (Note that some resource managers provide a different API to release its resources.) When a process exits, any handles it still possesses are closed.
Call Stacks and Symbols
Process Explorer can display details about the code paths being executed at a particular point in time called call stacks. Associating symbols with the modules in a process’ address space provides more meaningful context information about those code paths, particularly within Windows operating system code. Understanding call stacks and symbols, and how to configure them in the Sysinternals utilities, gives tremendous insight into a process’ behavior and can often lead to the root cause of a problem.
What Is a Call Stack?
Executable code in a process is normally organized as a collection of discrete functions. To perform its tasks, a function can invoke other functions (subfunctions). When a function has finished, it returns control back to the function that called it.
A made-up example, shown in Figure demonstrates this flow. MyApp.exe ships with a DLL named HelperFunctions.dll. That DLL includes a function named EncryptThisText that encrypts text passed to it. After performing some preparatory operations, EncryptThisText calls the Windows API CryptEncryptMessage in Crypt32.dll. At some point, CryptEncryptMessage needs to allocate some memory and invokes the memory-allocation function malloc in Msvcrt.dll. After malloc has done its work and allocated the requested memory, execution resumes at the point where CryptEncryptMessage had left off. And when CryptEncryptMessage has completed its task, control returns back to the point in EncryptThisText just after its call to CryptEncryptMessage.
The call stack is the construct that allows the system to know how to return control to a series of callers, as well as to pass parameters between functions and to store local function variables. It’s organized in a “last in, first out” manner, where functions remove items in the reverse order from how they add them. When a function is about to call a subfunction, it puts the memory address of the next instruction to execute upon returning from the subfunction (its “return address”) at the top of the stack. When that subfunction calls yet another function, it adds its own return address to the stack. On returning from a function, the system retrieves whatever address is at the top of the stack and begins executing code from that point.
The convention for displaying a return address in a call stack is module!function+offset, where module is the name of the executable image file containing the function, and offset is the number of bytes (in hexadecimal) past the beginning of the function. If the function name is not available, the address is shown simply as “module+offset”. While malloc is executing in the fictitious example just given, the call stack might look like this:
msvcrt!malloc+0x2a
crypt32!CryptEncryptMessage+0x9f
HelperFunctions!EncryptThisText+0x43
MyApp.exe+0x25d8
As you can see, a call stack not only tells you what piece of code is executing, it also tells you
how the program got there.
What Are Symbols?
When inspecting a thread start address or a return address on a call stack, a debugger can easily determine what module it belongs to by examining the list of loaded modules and their address ranges. However, when a compiler converts a developer’s source code into computer instructions, it does not retain the original function names. The one exception is that a DLL includes an export table that lists the names and offsets of the functions it makes available to other modules. However, the export table does not list the names of the library’s internal functions, nor does it list the names of COM entry points that are designed to be discovered at runtime.
When creating executable files, compilers and linkers can also create corresponding symbol files (with the default extension PDB). Symbol files hold a variety of data that is not needed when running the executable code but which can be useful during debugging, including the names and entry point offsets of functions within the module. With this information, a debugger can take a memory address and easily identify the function with the closest preceding address. Without symbols, the debugger is limited to using exported functions, if any, which might have no relation at all to the code being executed. In general, the larger the offset on a return address, the less likely the reported function name is to be accurate.
A symbol file must be built at the same time as its corresponding executable or it will not be correct and the debug engine might refuse to use it. Older versions of Microsoft Visual C++ created symbol files only for Debug builds unless the developer explicitly changed the build configuration. Newer versions now create symbol files for Release builds as well, writing them into the same folder with the executable files. Microsoft Visual Basic 6 can create symbol files, but it does not do so by default.
Symbol files can contain differing levels of detail. Full symbol files (sometimes called private symbol files) contain details that are not found in public symbol files, including the path to and the line number within the source file where the symbol is defined, function parameter names and types, and variable names and types. Software companies that make symbol files externally available typically release only public symbol files, while retaining the full symbol files for internal use.
The Debugging Tools for Windows make it possible to download correct symbol files on demand from a symbol server. The server can store symbol files for many different builds of a given executable file, and the Debugging Tools will download the one that matches the image you are debugging. (It uses the timestamp and checksum stored in the executable’s header as a unique identifier.)
Microsoft has a symbol server accessible over the Web that makes Windows’ public symbol files freely available. By installing the Debugging Tools for Windows and configuring the Sysinternals utilities to use the Microsoft symbol server, you can easily see what Windows functions are being invoked by your processes.
Configuring Symbols
Dbghelp.dll path
The Sysinternals utilities that use symbols require two pieces of information, a the location of the Dbghelp.dll to use, and the symbols path. The Sysinternals utilities that can use full symbolic information to display source files also request source code paths.
Dbghelp.dll is one of Microsoft’s debug engine DLLs, and it provides the functionality for walking a call stack, loading symbol files, and resolving process memory addresses to names. Only the version of Dbghelp.dll that ships in the Debugging Tools for Windows supports the downloading of files from symbol servers. The Dbghelp.dll that ships with Windows in the %SystemRoot%\System32 directory can use only symbol files stored locally. The first time you run them, Sysinternals utilities check default installation locations for the Debugging Tools and use its Dbghelp.dll if found. Otherwise, it defaults to using the version in %SystemRoot%\System32.
The URL for the Debugging Tools for Windows is
It is not necessary to install it. But you may install it
After the installation of debugging tools, you should find the path of dbghelp.dll in subfolder of "C:\Program Files (x86)\Windows Kits\"
Symbol path
The symbols path tells the debugging engine where to search for symbol files if they cannot be found in default locations. The two default locations that the debugging engine searches for symbol files before checking the symbols path are the executable’s folder and the folder where the symbol file was originally created, if that information is in the executable file.
The symbols path can consist of file system folders and symbol server directives. The first time you run it, the Sysinternals utility will set its symbol path to the value of the _NT_SYMBOL_PATH environment variable. If that variable is not defined, the utility sets its symbol path to
which uses the Microsoft public symbol server but does not save the downloaded symbol files to a local cache.
The Sysinternals utilities that use symbols require two pieces of information, a the location of the Dbghelp.dll to use, and the symbols path. The Sysinternals utilities that can use full symbolic information to display source files also request source code paths.
Dbghelp.dll is one of Microsoft’s debug engine DLLs, and it provides the functionality for walking a call stack, loading symbol files, and resolving process memory addresses to names. Only the version of Dbghelp.dll that ships in the Debugging Tools for Windows supports the downloading of files from symbol servers. The Dbghelp.dll that ships with Windows in the %SystemRoot%\System32 directory can use only symbol files stored locally. The first time you run them, Sysinternals utilities check default installation locations for the Debugging Tools and use its Dbghelp.dll if found. Otherwise, it defaults to using the version in %SystemRoot%\System32.
The URL for the Debugging Tools for Windows is
It is not necessary to install it. But you may install it
After the installation of debugging tools, you should find the path of dbghelp.dll in subfolder of "C:\Program Files (x86)\Windows Kits\"
Symbol path
The symbols path tells the debugging engine where to search for symbol files if they cannot be found in default locations. The two default locations that the debugging engine searches for symbol files before checking the symbols path are the executable’s folder and the folder where the symbol file was originally created, if that information is in the executable file.
The symbols path can consist of file system folders and symbol server directives. The first time you run it, the Sysinternals utility will set its symbol path to the value of the _NT_SYMBOL_PATH environment variable. If that variable is not defined, the utility sets its symbol path to
which uses the Microsoft public symbol server but does not save the downloaded symbol files to a local cache.
- Dbghelp.dll path should look similar to "C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\dbghelp.dll" .
- Symbols path "srv*https://msdl.microsoft.com/download/symbols"
Using find handle & Dll
One of Procexp’s most powerful features is its ability to quickly identify the process or
processes that have a DLL loaded or an object open.
Search which process has locked a file
You may have come across file that you are unable to delete. This occurs when that file has been locked by an process running in memory.
processes that have a DLL loaded or an object open.
- Open find Handle & Dll window. Shortcut for it is "Ctrl+F"
- To search the processes which has open the dll file "a2hooks64.dll" , enter the name of the dll file in search bar and click "Search"
- You can see below that process explorer has searched all the processes which has opened the dll file named "a2hooks64.dll"
Search which process has locked a file
You may have come across file that you are unable to delete. This occurs when that file has been locked by an process running in memory.
- To search the process which has locked the file , enter the name of the locked file in search bar and click "Search"
- Process explorer will find the process which has locked that particular file. Double click on the process name and process explore will mark the process which has locked that file.
- In this case, pdf file "browser-uniqueness.pdf" file has been locked by process FoxitReader.exe
- You can close that application which has locked the file you want to delete. Then you will be able to delete that file.
- Or you can forcibly close the file handle. Then you will be able to delete the locked file.
- Rght click the file handle as shown below and select "Close handle"
- When warned select "Yes"
Detecting & Removing active malwares
Last edited:
