Understand Windows 2000 and NT4 systems and processes (-)

zhaozj2021-02-16  63

Http://www.yythac.com/AR/LJJC1.TXT Source: Black Union This lecture number is TNQ 400-02, I am David Solomon, in the next two hours we will discuss how to observe through appearance Windows 2000 and Windows NT 4.0 in order to understand their internal running mechanism and how to implement these mechanisms in the system level, and will also understand the process running in the system. The purpose of this lecture is to give you help when you feel in the NT system or from behavioral positions, it seems to be helpful when something goes wrong; so that you can get closer to the part of the system housing and understand the CPU How to allocate time. If the system is slow, tell you what is running, why and how to separate the operating system time from the application execution.

This lecture assumes that you are familiar with basic operating system concepts, such as the process of the process, multitasking concept, virtual memory, pagination, etc.; and you are an experienced NT user - do not have to be a system administrator, but at least Should be an authoritative NT user.

After this lecture, you will be able to use a series of different tools to observe the activities inside the process so that you can find which file is opened, the source and target of the IO operation, which dynamic connection library (DLL) is being used by a process and they are Where to put it from the disk, some details about process security.

As I mentioned, one of the purposes of this lecture is to explain the CPU time. Therefore, if the CPU is running, what is it doing and why do you do this? Time spending there and how to take up: Is it used by operating systems, device drivers, executives or applications? It is understood that another aspect of the content of the NT operating system is to know which system processes exist. Therefore, if a transaction is running and it is not running, then it is part of the NT. What is the role of running processes, and how do you track the possible cause of CPU time? One of them is a Windows NT service consisting of a Windows NT system process. Sometimes it is not very clear that the service running is backward to which admin views can be seen by the management interface.

Finally, let's pay close attention to the level of granularity in the very special process of the system process, which contains special types of driver thread running fragments and NT fragments, and because of this existence of this special process, it is necessary to In-depth drilling to understand which fragments in the process is running and why.

This has a road map for this lecture. First of all, I will make a concise overview of the relevant tools and their sources. This will be a height-dependent tool lecture, and I will use the partial tools obtained on the toolkit, resource toolbox, and Internet. Next, we will observe the NT system activity from three angles: first is the process and thread, which is the interruption time and its service and interpretation mechanism in NT, and finally, the system process tree is traversed.

The final topic is a process activity we don't want to happen, but often encountered, that is, when the process dies, seeing Dr. Watson information. We will see what leads to Dr. Watson, which you can get further, and how you should deal with these outputs.

Let us first take a look at the tool first. This is a summary of the tools used in this lecture to tools. Performance Monitor - It plays a key role in the observation of NT system activities. We will also see some registry keys. The registry is the system database used by NT to configure itself, so it includes information that helps to understand where the program is run, from, and to map the service name to the image name. Next, we will explore the two process observation tools from the support kit ... for those who initially contact Windows 2000, the support kit does not exist in NT 4.0. There have been a limited subset of NT 4.0 Resource Toolkit, which is bundled with Service Pack 4.0 and is called Windows NT Resource Toolbox Support Tool, which has been named Windows 2000 Support Tool in Windows 2000 to eliminate it. Confused concept between it exists between it with resource tools. It is an integral part of each Windows NT and Windows 2000 sales versions. It exists in the support tool folder. It uses a suitable installer to install. It includes 40 to 50 tools integrated in the resource toolkit, but the toolkit is critical, indispensable to Windows 2000 users. I will use two tools from the resource kit. They are a molecule in more than 200 kinds of resources contained in the resource kit, and I will recommend it. If you haven't browsed the tools in the resource kit, these two tools are an important attachment for support tools. Through them, you will be able to inspect the NT system and understand its internal activity. The four tools listed next are from the Sysinternals.com website. You may have been very familiar with the site. It is called NT INTERNALS past. Here I will enter its homepage so that you see the face of the site. Sysinternals is a free software website, here there is a tool for free download. Most source code in these tools are also disclosed, which are designed to obtain information about NT through the support interface, and this information is often not accessible through standard Microsoft tools. Most NT administrators are very familiar with this, you will see the use of two tools during the lecture.

Then, let us start from the most basic level process with thread events, before the beginning, first define the terms. What is the difference between the process and the thread? The process is an instance of the execution program. For example, when you run a Notepad Program (NodePad), you create a process for accommodating the code that makes a NotePad.exe and its desired call. Each process in NT runs within its dedicated and protected address space. Therefore, if you run the two copies of the notepad, the data being used is independent of each other in their respective instances. A copy of the program will not be seen in a copy of the Notepad. I hereby elaborate with a sandbox as an example.

A process is better than a sandbox. Threads are like children in the sandbox. The children ran in the sandbox and might put the sand to other children's eyes, they will kick or tear each other. However, these sandboxs are slightly different lies in that each sandbox is completely closed by the walls and ceiling, regardless of how children in the boxes are hosted, they will not affect other children in other sandboxes. Therefore, each process is like a protected sandbox. No one can enter and exit without permission. This is the formation mechanism of the powerful memory protection model in NT, which is because of this mechanism, the NT is clearly distinguished from Windows 3.1, Windows 95, and Windows 98.

In Windows NT and Windows 2000, programs, program instances, or processes on other processes or memory space impacts. The only way to obtain private data or memory between two processes is to share memory blocks through the protocol. This is a collaborative strategy.

NT running thread. In other words, the thread is running and the process is not running. Each process contains a single thread, so when you run a notepad, generate the corresponding process sandbox to accommodate code and data, and a thread is created to start executing at the beginning of the main entrance pointing to Notepad. process. Once the thread is running, it can create additional threads, and a plurality of threads of a process are dispatched in parallel, which makes multi-thread programming very complex, and each thread shares the dedicated memory space in the process. Therefore, in the elaboration of this slide, the three threads shown in the process (all potential capabilities that have simultaneous operation) have equal access to dedicated data or address space in the process, so that three Threads must be synchronized with each other. So why do you have multiple threads? Why is the programmer chooses to split the program into multiple threads? There are two reasons: 1) it produces better response. Take Microsoft Word as an example. When you print file printing, you have selected the background printing method by default, and print processing will perform asynchronously while you continue to edit the document. How did this happen? Word has created a separate thread for print processing, and sets the priority of the print thread to the thread that handles the user's input, thereby providing the user with an illusion, that is, the application is specified by the application. The way the user responds to the user. However, you can't get in Win 98 and Windows 95, and the biggest benefit that Windows 2000 and Windows NT 4.0 is still in the multiprocessor system, and if there are multiple threads to run, these Threading facts will be able to run simultaneously on available processors. In other words, multithreaded applications can automatically run on a available processor, as long as: a) The application needs to run simultaneously; b) The priority of these threads supports the operation of the application. In other words, if there is a higher priority thread exists on another CPU ... Although your application has two threads that need to run, because of the other CPU, it is more important task, then, You can only run a thread at once.

Skills problem. Is it possible to add a second processor to run a single thread application faster? Let us imagine that you have a very simple computing intensive, single thread application. In addition to doing calculation work or calculating work. Add a processor to run the application faster? Ok, your first reaction is not, but the answer is affirmative, because NT also has several pieces of its own segment as threads. If most operating systems are the same, NT also has future internal management work. Therefore, the addition of the second processor means that when the main computational intensive application can continue to run without a short interrupt to perform the background operating system, such background, such background complex is still running. .

The above is a brief description of the processes and threads. When considering the planning of the sandbox, NT and Windows 2000 are a 32-bit operating system. If you think, you will know that 32 points mean 4GB. By default, NT divides the 4GB address space into two 2GB address space, one assigned to the user process, and the other is assigned to the operating system. In other words, each process provides a hypothesis that the process has a maximum of 2GB, and can load the code or data for virtual memory space. Of course, on a 128 megaby laptop, if you run 5 applications that extends itself to 2GB size, it is clear that a subset of these memory spaces is present in physical memory at any time. The above situations are transparent and executed in the background. This is a virtual memory everywhere. Like any operating system that uses virtual memory technology, Windows 2000 only introduces the memory space segments that are occupied by the process into physical memory according to their desired. Take Notepad as an example, when you run NotePad.exe, NT is not read in all the NOTEPAD.exe when the program starts. It will only be read in the executable program image clip referenced by the primary thread execution path. Similarly, the dynamic link library that is noteded by the Notepad is not read from the disk when it is called, and only when the subroutine in these dynamic link libraries is actually called, those that contain the desired reference code and exist. The dynamic link library segment on the disk will be read according to requirements. At the lower half of the screen, 2GB system sandbox is quite focused on NT without providing protection between operating components and drivers. I believe that many of you have experienced the blue screen phenomenon caused by the NT system management, and NT is often accused of these phenomena, in fact, this is from third-party device driver. The error in the program is caused, while the NT is subject to the above accusations because all of the NTs and all device drivers are in the same sandbox. However, each process runs in its own dedicated and protected sandbox, does not affect other processes, the same, these processes can not affect the operating system, the operating system and drivers are living in the same sandbox In, and, there is no protection mechanism between the driver and the operating system. Now, you may ask, this is why? The answer is performance. This is the system of the 32-bit operating system for each fact. There must be a lot of performance loss between the address space or operation, but it should be emphasized here that one of the reasons for this switching is to let all the driver when adding a driver. Returns and Windows file protection and extensions for Windows 2000 can avoid or restrict an accidental opportunity to add code to the system sandbox in the case of not fully verified and tested.

The operating system process does not exist. Below we will see a process called "system". But that is not an operating system. In these processes, some of the segments of the operating system are running, but there are also several processes that perform the background within the background. When a notepad opens a file, it produces a system call to open the file on the disk. This open disk file is generated in the context of the requested Notepad thread. In this sense, the operating system operates inside the Notepad process, and because the operating system is precisely a large subroutine that creates user threads such as opening files, reading files, assigning virtual memory, and creation processes Substant, so it is also running in every other process.

Windows 2000 adds new objects that allow multiple process clusters to be a job. A job consists of one or more processes that share the same set of quotas, restrictions, and other settings, and these settings are only available on the basis of processes one by one. For example, if you have a Batch Server system running on Windows 2000, and you want to limit the number of active processes in your job for a particular customer, this is possible - as an attribute of the job, an activity process Restrictions can be set; for example, you want to set up more than 50 megabytes of memory, here there is also a way to specify the maximum memory capacity available to the job, and the job will still include a number of full work segments. process. If you look at Windows 2000 Server and Windows 2000advanced Server, you may not notice the existence of the job object at all. This is because, unless you have created a job object and use a performance monitor to observe it, there will be no stuff on the user interface to indicate that the job object has been added to the system. Windows 2000 DataCenter Server will provide a tool called Process Control Manager, which will allow system administrators to create job objects, at the same time, specify the process to the job object and specify the limitations shown on this sheet slide. quota. The homework object can be described as a Basic Composition Element for Windows 2000 for the use of third-party applications. You can use the job object at firstlight, and the process control manager and data center will also take advantage of this kernel object.

Here, I want to mention one aspect of the job object - the scheduling level, it is very interesting for large-scale servers, although we are not talking about thread scheduling issues in Windows 2000, and interesting about job scheduling level attribute Things are it allows for controlling an important aspect of thread execution. To know, this cannot be set in Windows NT 4.0. The scheduling level is a number between 0 and 9. 5 is the default value. If the value is raised to 5 or more, the scheduling level will make the thread running longer during the turn to its run; This is the level scheduling, in other words, it can be said that a 20% CPU is occupied, while the other work takes 50% of the CPU. In Windows NT 4.0, this level scheduling is unresolved. Some people may think that "I can improve the priority of a process, and do this will provide more run time to the thread", however, this will give all run time to this process. Therefore, if you run two processes simultaneously, one of the priorities is higher than that, they all attempt to run, and the process with higher priority is basically taken up 100% CPU. This scheduling level property is now allowed to perform corresponding partitions based on the percentage of CPU time, and this is a very exciting ability to be brought by the job object.

Now, observing the work of the basic processes and thread information in NT is a bit headache, which is mainly due to the large amount of tools that can display different subsets on the same basic information (process list). Some tools also display threads existing in each process. Although numerous tools that can display process and thread lists are often references information from the same data source, each of these tools can also display unique information fragments that other tools cannot provide. Here, we will use two of them to demonstrate, these two tools meet the main needs of the observation process and thread information, but I should also explain that other tools also have the corresponding functions, just in this lecture. use. Another factor of another obstacle to understand "What is in operation" is the name of the image being running, for example, Notepad.exe may represent the name of the program being executed, but it may not mean being executed. The program name. In other words, the name of an executable file may not indicate which product is part of it, which directory is from which directory. Therefore, the system administrator observes the basic work of the process activity in the Windows 2000 system, which is the executable which corner from the disk. If you know which program folder exists, such as Microsoft Office, or existing in your Win NT System 32 directory, if you know what the folder is, then, you will be able to come from what components from this process. I know. Ok, there is a Visual Basic script called the PS in the Windows 2000 Resource Toolkit, which is a 90 VB Demonstration Samples of some new infrastructure in Windows 2000 . WMI allows you to access many information that cannot be accessed before Windows 2000, and more importantly, WMI allows access to information that can only be accessed locally within the network. Therefore, through the PS VBS script, you will be able to easily observe the list of processes on the remote system. There is also a VB script that can kill the process on a remote system. If you haven't seen this 90 scattered VB script examples in the Windows 2000 toolkit, I will recommend you to look at it.

But our primary problem is that whether in the workstation or on the server, if the process looks very slow, what is it running? For me, find out what is the fastest way to run, that is, call the task manager, turn it to the Process tab, and sort by the CPU consumption time clip. Before we do this, let's introduce the task manager as our first process browsing tool, although the task manager may be seen as a tool that is quite simple and clear, but the name of the tab and The information listed may still be clear. Therefore, let us call out the task manager mentioned in the slide.

There are three ways to start the task manager. I will use the fastest type, that is, the combination key Ctrl Shift ESC. I pressed Ctrl Shift Esc, and the default tab we see is the application tab. Now, if I ask you, this list is about what, how would you answer? No, this is not a list of applications; no, this is not a list of processes. In fact, it is a list of top-level visual windows with a very special format bit, in other words, this is a list list, but the window in the table is not all the windows in the system, nor all the visuals on the desktop. Window, but in general, it is a top-level and visible window list, you can see it by just clicking or pressing the Alt tab combination key on the taskbar.

Now, the window is owned by the thread, and the thread has the process, which is why there is a reason why the window is mapped to the process. If I click the right mouse button, transfer it to the process, it will bring me to the process tab of high brightness display, now I click on the mouse to be arrested (blue), showing the thread and ownership of the window. The process of threads. Here, we see mappings between windows and processes. Now, return to the Application Tab again. Since we are now known this is a list list, what does this status mean? Ok, the window is not running. Run means that the thread with the window is not running, and there is no response means that the thread with the window is running, it runs in the background. In other words, a running window is a window that is accepting a mouse, that is, a window input to the graphical user interface. The thread with the window is currently waiting, and you can click on the window. Therefore, the normal state of the window is an operational state. Take another time, run means that the thread with the window is waiting for you to click on the window. The window is not running.

Unsupplication is that the status indication you see when the window is hanging, or that this state is visually implied, and when you move the mouse over the window, the window will not mark the response. What do you see? An hourglass. Hourglass Simply means that the thread with the window is currently not accepted by the graphical user interface. It doesn't necessarily mean that the application is hang. The thread may be busy with other tasks, perhaps just waiting for IO on the disk or network, and will soon turn it back to the receiving window input. Therefore, when the thread is turned back to the normal state of the waiting graphical user interface, the unresponsive is sometimes only clearing the thread itself. Of course, if the application is really hanging, and the thread will not return to the window input status, then the window will display as no longer respond, you can click the end task, which will be issued to the thread with the window. A message is released to release the window. The end task option on the Application Tab does not turn off the process and does not turn off the window. It issues a friendly Mr. Thread message, ask if you want to release or close the window. This is the information it issued.

Let's perform a quick presentation of a final task by running a notepad, enter some unsaved text and try turning off the window. I will select the Notepad window in the Task Manager, press the end task and pay attention to what happened on the left. Notepad received a request for closing the window and refused, I would no longer repeat the above operation because you have not presented your changes. At the same time, the task manager has been impatient about the window you asked to close and release. In other words, the window you asked and closed is still there. So, the task manager said, hey, we can't end this program. Because the task manager is waiting for your response to return to the window and check the program click the cancellation status, it tries to close this window. If you choose to end the program immediately, you will lose all unsolded data. Pressing the current End button in a dangerous operation because this kills the process with threads, and the thread is already in an active state in the process of semi-cut. It has been updating files on disk, doing network IO, who knows? Therefore, when you choose to end now, it is necessary to care carefully, because the process whose thread with a window is released from the system without any remaining rooms.

Now let's take a look at the Process tab. The process here refers to a series of processes, as in the foregoing, is identified by the executable examples they run, which is why the first column in the Process Tab gives the mapping name. Please note that there is no process name column here. The process does not have mapping names independent of their home instance. In other words, if you run 5 Notepad to copy, you will see a process called NotePad.exe. How do they distinguish between each other? One way is through their process ID because each process has its own unique encoding. The process ID is generated by Windows NT or Windows 2000 and can be used. Therefore, the process ID will not be more and more, they can get cyclic utilization. The third column is the percentage of CPU time occupied by the thread in the process. It is not the number of the CPU, but is percentage of CPU time occupied by the process. In the current display, my system is basically free. Although the system looks only a small number of CPU times every second, the system idle process still consumes approximately 99% CPU time. We will see the phenomenon for a while.

The fourth column, the CPU time is the hour, minute, and second number of hours, minutes, and seconds of threads in the process of the CPU. Note that I use the thread in the process to use the word. This doesn't necessarily mean that the process consumed of the CPU time, because we will see it later, the NT timing method is that when a specific clock is excited, no matter who happens to be in the current thread, It will be calculated within the CPU cycle. Normally, in most NT systems, the clock operates at intervals of 10 milliseconds. Every 10 milliseconds of the heart beats. There are some driver code snippets run and display who is the current thread. Let us record the last 10 milliseconds of the CPU time on its account. Therefore, if a thread starts running, and after running 8 milliseconds, then the second thread starts running and lasts for 2 milliseconds. At this time, the clock is excited, please guess this whole 10 millisecond clock cycle to the end Which thread is on? The answer is the second thread. Therefore, there are some inherent inaccuracies in NT, and NT is in this way, and the actual situation is, for example, in most 32-bit operating systems, there is a spacing timing mechanism. Keep in mind, because, sometimes when you observe the sum of the CPU consumed by the thread, although the thread may seem to have run hundreds of thousands, but its CPU time occupies may be zero or very short. The phenomenon, then the above explanation is the reason. The above is the basic information column you can see in the Process Tab of the Task Manager.

Now, if you select a column in the View menu, this feature will allow you to add some additional columns such as IO counters, IO read and write, etc. This is the new feature of Windows 2000 and can be allowed to view IO activities in a process of processes. In NT 4.0, the IO counter is overwriting the full system and all disks. Tracking IO operations in a process of processes. This additional function is very important for understanding process activities, because now we can see which process that occurs on the system. I have added a thread counter that indicates the number of threads contained in the process; I also add a handle counter that represents the number of open objects. In the subsequent part of this lecture, we will also look back at the content of the handle.

Finally let us go to the Performance tab. The Performance tab displays the value of 13 of the NT kernel performance counters that can display by performance monitors. We once again see a small subset of the core system performance counter that usually use performance monitor tools, and some tags above may not be clear enough. For example, there is no relationship between memory usage columns and physical use. This is a completely dedicated and specified virtual memory in the system. We will not go deep into these details, just to make some projects in this display area may make you skilled before making decisions on system capacity restrictions. This is the task manager on the housing. It is a shortcut. Using this tool, you can find who the annoying process is on a slow system. Here, call the task manager again, press the CTRL SHIFT ESC key button, enter the Process tab, click the CPU consumption, and sort the output of the task manager according to the CPU utilization. Keep in mind that each time you call the task manager, it is sorted by the process ID, although the process ID is not a very useful sort order. Therefore, the task manager cannot save the settings after you call each time. If you want to sort by the percentage of CPU, you must click the CPU column. This is a shortcut to quickly find which or which process is consumer in the system. Now let us transfer to the process viewer utility, that is, PViewer.exe. This is one of the Windows 2000 support tools we have to run, which shows more details about the processes and threads needed to be in the test of the system process later. Now, we will start the process view tool by clicking Start Menu / Program / Windows 2000 Support Tools / Tool / Process Browser. The initial display area is a list of processes on a system. Note that there is a way to select a remote workstation or server name. Unlike the use of task manager, you can view the remote process list as long as you have access to your remote workstation or registry on the server. This is because the basic processes and thread information displayed by most tools are actually restored from the system to the NT performance record by executing the registry query. Now, according to what we know, the process seeing tools must use the reasons for performance records, based on the total score to view the first process in the list. That is not a real process, nor is it disclosed in the task manager list, but if you have used performance monitor, you will see that the performance counter that contains multiple instances (eg, process objects) has a name. The special internal construction example name of the scribe line is the total scribe of the scribe is a case where the selected and performance monitor is used to quickly summarize the counter value within all object instances. If you want to quickly summarize one or more counters of multiple objects, the process is read as a very convenient feature in the performance counter mechanism. PVIEWER's intelligence is not enough to show this. It is displayed in a process. But it is not a process. The first real process in the list is CMD. Now, please note that these alphabes sequential in the executable program file name are placed. The CMD is the first executable file name arranged in alphabetical order. Don't forget, the task manager is sorted according to the process ID. The task manager displays the process ID with a decimal number, while PViewer is displayed in a hexadecimal number after the mapping name.

There is a significant distinction between priority time and user time, which provides instructions for how long each process consumes in an application compared to inside the operating system. In the later part of the lecture, we will also look back to see the priority and user time comparison, but should remember that PViewer is to make you more closely pay more attention to the CPU time occupied by the process to master between applications and operating systems. One of the tools for time consumption. Now, when I click from the process to the process, and when the process list is scrolling, what happened in the bottom display area? That is the thread list. Because, if you have an impression on the description you made in front, you know that each process includes a set of threads. These threads are dedicated to each process. Obviously, the thread list in each process should be distinguished from the list of threads in the next process. If I select a thread and click on it, turn the thread list down, please note what changes have occurred at the bottom of the display area. The bottom side of the PViewer display area gives information including each thread including priority values ​​(between 1 to 30). The number of context switches is also the number of times NT selection running the thread. Now, there is a thread that looks a little special. It has been selected to run 58 times, but it only takes only 1% second CPU time. Do you remember this reason for this deviation? The thread is definitely not in the current state when the clock interval is excited at a 10 millisecond. Another example, the process 5 in the serving host seems to have run at all, but please see the number of contexts in the context - 76 times. The thread is selected for 76 times. It actually runs 76 times. But it is not in the current state when it is excited at clock intervals of 10 milliseconds. Therefore, if we go back to the process list, you can see that the total consumption of the total consumption of only 0.871 seconds, which obviously does not reflect the sum of the CPU time consumed by all threads during the process. Now, keep in mind that we will not lose the CPU cycle. NT does not lose the trajectory of the CPU cycle. It only measures the CPU occupancy time of each thread with an increment of 10 milliseconds, so the thread is sometimes misuse, but this error will be offset while the error will be offset without the real problem. This is the process viewing tool. Another explanation about the tool is that if you occasionally select a different computer name and press the connection button to view the remote system, a button will disappear. You will lose a part of the function, the button disappears is killing the process button. The reason for the disappearance of killing process is ... Do you still remember how PVIEWER is retrieved in the list of processes? It is through the registry. When I view the remote process list through the Registry, I can query the registry from the remote process and read the list of processes, but the registry is not a control mechanism. I can't kill a process through the registry. Therefore, if you want to kill the process on another machine, there are two tools to get. One is the Kill Process Script in the Windows 2000 Resource Toolkit --kill.bbs. It uses a new WMI (the Windows Management Specification) in Windows 2000 to access those remote process control operations, which cannot be used through the network. Another tool is a client server application called remote kill in the Resource Toolkit, which needs to install server-side programs on remote server systems you want to control. You can kill a process whenever Kill.BBS or remote killing customer server applications. Both tools are present in the Windows 2000 Resource Toolkit.

Now, we have used two tools to view the list of processes, and the list appears as a planar structure. There is no father and child relationship in the list, but in fact, when we transfer to the next slide, we will see which process is related to which process creates which process. In other words, who is your father? Who is my son? This hierarchy is displayed by a tool called TLIST through the Windows 2000 Support Toolkit. Now, TList represents a list of tasks, but it also shows a list of processes. In fact, this term does not necessarily mean everything in the NT core. I will call the command line and type TLIST / T in this way. TLIST is to generate a parent-child relationship showing where every process comes from, it is a father who is a father, who is a son by using a simple indentation format. However, TLIST can only be equally intelligent with the information recorded by NT. We return to the slide, it will notice that if the parent process is dead, TLIST will be left to the left. This is because NT only records the ID of the parent process. If your father is not in the world, you can't trace out who your grandfather is. When the TList finds that the parent process of a child is no longer run, the process will be left to the left, and this process is indicated by this process. Now, when you see a child process without a parent process, there is nothing to be rare. When you log out, all processes in your interactive session will be deleted. NT does not lose the sub-process at the same time due to the failure of the parent process. Let's see the output of TLIST / T, we will see that on my system, Explore.exe just is an orphan, it doesn't have a parent process, the reason is that when you log in to the network, the login process will run one. Explore program, and this intermediary program will exit when it completes the mission. Explore's all child processes represent all programs that I have started today. For example, I started from the Internet Explorer instance. I have run the command line. From the command line mode, I run PowerPoint and TLIST, and I am also generating a display area by running TLIST. Just showing the previous slide, we also run the process from the Start button to view the tool, and the start button is owned by Explorer. TLIST / T is an important diagnosis test tool, because by mastering the parent process of a process or observing the position in the system process hierarch (or tree) structure, you can quickly carry out the source of the process. classification. If this process is an Explorer's child process, the process must start running from the desktop graphical user interface. If this process is a child process for a system process, the process is inevitably a piece of NT. We will anativate all the processes in the system process tree in the next step. Therefore, we will go back to the upper part of the display area.

The new options in the Windows 2000 Task Manager are the end process tree. However, based on the Windows NT, the Windows NT, not to keep more information than the parent process ID, then what happens if you try to end the process task tree and from all the processes from the tree do not run, what happens? Will Task Manager discover all the sub-process from the same parent process? Let us conduct a quick demo. I will go to the command line, and start another command line mode as a child process from the command line by typing CMD. Now, we will run a brush (ie MS Paint) from the second process. In this way, we have a tree structure - a command line created another command line method, while another command line created a brush (ie MS Paint). Let's take a look at how the tree structure is displayed by performing TLIST / T. Here, we have seen the parent command line mode, the subsis line mode and the MS Paint as a grandson. What happened, first of all, if I quit this number of mediation command line of this number 712, what will happen? Ok, let's go to the intermediary command line and type exit, what will it be left? The brush still exists. Therefore, when the parent process exits, the child process does not exit. This has an interesting issue. If we now call the task manager by pressing the CTRL SHIFT ESC Combination button, go to the Application tab, select the first command line method, click the right mouse button, transfer to the process, and then find the process with the window, This is the instance of the command line method --cmb.exe, is the process of having the first window. Now, if I am right-click on the process tree, will Windows 2000 discover a brush? Keep in mind that the brush is the grandson of the command line. Let's try it, click the process tree. Task Manager warns me that termination of a process may cause data loss - this is because there is no chance to clear the thread. So I will do it, click Yes. The brush is still running. why? Explain again, this is because NT only retains the trace of creating a process, but does not keep the trace of grandfather or grandson. So, keep in mind that you are using the new end process tree option. Now let's take a look at another important information fragment in the process activity, which file is opened. Windows 2000 or Windows NT does not come with the corresponding tool to implement the above functions, however, this is indeed a very important diagnosis task, because if you encounter a file lock error, the file is definitely by a local workstation. Or open a process on the server. Without the tool mentioned on this slide, you can't find anyone who opened the file.

Another important aspect of opening a file is reflected in the case where the application contains unable to turn off file errors. It performs its own manifest as a system memory leak, because each open file takes a part of the system memory. Therefore, on the system where the application continues to open the object without turning off their systems, NT will exhaust system resources due to these applications that do not turn off handles.

First, let's take a look at how the task manager quickly views the number of handles opened by the process. I pressed the Ctrl Shift ESC combination key to call the task manager. Just, when we watch the settings, I have added a list to display the total number of handles opened by each process, and I will move the mouse immediately. Go to this column. If I click on the hip of the handle, the task manager will sort the process in the magnitude of the number of open handles. Here, we saw a process called ServiceHost.exe, with 760 open handles, we will look at it later. If you have an application that doesn't close your handle, this is the number you see. And this column should also be checked. You can also view the value of this data on the entire system, because, in the Performance tab, the total number of handles, total number of threads and total processes are included under the Performance tab. If you hang a handle, you should check the total number of handles. If the number is slow up slowly, you should go to the process tab to select the handle column, and you will be sorted by opening the number of handles, so you will be able to quickly identify those processes that do not close the handle. When you end a process, all the handles in the process should be turned off, and the system resources they occupy will also be returned. This is an aspect of the viewing handle information. Another aspect is to make this handle which object is opened. In other words, what is the 760 handles? They are representative documents, network objects, registry keys, threads and processes, or something else? This issue will introduce us on two tools that enable us to open a handle table in a process.

The first is the OH tool. OH represents an open handle, which is a tool in the Windows 2000 Resource Toolkit. For ensuring OH work, the OH tool must set a special internal sign in the registry read when the system reboots, so you need to reboot the system when you first use the tool for the first time. This special marker enables NT retention to open handle information than usual. Run OH in all NT systems and open settings, not what is not significant, and thus does not cause serious consequences, but these jobs are not set to default. Therefore, when you first run OH, you will get an error message or some prompts that you have set a special sign and you should re-boot the system. Ok, given the above work on the laptop, let us enter the command line. We will call up a command line. First, I will type OH /? And to see the option. OH has two options. In the first option, you can specify the process ID you are interested in. In other words, I will display the handle that is opened by the process of Issue 43. The second option is to view a specific type of open handle. For example, a file may be an open file, a registry key, a thread that is opened by a thread, and the like. The last option I will emphasize is to find a handle that is opened by an object with a specific name. We will give an example to figure out the problem. If I want to find the handle for the PowerPoint (PPT) file, I should enter oh -t file, meaning only the handle of the file object, that is, the handle names that include the .ppt extension existing in the object name. What is the answer? It is PowerPoint. Here with the open handle for the PowerPoint file, the PowerPoint file here also contains the presentation we are running - TQ400-02.PPT. If you encounter a file lock error, then this is to find a shortcut method for opening a processor process related to the file. However, if you look at the output, it will find that some of the critical file information is not displayed by OH. What did you miss before the file name? It is the drive name. This takes us to the second tool shown on the slide - The tool is a graphical user interface tool, and its command line version is NT Handle. This is the first tool we have run from the Sys Internals website. It is a free software. Please record a little, the tool is like most tools from sysinternals.com, as well as the use of the device driver. When you run Handle.exe for the first time, a driver will be loaded in the system. As we mentioned earlier, like other drivers and Windows NT systems, the device driver also share the same memory space (or called Sandbox), this means that if there is an error in the driver, it will have the possibility of crash. This is reality for any device driver. Handle.exe Reasons for Using the Device Driver is that the tool bypasses the NT security mechanism to retrieve the full name of the open file from the process handle list, and this touches the unable access from the general Windows application. information. Let's take a look at the Handle.exe tool. This is a graphical user interface version. When it starts, a list of processes in the system is displayed. When I choose a process, for example, I scroll down the list and select PowerPoint, and Handle.exe will display the handle form opened by the process. Now, the tool is sorted by handle numbers, which is not very important information. I will re-sort the table according to the handle type. Now, I clicked the type column, so we immediately saw the list of open files and saw the full path name of the PowerPoint file included in the current presentation. Here, the magnetic disk C: is added to the path name.

It can be seen that Handle.exe is another way to view open handles. This tool does not need to reboot the system like an OH tool to enable the set special flag to take effect. The negative aspect is, it needs to use the device driver and will thus cause conventional restrictions and warning information to call the driver code to appear on your system. Only for personal concern, I have never encountered the process of crash, but the tool indeed transferred the authorized system code into the operating system sandbox. Another way to use Handle EXE to view handle information is to perform a search. If I click the Search Discovery menu item or press the F3 button directly, I will be able to enter an incomplete file name (for example, .ppt) in the dialog that appears, then click the search button, Handle Exe will All handles include the .ppt extension for search. So, I found a process of opening a PowerPoint file again. This is another way to view the open handle.

Another class is called by those who brought troubles from the Windows system administrator to the dynamic link library. Dynamic link library conflicts have become the scourge of many system administrators. This problem is made by Windows installer adaptive application support and Windows file protection feature in Windows 2000. Windows Installer Adaptive Application Support and Windows File Protection Features Automatic Recovering or Error Replacing System Dynamics Link library. Therefore, dynamic link libraries conflicts and replacement issues will be overall in Windows 2000, but it is very important to view the process and find out the dynamic link library that they call and their disk is still very important for us.

Before observing a living process, let us see the static view. In other words, specify an executable file, tell me what dynamic link library (DLL) when it is running, in order to observe this, we will use a tool called dependency browser (Dependency Walker) . This tool is included in the Windows 2000 Resource Toolkit, I will start it by starting / run / depends. After the Dependency Walker window appears, I can now open an executable or an executable image. I will click Open the file menu item and as an example I will choose the Notepad program. Now, the default folder used by Dependency Walker is WIN NT System 32 folder, most of Windows 2000 and Windows NT 4 will be saved here. Therefore, we have positioned in the correct directory of opening the NOTEPAD.EXE file. Select NotePad and click Open. Now I have not created any processes, all I have done just open the NotePad.exe file. At this point, Dependency Walker already lists the image name list of the dynamic link library linked to the Notepad program. In other words, the eight dynamic link libraries are libraries that contain support routines when the Notepad is run. Keep in mind that they are not a complete list of all dynamic link libraries that will be used when the program is running, but only the list of dynamic link libraries that will be loaded when the program starts, because the dynamic link library can run in the program Dynamically loaded. So this is a very interesting display, it doesn't really tell us what will be used, because when the dynamic link library is loaded, it will generate an exact collection of use, and it does not show the location of the DLL file on disk. . First look for the corresponding DLL file in the directory where the executable is located. Secondly, the current directory will be used. Finally, use the environment variable of the search path, and if a dynamic link library is known, it will be overwritten because it has been opened when the system is started. Although this is a meaningful display, when the process is actually run, a more meaningful output will show me where the dynamic link library is loaded. This will bring us the next topic: observe the use of dynamic link libraries in actual situation.

If you encounter a dynamic link library conflict or due to the loading of a dynamic link library of a dynamic link library, if you don't know how to capture the process or want to observe the process before the activation process is to find the dynamic link library is loaded The full path, then this part may be able to help you diagnose dynamic link library conflicts. Now, Dependency Walker in Windows 2000 has a new option to briefly describe a process. This option means detects and tracks the loading of dynamic link libraries by actually creating an instance of a process or executable program. So I will go back to the Dependency Walker and click the Profile launch profile. I will choose the default setting. When I click OK button, the Dependency Walker creates a test process to run the notepad program and track and monitor all dynamic link libraries in the display area lower window. Let us do it. There is now a notepad. If I returned to Dependency Walker and observed the lower part of the display area, it will find a small part of the log record for the summary. Here is a list records the dynamic link library that is loaded when the process starts. Similarly, it did not tell us the full file name you will see in the tool described in the next introduction, but at least we can see the loaded dynamic link library. Now, if I returned to Notepad and try to open a file, when the standard open file dialog is turned on, 10 to 20 additional dynamic link libraries can be observed in the background. Let us do it. Can you see it in the background? Let's go back to Dependency Walker, if scrolling up, it will find the result as the display standard to open the file dialog, there are many dynamic link libraries that have not been loaded before have been added to the process. If we return to the dynamic link library list, it will find that the number of dynamic link libraries has increased much on 8 basis. I can also observe the list of loaded dynamic link library from the middle of the display area, let us count the number of adds - 31 dynamic link libraries in order to display the standard opening file dialog, but still not see complete path. This will be brought into the next tool - TLIST used in front, but this time we will use a parameter that is not described in front to specify a specific process name.

In the next presentation, we will use the TLIST tool to display the dynamic link library list in the process and view the information it displayed. Switch to a state of running command lines, TLIST, and PowerPoint, and view dynamic link libraries that are loaded by the PowerPoint process, where the memory address of these dynamic link libraries is located in the process address segment. We really have some useful information, but what data is missing? Yes, it is the full path name of the dynamic link library. On this slide, it will eventually show us a full path name, which is the second tool List DLL we have obtained from the sysinternals.com website. The List DLL tool can display the full path to each dynamic link library, and it will also display the full path to the running executor. This is another important aspect of analyzing the content of the NT system. As we mentioned earlier, the name of an executable may not always make you understand its role, but if you know the directory where the file is located, at least it may quickly know which package is the file. Part. Therefore, we use the List DLL tool more than just to view the details of the dynamic link library, but more importantly, it should keep in mind that it is a shortcut to view an executable full path.

We will return to the command line, now let us try the List DLL tool from our demonstration directory, we will continue to use the previous notepad, that is, the process we started from the Dependency Walker. Now if you look at the path name in the table, we can get the full path name, including the drive symbol, directory name, and file name, which is the purpose of trying to achieve in this example. Let us do this for Power Point.

Similarly, this also shows the importance of obtaining executables and the full path of the dynamic link library when making basic process error handling or analysis in Windows 2000. Another angle of the system and process activity is an IO operation. Typically, the main load on a server system derived from the network between the server application or IO activity for the disk. Therefore, when the system looks very busy and the disk is constantly rotating and vibrating, how can you determine which file is for the IO operation and which process is generated? In other words, how can we track the IO activity on a busy system? What process, file name or file work? Ok, in NT 4, it is as mentioned earlier, there is no method that can be independent of IO activity based on each process. However, in Windows 2000, some new counters are added to allow you to observe individual IO activities based on each process. Therefore, in our first demo, you will use a performance monitor to see these new counters so as to quickly learn how to determine which or which processes in the Windows 2000 system are generating IO operations.

We will switch to the command line status and start the performance monitor by command Perfmon. Click to join the tag or add the counter button, because we only interested the process-level counter, so select the process object, scroll down the list of newly added IO counters - the number of IO data bytes per second and the IO data operation per second Quantity.

The number of IO data operations per second is the total number of read and / or write combination operations. Although there is a counter for recording the read operation and write operation, here, for this level of analysis, we only care about the IO operation without reading or writing. Now we have the number of IO data operations per second. In addition, by pressing the CTRL button, select the number of other IO operations per second. Other IO operations represents those IO operations that do not perform data read and write. For example, open a file or read a file attribute such as a file size. If you want to see all IO operations generated by a process - including data operations and other IO operations, the above two counters must be selected. Next, we have to insert the selected counter into which process? The answer is all processes. So click the first process in the instance list box. Keep in mind that _total option is not a process. Press and hold the mouse and drag to the bottom of the list box to select all the processes, press the Add button, follow the application or close the button.

Now we are observing the IO operation generated by each process in the system through the display area of ​​the performance monitor. There are two fold lines for each process. Other operations. Soon, the system calm down like this. Now let's return to the command line status and launch some activities that will lead to many operations. Let's take a look at the operation involving all directories on the hard disk - DIR C: / S. This will mean generating a list of directory all subdirectory on the C discharge from the C drive. As we see, in order to display the required data being executed, many directory read operations are being performed. During this operation, let's go back to the performance monitor and see the lines of the display content as seen as someone is performing a large number of IO operations. Ok, now consider how to determine the process of actually mapping this representative of a large number of IO operations.

Let us open the highlight display. Click the highlight button or use the shortcut Ctrl-H. If you have previously used the performance monitor, you must know that when you open the bright function, when scrolling the counter on the list of the lower arrow on the keyboard, the process or line selected in the list box will be highlighted as white. Therefore, I will scroll down the counter until the fold line currently at the top becomes white. That's it. Can you see the instance name displayed at the bottom? It is CMD. Therefore, the process CMD is the process that generates all of these IO operations. This is easy to understand because CMD is here. It is the command line window and it is the IO operation involving the directory. You can see how fast, use the Performance Monitor to monitor the IO operation per second and which processes are responsible for when the IO operation per second and quickly locates. Ok, this is very interesting, but it also has a problem, that is, where is the go of IO operations? The content just introduced only told our IO operation. It will bring us the next tool on the slide - file monitor. File Mon is the third tool we use so far we used to stems from the Sysinternals.com website. Like the tool we have used earlier, it involves the use of a device driver. When we run the file monitor, what it does is to load a file system driver that can take each IO operation in the system, display each IO operation on the screen, then send it to the corresponding device driver. program. Therefore, it has largely reduced the speed of the IO operation, but it does provide an effective way to determine the source of the IO operation, because each IO operation will be recorded by it, the recorded information includes the process name , The referenced file name and the type of operation - read or some. Let us take a look at it in specific ways.

Back to the command line status, run the file monitor from the demo command via the filemon command. The file monitor now launches the monitoring activity of the file. Although it seems that some IO operations are running in the background, the system is still calm down, in fact, there is a system process in this special Windows 2000 system, which performs some IO operations of accessing the database every 1 or 2 seconds. Now let's return to the command line status and try to imitate some heavy IO activities for a particular file. This particular objective file is a big file that each Windows 2000 system has a driver compressed package file.

This driver compression package file contains a compressed version of all device drivers issued with Windows 2000. It is stored in the Win NT Driver Cache folder. I will launch the Window NT Explorer and enter the file in my WIN NT DRIVER Acche folder to make a simple copy of this file. I open the C drive, expand the Winnt directory, then expand the driver cache directory and the i386 directory, where the driver.cab file is stored. Please note that its size is 51 megabytes. So it will be an ideal test object. I will only make a simple file copy by the copy command and the paste command in the editing menu. You can see that we are now copying a 51 megabyte file.

Let's go back to the file monitor and observe its display content. Ok, like we have seen in the output area, we can observe a lot of IO operations to the Driver.cab file and its backup. I use shortcuts Ctrl-e to terminate the monitoring activity of the file monitor, and we can see some read and write operations - read operations from the DRiver.cab file and write a copy of its same name. Now let's return and cancel the file copy, you will see an example of using the file monitor to observe the independent IO operation and allow you to see which file in which the IO operation occurs in.

You can do some filtering work with a file monitor. For example, if you use only IO operations in a C or D drive or these drives in a special directory, you can filter your specific path, you can also highlight a specified path name so that you can Easily find all special documents you are interested in all monitored files. This is again verified that the file monitor is an important tool for observing the IO activity and the tracking IO operation. The last point of this part is that the file monitor can indicate the paging IO operation by adding a small asterisk in a row. Since the Windows 2000 Cache Manager uses the usual paging mechanism and memory manager to complete the file IO operation, you can see the paging activity that happens in the file opened by the application. In other words, since the cache subsystem reads data from the file using the usual paging mechanism, the IO operation is displayed in the file monitor in the file monitor using the usual paging mechanism.

The last area of ​​the file or system process activity is also the same as that require the content that can be monitored is registration activities. For example, most of you know, the registry is NT to configure itself, the driver that needs to be loaded, all management settings, and the settings of each user file are stored here. Sometimes, for a system administrator, you know where a particular setting is stored in the registry is very helpful. There is a tool called a registry monitor on the sysinternals.com website to monitor every read and / or write to the registry. Let's run the registry monitor. I will return to the command line status and run a copy of the registry monitor from the Sysinternals.com website from the demosted directory. When the Registry Monitor is launched, it will load a driver to start intercepting the query for the registry. At this moment, the MMC process as a performance monitor container is also conducting some registry queries. Therefore, let's return and close the performance monitor to stop these queries. Ok, now the system calm down. The registry is usually calm. In other words, if a process is performing a registered or write operation, an error occurs, and you may consider organizing a wrong report. When the process or NT starts, the registry will be queried. It is not a database that will be accessed. Using the Registry Monitor can be inspired when looking for a particular system settings in the registry storage location. For example, if you enter the Control Panel after starting the Registry Monitor, access some setup programs or tabs, you will be able to see the precise tracking information in the registry in the registry in the control panel, and it It is possible to guide some deeper research on the registry, so as a aid for the Windows 2000 Resource Kit Help file (this file records the vast number of registry keys). This is the registry monitor utility. Next, two questions will be mentioned.

What is running in NT? What is the scheduled unit? The answer is thread. Remember, the process does not run, threads can run. Each process contains at least one thread.

How do threads have a lot running much, but does not occupy the CPU time? A thread has a lot of content that is unrelated to context, which makes threads can be run by NT, but it is rarely occupied or does not occupy the CPU time. The answer is: NT uses a spacing-based clock timer mechanism to calculate the CPU time. If the clock is excited, the thread that has been running is no longer running, which will not take up the clock cycle. As the default clock interval, every 10 milliseconds - although the default values ​​of different systems are different, it will be considered to occupy this 10 millisecond cycle regardless of the current thread. If no thread is running, it will be used as an idle thread. The idle thread is part of the system idle process displayed in the task manager. Let us recall, the first process listed in the List of Process Tab is the idle process. The role of this process is to accumulate and occupy all CPU clock cycles when there is no thread run.

last question. What is the size of the process address space? NT is a 32-bit operating system, and 32-bit corresponds to 4GB. By default, NT points half of the address space to the user process and leaves the other half of the 4GB to yourself. We have spent some time to observe internal processes and IO activities inside these processes, dynamic link library usage, open handles, registry activities. In the following section, we will understand how NT is distinguished how the operating system works, and the CPU time occupied by the application, and how NT maintains and calculates interrupt time. The interruption is a very important topic because it does not take up any thread, so it is not displayed in any process. In other words, a system with heavy interrupt loads can look very slow, but it seems that there is no process is running. We will answer this question in this section.

Now, I suggest that we are best going to discuss the time of spending time and spending the time in the application code itself. NT uses two memory protected states, which are sometimes referred to as core states and user states, or in additional occasions, called privileges and user states. Each page in a process 4GB address space is marked in a pages it is in a core state. The page in all system address spaces is marked as the core page. The page in all user address spaces is marked by the user page. The only way to access the page tagged as the core page is to run in the core state and only the operating system and device driver can run in the core state. In other words, a user program will not be able to run in the core state unless the device driver is loaded. This is the solid level of memory protection provided between applications and operating systems. No matter how the run is run, no matter what the memory address is tried to reference and change, it will never destroy the system data structure, because all operating systems and device driver memory structures are marked as core pages. . They are in the system address space, because the application runs in a user state, it is impossible to see or modify the data.

Threads are often switched between user states and core states. Each time a system call is performed, for example, open a file, turn off a file, read data, write data, which changes from the user-state application code into a core state or operating system code. When the 10 millisecond clock interval is excited again, how will NT decide how to take up the CPU time? If the thread is in the core state or is running part of the operating system, it will increase the privilege time counter value for the thread. However, if the thread is running inside the user or application, it will make the thread occupy user time. Therefore, NT is accurately tracking a thread cost in the application and spending the amount of time in the operating system. Observing the CPU Time Leader in the Task Manager Process tab, it does not distinguish between privilege time and user time, but only all CPU time, but some tools allow us to observe the application and quickly calculate this application separately. How much time spent in the program itself and the operating system. It brings us the next demonstration: use the QSLICE or Quick Slice tool to detect the process CPU time.

Let's run Quick Slice by starting / running / QSLice. It is included in the Windows 2000 Support Tool. The CPU activity of the process is displayed in the Quick Slice, where red indicates the core state, the blue indication is a user state. Please note what happened in my system now? Quick Slice is called 100% of the No. 0 process in the system process is at a core state, but the No. 0 process in Task Manager is called a system free process. You can see a quirks in the NT Process Display tool, for idle processes, each tool creates their own name and is inconsistent. The idle process is NT for the counterfeit process for statistical idle CPU cycles, and these CPU cycles are counted as core state time.

Let's run a program to simulate a usual user application. This is a program called CPUSTRESS, which is included in the resource toolkit. I will run the program by starting / run / cpustress. When it starts to run, it is default, it will have a thread running on a low level. The low activity level means that it has 25% of the time in operation and the other 75% of the time is waiting. When the CPUSTRESS program at the bottom is often suddenly appearing and runs a short period of time in the user state - the manifestation is a blue strip map, and then reforms. Let us turn its level of activity to the largest. Click the active list box to scroll down and select the maximum. Please pay attention to what happened now. It turned 100% blue. The maximum activity level causes CPUSSS to fall into an infinite loop. There is only one process here, so it is basically in the application. No system call is generated. If I see a set of separate blue and red, this program is in a usual situation, that is, some time spent in the application, some time spent in the operating system. Similarly, using QSLICE can also be considerably easily observed.

Process and quickly determine how the process is consumed - is it in a user-state application or within a core state operating system.

Based on one of the following three reasons, NT will run the operating system code in a core state or privilege. We will only describe the first case, that is, the user application issues a system call request - such as open a file, close A file is released to allocate memory, release memory, create a process, create a thread, and so on. We will also introduce the second case and introduce the third case in the next section.

In other words, the second reason for NT spent time is due to interrupt call users cannot continue to run. Interrupt call is caused by the user application to issue IO requests. In the next few slides, we will see some technical details, and it seems that only the writer of the NT device driver will be interested in these content, which prompted us to go deep into this level of detail because NT calculation interrupt call time The way, two separate counters in the Performance Monitor - a counter for statistical interrupt call time and another counter called DPC time percentage - can display interrupt call times. So, what is DPC? In order to understand these two counters, we first we need to understand DPC. Let us first see what will happen when an interrupt call is generated. When the interrupt call is generated, the running thread will be interrupted in turn. A NT system code will be run so as to find a driver with this interrupt source, and call the driver, the driver completes the work that needs to be completed, release the interrupt and returns to the thread being executed. Only as one side, since the interrupt is not related to the context, the NT is considered perfect in terms of the general operating system and the processing interrupt call. NT does not switch to some special interrupt processing threads. It only saves the status of the current running thread and calls the driver to complete the work, and then the interrupt is released, and the interrupted thread returns to the run state. Since interrupt calls may be derived from many different interrupt sources, a mechanism must be used to implement interrupt priority submitting, which is why two different counters-interrupt call times and DPC time-monitor interrupt. NT uses 32 related priorities to achieve interrupt priority submitting and service. It is one that you will never see in the user program, and you will never see it in the Performance Monitor. It is called interrupt request priority or IRQL.

When a driver is loaded, it tells NT your own interrupt source and IRQL. please consider it. In other words, there is a related priority. Therefore, when an interrupt is generated, the NT must look at the IRQL of the interrupt source. If its value is higher than the priority where the program is now running, then the interrupt will be served. If its value is lower than or equal to the priority of the program being running now, the process of the interrupt will be delayed to the high priority interrupt source to complete the work. What will be blocked when an interrupt is generated? What work will not happen during the driver processing interrupt? The answer is: Other interrupts with the same or lower priority and all threads are performed. In other words, since the interrupt call always interrupts the process activity regardless of its process or thread priority, all process activities in the system will be suspended. In order to make the time with high priority drivers to minimize, NT provides such a method: the driver seems to be said, I have done a job that should be made under this interrupt priority, but I am more Many work should be done. Now I will release the interrupt, but please call me again later so that I can do my unable to do it under high priority. This operation is referred to as a delay assignment (DPC). Delay allocation call is a method that the driver request NT calls it again later. There is a system queue or list for recording the driver callback request. When is the callback? When there is no higher priority interrupt call to be submitted. Look at the last slide and pay attention to where the DPC (delay allocation call) falls into the priority pedigree? They fall into priority 2, which is lower than the hardware device interrupt but higher than the regular thread execution. A simple way is to treat interrupt calls as two phases: The first phase is at the interrupt level, and the second phase is in the DPC level. In Performance Monitor, DPC and Interrupt Call Time These two counters are in front of you, because they are in the processor's default CPU time counter, this is why we explain the details of the interruption process, from this, you The interrupt call time and the content represented by the DPC time can be more clearly understood. The interrupt call time reflects the first phase of the interrupt process. The DPC time reflects the second phase of the interrupt process. Now let's make a demonstration and observe interrupt activities in performance monitors.

Start performance monitor. Let us add interrupt call times and DPC times to the display area by clicking the Add button. The counter we just described in the display area has appeared. Click Add. Click Close. Since the default scale range of performance monitors is 0 to 100, only some fairly small numbers are displayed. I will open the Properties dialog box by clicking the mouse button, and switch to the chart tab, the maximum value of the vertically display is reduced from 10 to 10 for easy reading of the value. Let us do, now we are observing interrupts through DPC activities. The red line represents the DPC time, and the green line represents the interrupt time. If we come back and forth back to move the mouse, do you notice that the green line suddenly jumps? It is formed by an interrupt generated by the mobile mouse. Now, DPC time seems to occur in regularity per second, which is definitely the result of certain IO operations. If you see this continuous occurrence of this continuous DPC operation, we should return to the previous content. Our next step is to find out who is executing IO operation. Do you remember the tool to complete this work? It is a file monitor. The file monitor will tell us which process will result in the IO operation of the DPC later. The focus of remember when observing the interrupt call time activity is that it will not take up any threads or processes, which will lead to a quick question and answer from our section.

If the system looks very slow, but did not see the process is running in the task manager, what is happening? It must be an interrupt call. Use Performance Monitor to see the number of interrupts per second and the percentage of DPC per second or interrupt call time percentage and DPC time percentage. Again again, the time consumed in the interrupt call does not take up the thread, so there is no process in operation. Please observe the interrupt call time.

I said that we will return to the head to identify every process created by NT and run in the system. Why is this important? Because if some context is running and not by you, it must be part of NT - some system processes. Therefore, it is possible to identify that all system processes are another important composition of troubleshooting or performance analysis in Windows 2000 and Windows NT 4.0 systems. Now, we use the TLIST / T that the system process tree will be introduced in front. Similarly, TLIST / T will display hierarchies between processes. Therefore, use this tool, we can quickly browse the process sources and processes in the tree in the tree. As a review of that section, I will return to the command line, perform TLIST / T, and refer to these content when reviewing the slide. Observe the output of TLIST / T, the first two processes in the system are exactly what we will describe - their process ID is 0 and 8.0. In multiprocessor systems, this process that does not run the actual program will allocate a thread for each CPU. In other words, the idle time of each CPU will be calculated separately. By the way, this is also a rapid and simple way to check the second, third, fourth and five CPU usage efficiency in your system. By observing the idle time of each CPU, you can determine the uniformity of the load distribution in your multiprocessor server or workstation. The idle process is not displayed as run. Keep in mind that in Quick Slice and Task Manager, the idle process looks in operation because when the clock is excited, there is no thread is running, so the clock is occupied by the idle thread of the CPU. Therefore, it looks like running, but in fact, the system is in an idle state.

The second process -8 process (the process ID in NT 4.0 is 2) is a special type thread family called a core state system thread. This system process called the system, includes a subroutine example of the operating system and some devices that need to be partially partially running in the actual thread in two versions of the NT system. In other words, they need to perform concurrently with other system activities. Some examples can help understand this concept.

Several portions in the operating system need to run in the background - such as a swap program - running a system thread. When NT thinks that a process that is not running in a period of time, if other processes request physical memory, it will mark the memory space of the process as cleared. So, who is to complete the work of the process out of memory? It is exchanging program. The switch is a thread running with other threads running in the system. The file server is a driver for creating a system thread. This is an interesting example. On the load-bearing file server, the process of manifesting as a run status as the result of the client IO activity is not a process of a server because the file server itself is not a process. To know, the driver creates and uses system threads to provide servo and request service for remote network IO. Therefore, this is a very important monitoring point, where the load-bearing file server will make the system thread to continue, but because the system thread is mainly disclosed in the process called the system, we need some ways to inverse And closely pay attention to the system process, so that what thread is running. Based on what we have already told, if you tell your system process is running, what do you know? Basically, you can't know anything. You only know that one of the NT (perhaps a driver) is running, but you don't know which piece it is.

This brings us to the next presentation: Understanding which thread in the system process is running, and thus know which driver or clip in NT creates the thread. This is a messy process, because it requires three tools: performance monitor, process browser, and NT 4.0 Resource Toolkit a tool called PSTAT, this tool does not only exist in Windows 2000 resources. In the toolkit, it is also an integral part of the Platform SDK (i.e., platform software development kits) and is published with MSDN (Microsoft Development Network) and its subsequent versions. It is also an integral part of this lecture demo file. What we must do first is to use the Performance Monitor to find threads running in the system process. Next, we will use PViewer to give them a number of threads we are interested in and find the memory start address, the memory start address is a number that represents the system thread from the system sandbox. Finally, we will use PSTAT, which provides a memory map of the system sandbox and positions in which driver runs in the thread, in other words, the code snippet running in the thread belongs to which driver. Therefore, the process has been more complicated. After all, it has used 3 tools, but let us take this demonstration to see how it works.

First, we will return to the performance monitor. Let us start from a new chart. In fact, since we have changed chart settings, we will start a new performance monitor instance. I will click the plus sign and add the CPU time of the thread in the system process to the chart. I am transferred to thread objects, select the processor time percentage, scroll down to the process called the system, click the first thread - thread 0, drag the mouse, roll down until all the threads in all system processes are all Select, then click Add. Now, I have not been able to wish, because there is still another process in Windows 2000, which also contains some system threads, which is the CSR Access - a Windows subsystem process. This process is a NT fragment containing part of the Windows system. In NT 4.0, all system threads are present in the system process. In Windows 2000, some system threads exist in the CSR access process, while others are present in the process called system. Let's click Add, then click Close.

I now look at the implementation of more than 30 scattered system threads. Let us move the mouse quickly, you can see something that has been running. How do I find thread random memory arrangements in this list consisting of more than 30 zeroats? I will open the highlight switch, click the high brightness button, scroll down the screen until the counter moves with the mouse is also highlighted in white. There is a green raised in the middle of the display area. Just there, have you seen it? It is the one from green to white. When I move my mouse, I've looks running on the 6th line of the CSR access. The second step is to use PViewer that exists in the Support Toolkit, click Start / Program / Windows 2000 Support Tools / Tool Process Browser. Select the CSR access, scroll down and select the line 6 thread, the information we are looking for is the starting address of the thread, which is located at the bottom of the PViewer display area. This address is the starting point of the thread start execution. It shows hexadecimal, 0x represents A000-9CBF in hexadecimal. Ok, we have a memory address. What are you doing next? Step 3 - Run PSTAT, the tool exists in our presentation and executing the PSTAT tail. Therefore, please ignore all details from the thread. The last part of the PSTAT display area is the memory mapping of the system sandbox. It lists the names of each driver and addresses in system memory. If I let it reach the end and look forward, I will look for the driver that started at the thread run address. Unfortunately, PSTAT does not display the end address of the driver, and only the start address is provided. Therefore, it is necessary to pay close attention to which driver we are looking at. The example we currently raised is very simple, because only one driver is called at A00. If you view the entire list, any other event has a number with F, 8 or B headers. Therefore, I will immediately determine that the thread device is definitely a code snippet in the driver Win32k.sys. It is a component of the Win32 graphics and window operating system. This is a bit meant. When you move your mouse, you will expect a piece of window in the window operating system to run to indicate which window you are moving on the mouse. Although this is just a person as an example, but it demonstrates the three tools (performance monitor, PViewer and PSTAT) to deliberate system processes or CSR access and find out the drivers for creating threads. This is a very important trick, because if the system process runs on Windows 2000, you will not be able to make any judgment on the current situation without finding which driver or system clip is not found. If the thread start addresses fall within the operating system image (NTOSS (?) Kernel.exe, the problem may be somewhat complicated. So, what do you know? You can't know anything. For example, let's take a look at the PSTAT output. The most upstanding device driver - it is not a real driver, but only the operating system itself - is called at 80400000. If I return to PViewer and select a system process - please pay attention, not the CSR access, but the system, then several threads in the process are started near the address 804. So, I click on the system, please note that when I scroll down the first set of threads, the starting address of the most thread is near 804. So, what is it telling us? It tells us that the thread is a fragment of NT, but it is not specified which fragment is NT, but some can be affirmed, the thread is a NT fragment, not a driver. If you want to take a step forward, there is a way to convert the memory address into a subroutine name, that is, by dump the operating system kernel image identification form (or debug ID), this The method is provided by the Windows 2000 user diagnosis.

This requires a tool called kernel debugger, but I will not be demonstrated in this lecture, but if you want to know how to perform this additional step, please read the second edition of Windows NT (the book is published in Microsoft The second chapter is available on how to dump the NTOSS kernel ID and track the system thread address to obtain the details of the system subroutine name. Now let us go back to complete the remaining system process tree. Keep in mind that TLIST / T shows us this tree structure. This slide is precisely in a graphical way to show the father and child relationship between processes. Next, let us complete the description of the remaining process. If you view the TLIST / T output, it will notice the first process ending with .exe is SMSS, which represents the session manager. This is the first process that is created and is related to the load of the system remaining. In order to allow you to view the output of TLIST / T, I will return to the command line, and type TLIST / T. The session manager has two children, namely CSR and WinLogin. The CSR we just mentioned is a fragment of the window operating system. When you see the next slide, there will be two additional details on why running the process. CSR is not a frequently running process, which is only called for small partial window system requests. If you often run the CSR access process in your system, there may be one or two reasons, which is also the last two parts of this submission - window management and running on the character application (such as command line mode). The application. The above application is processed by CSR access. If you run 16-bit DOS or Windows 3.1 applications, some support for the program includes in CSR access, however, in a regular NT server or Windows 2000 Professional desktop system, the process should be stationary. Now let's return to the previous slide and complete the remaining process tree.

As the name suggests, Winlogon is a login process. This process provides the dialog box required for the type control and input port to log in. When you enter the username and password, Winlogon sends it to a child called LSASS. If you perform a local login to the server or workstation, the LSASS process will check the user name and password in the secure database (ie SAM). Since the network login service runs within the LSASS child process, if you are logging in to the NT 4.0 domain account, Winlogon sends the username and password to the LSASS sub-process running on the domain controller, and the above domain controller exists in the included In the domain of the account you are logging in.

Now let's come back to see the output of TLIST / T. In the display area, can we see how many sub-processes in Winlogon? Two, namely service controllers and LSASS. Let us talk about the service controller. What is Windows NT service? A service is a clip of the server application, which is usually installed in the registry and will be started by the service controller when the system boots. If we go to the next slide, we will see a picture about the service process hierarchy. When a service is added to a registry such as SQL Server or Extreme Server, when the system boots, the service controller searches in the registry service database and creates a slave chart (because of service The projects can be rely on each other), which in turn starts in the correct order. As shown in the TLIST / T output, the service controller has many sub-processes, which represent images of the executable program, and these executable program images include server application components that run service functions. Now how will you view the list of installed services? Let's click Start / Set / Control Panel, and click on the management tool in Windows 2000. In the Administrative Tool, we click Services. The current display is similar to you get from Windows NT 4.0 and accompanying information. For example, the description is the new information added to Windows 2000. This provides some extra descriptive text to explain what the service is doing. Viewing the ability of the detailed properties of the various services is also the new feature of Windows 2000. For example, I will scroll down to the offline print service and click the right mouse button, and then select the properties item on the appearance menu, one of the properties shown is the path to the executable program. Why is this important? The reason is that the service name is not always mapped to the executable file name containing the constituent service function code. In other words, if you are looking at the Task Manager and find that a service process is running, the service is executed The file name may not immediately tell you that it is not the service function displayed in the control panel. Let's look at the next slide, it shows how to map the service activities you see in the system to the service activities defined in the registry. Ok, we just saw how to map a service to the executable file name, but how should we perform the reverse process of this process? TLIST solves this issue by adding a parameter-/ s we have not used. The content displayed by this parameter is designed for those who contain services, as I am now using the service name that is displayed in the process in white. Please note that some service processes contain a single service like offline printing, while others contain multiple services, which means that it is still difficult to explain it in the premise of which service is being running. CPU time occupation issues, but you have shrunk this problem into a smaller range. Keep in mind that the names displayed in the third column are not those you see in the control panel, because the service actually has three names: the system administrator sees the name seen in the control panel, including the The name of the service executable and the service name in the registry. TLIST displayed is the service name in the registration. Therefore, if you enter the registry and view the service list (this list exists in the current control service of the H keystone), that is, you can view the registry key name in alphabetical order. Under this registry key, it is the name of the display name that you will see in the control panel and the name of the executable. Therefore, with TLIST / T this tool, you will be able to determine at least to a certain degree of a process in which a process in these service processes is being judged, and it is precisely one or more services leads to the CPU time. Take up.

The content of our last section involves observing its abnormal process activity when the process crashes. No one is willing to see the application crash, but I believe that all of you have seen at least half of the top half of the screen - the message box generated by the famous Dr. Watson program. Now, what we see is actually a DR. Watson message box updated in Windows 2000, which is less than the same message box than NT 4.0. Windows NT 4.0 displays the application crash in the message box. And labeled it to Dr. Watson. Now it is only labeled as an application error and adds some help characters in NT 4.0, mainly including the sentence of "You need to restart". Although most users know that they should do this, this message box is more clearly specified in the application's crash. You need to restart the program. Unfortunately, it still does not tell users what to do for the application's crash. It only shows a generated error logging. So, where is this error log record and what to do? This is exactly what we will consider in this section. First of all, how to cause a process crash? An unwilling abnormality is generated, for example, references an illegal memory address, or is divided by 0. Most Windows NT 4.0 and Windows 2000 systems are configured to run Dr. Watson when an application is wrong. The AE Debug key in the registry indicates the name of the debugger, which is located in the software branch. If you find the registry key, you will find that it is configured as debugger Dr. Watson, Dr. Watson is not a real debugger, but only a post-license tool that generates information snapshots when the process crashes. If you have already installed Visual Studio or some other development tools, the registry may have been modified, no longer use Dr. Watson, replaced by the Visual Studio development environment, when the process crashes, you will see the screen below The message box for programmers is displayed, including detailed information about exceptions and an option to the programmer an exit program or run the debugger. But in most cases, the message box above is still displayed.

What happens when a program crashes? First, let us create such a situation and take a look at its results. Let's return to the command line and run a program that will immediately lead to the violation immediately, which references a 0 address such an illegal address. A message box generated by Dr. Watson is displayed, and at the same time create an error logging, we still don't know where it comes, so click OK. Below, we will run the Dr. Watson tool to determine the location of the wrong log record by interactively running the Dr. Watson tool. I will run DrwtsN32, which is the program name of the Dr. Watson tool. When interacting with the Dr. Watson tool, it displays a configuration dialog to tell you the location of the log file and the failed dump file, although not mentioned in the message box, it can be seen that the failed dump file is obviously created. . The default action in Windows NT 4.0 and Windows 2000 is to create a log file for Dr. Watson and a failed dump file. The failed dump file named user.dmp contains content in private memory spaces in the death process. The log file contains text messages that I don't know if the programmer has help. The User.dmp file contains the exact state of the process. In other words, it contains the dirty sand in the sandbox during the death. The dump file can be applied to a tool or Windows debugger called WindBG to observe the status of the process crash, which will have a problem that you want to debug or diagnose. In reality, for each crash process, you should send a user.dmp file to the program owner. For example, if Outlook crashes, and is an unknown problem, you should send a dump file to Microsoft. If it is a third-party software, you should send a user.dmp file to its vendors. Dump files will be overwritten each time, in contrast, the log file is appended to the default. The log file will save the tracking information of all process crashes, unfortunately, the user.dmp file will be overwritten. Therefore, unless certain mechanisms or ensures that the user has been trained to be able to position and rename files, only the nearest death process information will be retained. Currently, it is not a NT core failure dump generated by the system crash, but a dump file generated by a process crash. Different tools will be used to observe the two dump files. The most basic, if your user encounters a Dr. Watson error or program error, someone should get dump files and transfer them to his own system, change their name and send it to the vendor.

Another tool related to the system crash is a program called enhancing the user dump tool as part of the debug tool to the Windows 2000. This tool will be installed when installing a debug tool from the user diagnostic CD. The tool can be completed and the function that DR. Watson is currently unacceptable is to generate a USER.DMP file for a suspended process in the case where the process is not affected. Now, if there is a hang-up program, and your only choice is to kill this process. In this case, there is also a method of obtaining a memory snapshot so that you can send it to the vendor and expect the problem to be resolved. This method is configured to run the tool from the command line state or by predefined shortcuts (which is very useful when switching to the command line state). To get more information, you can refer to the Help file for the Windows 2000 debugging tool.

The above is about understanding Windows NT 4.0 and Windows 2000 systems and process activities. I hope that through the tools we have seen, you can go deep into the process or system activity when the system is running slowly or if you have failed, and what is the CPU time spent on the process or in this way.

For more information, you can get a lot of information about NT troubleshooting in the article on the TechNet website. Of course, WINDOWS 2000 Microsoft official courses are also useful. The Windows 2000 Technology Center on the Technet website is another good reference resource. In the lower part of the slide, there are some useful information about the Window 2000 operating system, for example, my work "INSIDE Windows 2000 Second Edition", the Very Valuable Information About NT System Configuration in the Windows 2000 Resource Toolkit, and One you may not think of the web page that you want to go accessed - Hardware Developer's Web (Microsoft.com/hwdev), which contains some NT internal articles interested in driver writers. Finally, there are some additional tools and technical information on the sysinternals.com website. I would like to thank the WINDOWS NT and WINDOWS 2000 development group members and My Customer Jamie Hanrahan. The former provided me with the permission of the source code in my book and prepared for the workshop; the latter wrote the NT internal classification section required for this lecture. If you want to get more information, please visit our website www.salsin.com. The number of the number TNQ 00 ended.

转载请注明原文地址:https://www.9cbs.com/read-16559.html

New Post(0)