http://www.yythac.com/ar/ljjc2.txt
Source: The ALA is now 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. One of them is used to record data operations, and another other operations used to record files open and off. 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 start the Window NT Explorer and enter the file in my WIN NT Driveracche 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 easily observe a process and quickly determine how the process is consumed - is 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 3 tools: Performance Monitor, Process Browser, and NT 4.0 Resource Tools, a tool called PSTAT, this tool does not only exist in Windows2000 Resource Tools. In the package, it is also an integral part of the Platform SDK (That is, the platform software development kit), and is published with the 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 done and the function that Dr.Watson is currently unable to implement is a user.dmp file for a pending process in the process without affecting the process. 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.
