Windows differs from most other operating systems in that most internal text strings are stored and processed as 16-bit-wide Unicode characters. Unicode is an international character set standard that defines unique 16-bit values for most of the world's known character sets.
Because many applications deal with 8-bit (single-byte) ANSI character strings, Windows functions that accept string parameters have two entry points: a Unicode (wide, 16-bit) and an ANSI (narrow, 8-bit) version.
Tuesday, July 17, 2007
Registry
You can't talk much about Windows internals without referring to the registry because it's the system database that contains the information required to boot and configure the system, systemwide software settings that control the operation of Windows, the security database, and per-user configuration settings (such as which screen saver to use).
In addition, the registry is a window into in-memory volatile data, such as the current hardware state of the system (what device drivers are loaded, the resources they are using, and so on) as well as the Windows performance counters.
In addition, the registry is a window into in-memory volatile data, such as the current hardware state of the system (what device drivers are loaded, the resources they are using, and so on) as well as the Windows performance counters.
Security
The core security capabilities of Windows include: discretionary (need-to-know) protection for all shareable system objects (such as files, directories, processes, threads, and so forth), security auditing (for accountability of subjects, or users and the actions they initiate), password authentication at logon, and the prevention of one user from accessing uninitialized resources (such as free memory or disk space) that another user has deallocated.
Windows has two forms of access control over objects. The first form—discretionary access control—is the protection mechanism that most people think of when they think of operating system security. It's the method by which owners of objects (such as files or printers) grant or deny access to others. When users log in, they are given a set of security credentials, or a security context. When they attempt to access objects, their security context is compared to the access control list on the object they are trying to access to determine whether they have permission to perform the requested operation.
Privileged access control is necessary for those times when discretionary access control isn't enough. It's a method of ensuring that someone can get to protected objects if the owner isn't available.
Windows has two forms of access control over objects. The first form—discretionary access control—is the protection mechanism that most people think of when they think of operating system security. It's the method by which owners of objects (such as files or printers) grant or deny access to others. When users log in, they are given a set of security credentials, or a security context. When they attempt to access objects, their security context is compared to the access control list on the object they are trying to access to determine whether they have permission to perform the requested operation.
Privileged access control is necessary for those times when discretionary access control isn't enough. It's a method of ensuring that someone can get to protected objects if the owner isn't available.
Security pervades the interface of the Windows API. The Windows subsystem implements object-based security in the same way the operating system does; the Windows subsystem protects shared Windows objects from unauthorized access by placing Windows security descriptors on them. The first time an application tries to access a shared object, the Windows subsystem verifies the application's right to do so. If the security check succeeds, the Windows subsystem allows the application to proceed.
Objects and Handles
In the Windows operating system, an object is a single, run-time instance of a statically defined object type. An object type comprises a system-defined data type, functions that operate on instances of the data type, and a set of object attributes. If you write Windows applications, you might encounter process, thread, file, and event objects, to name just a few examples. These objects are based on lower-level objects that Windows creates and manages.
An object attribute is a field of data in an object that partially defines the object's state.
Object methods, the means for manipulating objects, usually read or change the object attributes.
The most fundamental difference between an object and an ordinary data structure is that the internal structure of an object is hidden.
An object attribute is a field of data in an object that partially defines the object's state.
Object methods, the means for manipulating objects, usually read or change the object attributes.
The most fundamental difference between an object and an ordinary data structure is that the internal structure of an object is hidden.
Objects provide a convenient means for accomplishing the following four important operating system tasks:
-
Providing human-readable names for system resources
-
Sharing resources and data among processes
-
Protecting resources from unauthorized access
-
Reference tracking, which allows the system to know when an object is no longer in use so that it can be automatically deallocated
Terminal Services and Multiple Sessionsw
Terminal Services refers to the support in Windows for multiple interactive user sessions on a single system. With Windows Terminal Services, a remote user can establish a session on another machine, log in, and run applications on the server. The server transmits the graphical user interface to the client, and the client transmits the user's input back to the server. (This is different than X windows on UNIX systems, which permit running individual applications on a server system with the display remoted to the client, because the entire user session is remoted, not just a single application.)
The first login session at the physical console of the machine is considered the console session, or session zero. Additional sessions can be created through the use of the remote desktop connection program (Mstsc.exe) or on Windows XP systems through the use of fast user switching (described later).
Windows XP Professional permits a single remote user to connect to the machine, but if someone is logged in at the console, the workstation is locked (that is, someone can be using the system either locally or remotely, but not at the same time).
The first login session at the physical console of the machine is considered the console session, or session zero. Additional sessions can be created through the use of the remote desktop connection program (Mstsc.exe) or on Windows XP systems through the use of fast user switching (described later).
Windows XP Professional permits a single remote user to connect to the machine, but if someone is logged in at the console, the workstation is locked (that is, someone can be using the system either locally or remotely, but not at the same time).
Kernel Mode vs. User Mode
To protect user applications from accessing and/or modifying critical operating system data, Windows uses two processor access modes (even if the processor on which Windows is running supports more than two): user mode and kernel mode.
User application code runs in user mode, whereas operating system code (such as system services and device drivers) runs in kernel mode. Kernel mode refers to a mode of execution in a processor that grants access to all system memory and all CPU instructions. By providing the operating system software with a higher privilege level than the application software has, the processor provides a necessary foundation for operating system designers to ensure that a misbehaving application can't disrupt the stability of the system as a whole.
Although each Windows process has its own private memory space, the kernel-mode operating system and device driver code share a single virtual address space. Each page in virtual memory is tagged as to what access mode the processor must be in to read and/or write the page.
Windows doesn't provide any protection to private read/write system memory being used by components running in kernel mode. In other words, once in kernel mode, operating system and device driver code has complete access to system space memory and can bypass Windows security to access objects.
User applications switch from user mode to kernel mode when they make a system service call.
A transition from user mode to kernel mode (and back) does not affect thread scheduling per se—a mode transition is not a context switch.
Thus, it's normal for a user thread to spend part of its time executing in user mode and part in kernel mode. In fact, because the bulk of the graphics and windowing system also runs in kernel mode, graphics-intensive applications spend more of their time in kernel mode than in user mode.
User application code runs in user mode, whereas operating system code (such as system services and device drivers) runs in kernel mode. Kernel mode refers to a mode of execution in a processor that grants access to all system memory and all CPU instructions. By providing the operating system software with a higher privilege level than the application software has, the processor provides a necessary foundation for operating system designers to ensure that a misbehaving application can't disrupt the stability of the system as a whole.
Although each Windows process has its own private memory space, the kernel-mode operating system and device driver code share a single virtual address space. Each page in virtual memory is tagged as to what access mode the processor must be in to read and/or write the page.
Windows doesn't provide any protection to private read/write system memory being used by components running in kernel mode. In other words, once in kernel mode, operating system and device driver code has complete access to system space memory and can bypass Windows security to access objects.
User applications switch from user mode to kernel mode when they make a system service call.
A transition from user mode to kernel mode (and back) does not affect thread scheduling per se—a mode transition is not a context switch.
Thus, it's normal for a user thread to spend part of its time executing in user mode and part in kernel mode. In fact, because the bulk of the graphics and windowing system also runs in kernel mode, graphics-intensive applications spend more of their time in kernel mode than in user mode.
Virtual Memory
Windows implements a virtual memory system based on a flat (linear) address space that provides each process with the illusion of having its own large, private address space. Virtual memory provides a logical view of memory that might not correspond to its physical layout. At run time, the memory manager, with assistance from hardware, translates, or maps, the virtual addresses into physical addresses, where the data is actually stored. By controlling the protection and mapping, the operating system can ensure that individual processes don't bump into one another or overwrite operating system data.
Because most systems have much less physical memory than the total virtual memory in use by the running processes, the memory manager transfers, or pages, some of the memory contents to disk. Paging data to disk frees physical memory so that it can be used for other processes or for the operating system itself. When a thread accesses a virtual address that has been paged to disk, the virtual memory manager loads the information back into memory from disk. Applications don't have to be altered in any way to take advantage of paging because hardware support enables the memory manager to page without the knowledge or assistance of processes or threads.
The size of the virtual address space varies for each hardware platform.
Windows allocates half this address space (the lower half of the 4 GB virtual address space, from x00000000 through x7FFFFFFF) to processes for their unique private storage and uses the other half (the upper half, addresses x80000000 through xFFFFFFFF) for its own protected operating system memory utilization. The mappings of the lower half change to reflect the virtual address space of the currently executing process, but the mappings of the upper half always consist of the operating system's virtual memory.
Because most systems have much less physical memory than the total virtual memory in use by the running processes, the memory manager transfers, or pages, some of the memory contents to disk. Paging data to disk frees physical memory so that it can be used for other processes or for the operating system itself. When a thread accesses a virtual address that has been paged to disk, the virtual memory manager loads the information back into memory from disk. Applications don't have to be altered in any way to take advantage of paging because hardware support enables the memory manager to page without the knowledge or assistance of processes or threads.
The size of the virtual address space varies for each hardware platform.
Windows allocates half this address space (the lower half of the 4 GB virtual address space, from x00000000 through x7FFFFFFF) to processes for their unique private storage and uses the other half (the upper half, addresses x80000000 through xFFFFFFFF) for its own protected operating system memory utilization. The mappings of the lower half change to reflect the virtual address space of the currently executing process, but the mappings of the upper half always consist of the operating system's virtual memory.
Processes, Threads, and Jobs
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 when executing the instance of the program. At the highest level of abstraction, a Windows process comprises the following:
-
A private virtual address space, which is a set of virtual memory addresses that the process can use
-
An executable program, which defines initial code and data and is mapped into the process's virtual address space
-
A list of open handles to various system resources, such as semaphores, communication ports, and files, that are accessible to all threads in the process
-
A security context called an access token that identifies the user, security groups, and privileges associated with the process
-
A unique identifier called a process ID (internally called a client ID)
-
At least one thread of execution
Each process also points to its parent or creator process. However, if the parent exits, this information is not updated. Therefore, it is possible for a process to point to a nonexistent parent. This is not a problem, as nothing relies on this information being present.
A thread is the entity within a process that Windows schedules for execution. Without it, the process's program can't run. A thread includes the following essential components:
-
The contents of a set of CPU registers representing the state of the processor.
-
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 DLLs.
-
A unique identifier called a thread ID (also internally called a client ID—process IDs and thread IDs are generated out of 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 that they serve.
The volatile registers, stacks, and private storage area are called the thread's context. Because this information is different for each machine architecture that Windows runs on, this structure, by necessity, is architecture-specific. The Windows GetThreadContext function provides access to this architecture-specific information (called the CONTEXT block).
Although threads have their own execution context, every thread within a process shares the process's 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 each other's memory. Threads cannot accidentally 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 such as ReadProcessMemory and WriteProcessMemory.
In addition to a private address space and one or more threads, each process has a security identification and a list of open handles to objects such as files, shared memory sections, or one of the synchronization objects such as mutexes, events, or semaphores.
Every process has a security context that is stored in an object called an access token. The process access token contains the security identification and credentials for the process. By default, threads don't have their own access token, but they can obtain one, thus allowing individual threads to impersonate the security context of another process—including processes running on a remote Windows system—without affecting other threads in the process.
The virtual address descriptors (VADs) are data structures that the memory manager uses to keep track of the virtual addresses the process is using.
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. A job object allows control of certain attributes and provides limits for the process or processes associated with the job. It also records basic accounting information for all processes associated with the job and for all processes that were associated with the job but have since terminated. In some ways, the job object compensates for the lack of a structured process tree in Windows—yet in many ways it is more powerful than a UNIX-style process tree.
Services, Functions, and Routines
-
Windows API functions Documented, callable subroutines in the Windows API. Examples include CreateProcess, CreateFile, and GetMessage.
-
Native system services (or executive system services) The undocumented, underlying services in the operating system that are callable from user mode. For example, NtCreateProcess is the internal system service the Windows CreateProcess function calls to create a new process.
-
Kernel support functions (or routines) Subroutines inside the Windows operating system that can be called only from kernel mode (defined later in this chapter). For example, ExAllocatePool is the routine that device drivers call to allocate memory from the Windows system heaps.
-
Windows services Processes started by the Windows service control manager. For example, the Task Scheduler service runs in a usermode process that supports the at command (which is similar to the UNIX commands at or cron).
-
DLL (dynamic-link library) A set of callable subroutines linked together as a binary file that can be dynamically loaded by applications that use the subroutines. Examples include Msvcrt.dll (the C run-time library) and Kernel32.dll (one of the Windows API subsystem libraries). Windows user-mode components and applications use DLLs extensively. The advantage DLLs provide over static libraries is that applications can share DLLs, and Windows ensures that there is only one in-memory copy of a DLL's code among the applications that are referencing it.
What About .NET and WinFX?
The .NET Framework consists of a library of classes called the Framework Class Library (FCL) and a Common Language Runtime (CLR) that provides a managed code execution environment with features such as just-in-time compilation, type verification, garbage collection, and code access security. By offering these features, the CLR provides a development environment that improves programmer productivity and reduces common programming errors. (For an excellent description of the .NET Framework and its core architecture, see Applied Microsoft .NET Framework Programming by Jeffrey Richter.)
The CLR is implemented as a classic COM server whose code resides in a standard usermode Windows DLL. In fact, all components of the .NET Framework are implemented as standard user-mode Windows DLLs layered over unmanaged Windows API functions. (None of the .NET Framework runs in kernel mode.)
WinFX is "the new Windows API." It is the evolution of the .NET Framework that ships with Windows "Longhorn," the next major release of Windows. It will also be installable on Windows XP and Windows Server 2003. WinFX provides the foundation for the next generation of applications built for the Windows operating system.
Windows API
The Windows application programming interface (API) is the system programming interface to the Microsoft Windows operating system family, including Windows 2000, Windows XP, Windows Server 2003, Windows 95, Windows 98, Windows Millennium Edition (Me), and Windows CE. Each operating system implements a different subset of the Windows API.
Prior to the introduction of 64-bit versions of Windows XP and Windows Server 2003, the programming interface to the 32-bit version of the Windows operating systems was called the Win32 API, to distinguish it from the original 16-bit Windows API, which was the programming interface to the original 16-bit versions of Windows.
Prior to the introduction of 64-bit versions of Windows XP and Windows Server 2003, the programming interface to the 32-bit version of the Windows operating systems was called the Win32 API, to distinguish it from the original 16-bit Windows API, which was the programming interface to the original 16-bit versions of Windows.
The Windows API consists of thousands of callable functions, which are divided into the following major categories:
-
Base Services
-
Component Services
-
User Interface Services
-
Graphics and Multimedia Services
-
Messaging and Collaboration
-
Networking
-
Web Services
Monday, July 16, 2007
System Internals Tools 1
- Process Explorer for Windows v10.21
Ever wondered which program has a particular file or directory open? Now you can find out. Process Explorer shows you information about which handles and DLLs processes have opened or loaded.
The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you'll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded.
The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work.
Process Explorer works on Windows 9x/Me, Windows NT 4.0, Windows 2000, Windows XP, Server 2003, and 64-bit versions of Windows for x64 and IA64 processors, and Windows Vista.
CPU Usage by Processes (qslice.exe) Shows the percentage of total CPU usage per process.TList.exe The TList tool is a task-list application that prints a list of tasks to standard out (stdout). It can be used to determine the Process ID.- Debugging Tools for Windows
You can use Debugging Tools for Windows to debug drivers, applications, and services on systems running Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server codename "Longhorn," as well as for debugging the operating system itself. Versions of the Debugging Tools for Windows package are available for 32-bit x86, native Intel Itanium, and native x64 platforms.
Windows Server 2003 Resource Kit Tools The Microsoft® Windows® Server 2003 Resource Kit Tools are a set of tools to help administrators streamline management tasks such as troubleshooting operating system issues, managing Active Directory®, configuring networking and security features, and automating application deployment.Windows Server 2003 Administration Tools Pack The Windows Server 2003 Administration Tools Pack (adminpak.msi) provides server management tools that allow administrators to remotely manage Windows 2000 Servers & Windows Server 2003 family servers. This is the final version (build 3790) of the adminpak.msi file.Windows XP Support Tools The Windows Support Tools for Microsoft Windows XP are intended for use by Microsoft support personnel and experienced users to assist in diagnosing and resolving computer problems.- AutoRuns for Windows v8.70
This utility, which has the most comprehensive knowledge of auto-starting locations of any startup monitor, shows you what programs are configured to run during system bootup or login, and shows you the entries in the order Windows processes them. These programs include ones in your startup folder, Run, RunOnce, and other Registry keys. You can configure Autoruns to show other locations, including Explorer shell extensions, toolbars, browser helper objects, Winlogon notifications, auto-start services, and much more. Autoruns goes way beyond the MSConfig utility bundled with Windows Me and XP.
Autoruns' Hide Signed Microsoft Entries option helps you to zoom in on third-party auto-starting images that have been added to your system and it has support for looking at the auto-starting images configured for other accounts configured on a system. Also included in the download package is a command-line equivalent that can output in CSV format, Autorunsc.
You'll probably be surprised at how many executables are launched automatically!
Autoruns works on all versions of Windows including 64-bit versions.
- ListDLLs v2.25
A question that I often get asked is "Do you know of a utility that will show me which DLLs are loaded on Windows 9x or NT ". The answer I gave up until recently was "no", until I discovered a tool in the Windows NT Resource Kit called tlist that does show this information. I decided to write a free-ware version, ListDLLs. Unlike tlist, however, ListDLLs is able to show you the full path names of loaded modules - not just their base names. In addition, ListDLLs will flag loaded DLLs that have different version numbers than their corresponding on-disk files (which occurs when the file is updated after a program loads the DLL), and can tell you which DLLs were relocated because they are not loaded at their base address.
You can also get Process Explorer, a GUI-based version of this program, here at Sysinternals.
- EFSDump v1.02
Windows 2000 introduces the Encrypting File System (EFS) so that users can protect their sensitive data. Several new APIs make their debut to support this factility, including one - QueryUsersOnEncryptedFile - that lets you see who has access to encrypted files. This applet uses the API to show you what accounts are authorized to access encrypted files.
- FileMon for Windows v7.04
Note: Filemon and Regmon have been replaced by Process Monitor on versions of Windows starting with Windows 2000 SP4, Windows XP SP2, Windows Server 2003 SP1, and Windows Vista. Filemon and Regmon remain for legacy operating system support, including Windows 9x.
FileMon monitors and displays file system activity on a system in real-time. Its advanced capabilities make it a powerful tool for exploring the way Windows works, seeing how applications use the files and DLLs, or tracking down problems in system or application file configurations. Filemon's timestamping feature will show you precisely when every open, read, write or delete, happens, and its status column tells you the outcome. FileMon is so easy to use that you'll be an expert within minutes. It begins monitoring when you start it, and its output window can be saved to a file for off-line viewing. It has full search capability, and if you find that you're getting information overload, simply set up one or more filters.
FileMon works on NT 4.0, Windows 2000, Windows XP, Windows XP and Windows Server -bit Edition, Windows 2003 Server, Windows 95, Windows 98 and Windows ME.
- Handle
Ever wondered which program has a particular file or directory open? Now you can find out. Handle is a utility that displays information about open handles for any process in the system. You can use it to see the programs that have a file open, or to see the object types and names of all the handles of a program.
You can also get a GUI-based version of this program, Process Explorer, here at Sysinternals.
- Junction
Windows 2000 and higher supports directory symbolic links, where a directory serves as a symbolic link to another directory on the computer. For example, if the directory D:\SYMLINK specified C:\WINNT\SYSTEM32 as its target, then an application accessing D:\SYMLINK\DRIVERS would in reality be accessing C:\WINNT\SYSTEM32\DRIVERS. Directory symbolic links are known as NTFS junctions in Windows. Unfortunately, Windows comes with no tools for creating junctions - you have to purchase the Win2K Resource Kit, which comes with the linkd program for creating junctions. I therefore decided to write my own junction-creating tool: Junction. Junction not only allows you to create NTFS junctions, it allows you to see if files or directories are actually reparse points. Reparse points are the mechanism on which NTFS junctions are based, and they are used by Windows' Remote Storage Service (RSS), as well as volume mount points.
Please read this Microsoft KB article for tips on using junctions.
Note that Windows does not support junctions to directories on remote shares.
- LiveKd
LiveKD, a utility I wrote for the CD included with Inside Windows 2000, 3rd Edition, is now freely available. LiveKD allows you to run the Kd and Windbg Microsoft kernel debuggers, which are part of the Debugging Tools for Windows package, locally on a live system. Execute all the debugger commands that work on crash dump files to look deep inside the system. See the Debugging Tools for Windows documentation and our book for information on how to explore a system with the kernel debuggers.
While the latest versions of Windbg and Kd have a similar capability on Windows XP and Server 2003, LiveKD works on NT 4 through Server 2003, including x64 versions of Windows, and enables more functionality, such as viewing thread stacks with the !thread command, than Windbg and Kd's own live kernel debugging facility.
- LogonSessions
If you think that when you logon to a system there's only one active logon sessions this utility will surprise you. It lists the currently active logon sessions and, if you specify the -p option, the processes running in each session. LogonSessions works on Windows 2000 and higher.
- Winobj
WinObj is a must-have tool if you are a system administrator concerned about security, a developer tracking down object-related problems, or just curious about the Object Manager namespace.
WinObj is a 32-bit Windows NT program that uses the native Windows NT API (provided by NTDLL.DLL) to access and display information on the NT Object Manager's name space. Winobj may seem similar to the Microsoft SDK's program of the same name, but the SDK version suffers from numerous significant bugs that prevent it from displaying accurate information (e.g. its handle and reference counting information are totally broken). In addition, our WinObj understands many more object types. Finally, Version 2.0 of our WinObj has user-interface enhancements, knows how to open device objects, and will let you view and change object security information using native NT security editors.
- PendMoves
There are several applications, such as service packs and hotfixes, that must replace a file that's in use and is unable to. Windows therefore provides the MoveFileEx API to rename or delete a file and allows the caller to specify that they want the operation to take place the next time the system boots, before the files are referenced. Session Manager performs this task by reading the registered rename and delete commands from the HKLM\System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations value.
This applet dumps the contents of the pending rename/delete value and also reports an error when the source file is not accessible.
- PsGetSid
Have you performed a rollout and only to discover that your network might suffer from the SID duplication problem In order to know which systems have to be assigned a new SID (using a SID updater like our own NewSID) you have to know what a computer's machine SID is. Up until now there's been no way to tell the machine SID without knowing Regedit tricks and exactly where to look in the Registry. PsGetSid makes reading a computer's SID easy, and works across the network so that you can query SIDs remotely. PsGetSid also lets you see the SIDs of user accounts and translate a SID into the name that represents it.
- Regmon
Note: Filemon and Regmon have been replaced by Process Monitor on versions of Windows starting with Windows 2000 SP4, Windows XP SP2, Windows Server 2003 SP1, and Windows Vista. Filemon and Regmon remain for legacy operating system support, including Windows 9x.
Regmon is a Registry monitoring utility that will show you which applications are accessing your Registry, which keys they are accessing, and the Registry data that they are reading and writing - all in real-time. This advanced utility takes you one step beyond what static Registry tools can do, to let you see and understand exactly how programs use the Registry. With static tools you might be able to see what Registry values and keys changed. With Regmon you'll see how the values and keys changed..
Regmon works on Windows NT/2000/XP/2003, Windows 95/98/Me and Windows 64-bit for x64.
- TCPView for Windows v2.4
TCPView is a Windows program that will show you detailed listings of all TCP and UDP endpoints on your system, including the local and remote addresses and state of TCP connections. On Windows NT, 2000 and XP TCPView also reports the name of the process that owns the endpoint. TCPView provides a more informative and conveniently presented subset of the Netstat program that ships with Windows. The TCPView download includes Tcpvcon, a command-line version with the same functionality.
TCPView works on Windows NT/2000/XP and Windows 98/Me. You can use TCPView on Windows 95 if you get the Windows 95 Winsock 2 Update from Microsoft.
Tlist.exe is replaced by TaskList.exe in Windows XP?
Microsoft has replaced tlist.exe with tasklist.exe in XP. Tlist.exe lets you list all the processes running on your machine and the associated task name and memory usage. Tasklist.exe replicates all the functionality of the original utility. For information about tasklist.exe, type the following at the XP command prompt:
tasklist /?
The help message see below:
TASKLIST [/S system [/U username [/P [password]]]]
[/M [module] | /SVC | /V] [/FI filter] [/FO format] [/NH]
Description:
This command line tool displays a list of application(s) and
associated task(s)/process(es) currently running on either a local or
remote system.
Parameter List:
/S system Specifies the remote system to connect to.
/U [domain\]user Specifies the user context under which
the command should execute.
/P [password] Specifies the password for the given
user context. Prompts for input if omitted.
/M [module] Lists all tasks that have DLL modules loaded
in them that match the given pattern name.
If the module name is not specified,
displays all modules loaded by each task.
/SVC Displays services in each process.
/V Specifies that the verbose information
is to be displayed.
/FI filter Displays a set of tasks that match a
given criteria specified by the filter.
/FO format Specifies the output format.
Valid values: "TABLE", "LIST", "CSV".
/NH Specifies that the "Column Header" should
not be displayed in the output.
Valid only for "TABLE" and "CSV" formats.
/? Displays this help/usage.
Filters:
Filter Name Valid Operators Valid Value(s)
----------- --------------- --------------
STATUS eq, ne RUNNING | NOT RESPONDING
IMAGENAME eq, ne Image name
PID eq, ne, gt, lt, ge, le PID value
SESSION eq, ne, gt, lt, ge, le Session number
SESSIONNAME eq, ne Session name
CPUTIME eq, ne, gt, lt, ge, le CPU time in the format
of hh:mm:ss.
hh - hours,
mm - minutes, ss - seconds
MEMUSAGE eq, ne, gt, lt, ge, le Memory usage in KB
USERNAME eq, ne User name in [domain\]user
format
SERVICES eq, ne Service name
WINDOWTITLE eq, ne Window title
MODULES eq, ne DLL name
Examples:
TASKLIST
TASKLIST /M
TASKLIST /V
TASKLIST /SVC
TASKLIST /M wbem*
TASKLIST /S system /FO LIST
TASKLIST /S system /U domain\username /FO CSV /NH
TASKLIST /S system /U username /P password /FO TABLE /NH
TASKLIST /FI "USERNAME ne NT AUTHORITY\SYSTEM" /FI "STATUS eq running"
Problem: How to list the processes as tree list just same as the Tlist /t function ?
Subscribe to:
Posts (Atom)