完美者（wmzhe.com）网站以软件下载为基础，改版后的网站对功能性板块进行扩充，以期能够解决用户在软件使用过程中遇见的所有问题。网站新增了“软件百科”、“锦囊妙技”等频道，可以更好地对用户的软件使用全周期进行更加专业地服务。
ProcessThreadsView是一个查看系统进程详细信息的小程序，它能枚举出每个进程的详细情况。ProcessThreadsView是一个小工具，显示有关您选择的过程中，所有线程的信息。线程的信息包括的ThreadID，上下文切换次数，优先级，创建时间，用户/内核时间，窗口数量，窗口标题，起始地址，以及更多。在上部窗格中选择一个主题时，下部窗格中显示以下信息：堆栈，堆栈模块的地址找到的字符串，调用堆栈，和处理器寄存器。ProcessThreadsView也允许你暂停和恢复一个或多个线程。
"锦囊妙技"栏目是聚合全网软件使用的技巧或者软件使用过程中各种问题的解答类文章，栏目设立伊始，小编欢迎各路软件大神朋友们踊跃投稿，在完美者平台分享大家的独门技巧。
本站文章素材来源于网络，大部分文章作者名称佚失，为了更利于用户阅读和使用，根据需要进行了重新排版和部分改编，本站收录文章只是以帮助用户解决实际问题为目的，如有版权问题请联系小编修改或删除，谢谢合作。
软件大小：102.34 KB
这个可以用processthreadsview查找出可疑的具体进程位置，用进程工具强制关闭它，并按查出的路径删除软件。
using System;using System.Windows.Forms;using System.Diagnostics;using System.Collections;private void EnumProcesses() { 1653// Timespans for individual process information TimeSpan tpt; TimeSpan tppt; TimeSpan tupt; // Timespans for machine TimeSpan mtpt = new TimeSpan(); TimeSpan mtppt = new TimeSpan(); TimeSpan mtupt = new TimeSpan(); ListViewItem lSingleItem; // Enumerate all processes try { Process[] Processes; if (!(mcolProcesses == null)) { mcolProcesses = new ArrayList(); } if (this.lvProcesses.Items.Count > 0) { this.lvProcesses.Items.Clear(); this.lvProcessDetail.Items.Clear(); this.lvThreads.Items.Clear(); } Processes = Process.GetProcesses(); foreach(Process p in Processes) { mcolProcesses.Add(p); // Get processor time and store tppt = p.PrivilegedProcessorTime; tupt = p.UserProcessorTime; tpt = p.TotalProcessorTime; // Add the current process times to total times. mtpt = mtpt.Add(tpt); mtppt = mtppt.Add(tppt); mtupt = mtupt.Add(tupt); // % User Processor Time decimal dblPUPT = Decimal.Divide(tupt.Ticks, tpt.Ticks); string strPUPT = dblPUPT.ToString("#0%");// % Privileged Processor Time decimal dblPPPT = Decimal.Divide(tppt.Ticks, tpt.Ticks); string strPPPT = dblPPPT.ToString("#0%"); string strTPT; strTPT = (tpt.Days.ToString("00") + "." + tpt.Hours.ToString("00") + ":" + tpt.Minutes.ToString("00") + ":" + tpt.Seconds.ToString("00")); lSingleItem = this.lvProcesses.Items.Add(p.ProcessName + " (0x" + (p.Id.ToString("x")).ToLower() + ")"); lSingleItem.SubItems.Add(p.Id.ToString()); lSingleItem.SubItems.Add(strTPT); lSingleItem.SubItems.Add(strPPPT); lSingleItem.SubItems.Add(strPUPT); } // % Total User Processor Time decimal mdecPUPT = Decimal.Divide(mtupt.Ticks , mtpt.Ticks); string mstrPUPT = mdecPUPT.ToString("#0%"); // % Total Privileged Processor Time decimal mdecPPPT = decimal.Divide(mtppt.Ticks,mtpt.Ticks); string mstrPPPT = mdecPPPT.ToString("#0%"); string mstrTPT; mstrTPT = (mtpt.Days.ToString("00") + "." + mtpt.Hours.ToString("00") + ":" + mtpt.Minutes.ToString("00") + ":" + mtpt.Seconds.ToString("00")); // Add entry for all processes lSingleItem = this.lvProcesses.Items.Add(PROCESS_NAME_TOTAL); lSingleItem.SubItems.Add(PID_NA); lSingleItem.SubItems.Add(mstrTPT); lSingleItem.SubItems.Add(mstrPPPT); lSingleItem.SubItems.Add(mstrPUPT); } catch (Exception exp) { MessageBox.Show(exp.Message, exp.Source, MessageBoxButtons.OK, MessageBoxIcon.Error); } } c# 检测cpu使用率创建一个控制台应用程序，代码如下代码 using System;using System.Collections.Generic;using System.Linq;using System.Text;//引用2命名空间using System.Diagnostics;using System.Threading;namespace ConsoleApplication1{class Program{static void Main(string[] args){Process[] p = Process.GetProcessesByName("devenv");//获取指定进程信息// Process[] p = Process.GetProcesses();//获取所有进程信息string cpu = string.Empty;string info = string.Empty;PerformanceCounter pp = new PerformanceCounter();//性能计数器pp.CategoryName = "Process";//指定获取计算机进程信息如果传Processor参数代表查询计算机CPU pp.CounterName = "% Processor Time";//占有率//如果pp.CategoryName="Processor",那么你这里赋值这个参数 pp.InstanceName = "_Total"代表查询本计算机的总CPU。pp.InstanceName = "devenv";//指定进程 pp.MachineName = ".";if (p.Length > 0){foreach (Process pr in p){while (true)//1秒钟读取一次CPU占有率。{info = pr.ProcessName + "内存：" +(Convert.ToInt64(pr.WorkingSet64.ToString()) / 1024).ToString();//得到进程内存Console.WriteLine(info + " CPU使用情况：" + Math.Round(pp.NextValue(), 2).ToString() + "%");Thread.Sleep(1000);}}}}}}
仅供参考:The factory is re-making the sample finish. Please help to reconfirm the process. As per your opinion, all seaming threads are exposed. However, we sent you our samples twice, they were made in two different ways. You didn't confirm on either ones. The correct way, we guess should be that of the second sample. If the side seaming line shall not be exposed, the factory has to wrap the edges, which makes the seaming very thick and affects its look. The factory suggests we do it in the older way. -------------不是纺织专业，翻译仅供参考。
technical ramblings from a wanna-be unix dinosaurHow do debuggers keep track of the threads in your program?View CommentsIf you enjoy this article, subscribe (via RSS or e-mail) and follow me on twitter.tl;drThis post describes the relatively undocumented API for debuggers (or other low level programs) that can be used to enumerate the existing threads in a process and receive asynchronous notifications when threads are created or destroyed. This API also provides asynchronous notifications of other interesting thread-related events and feels very similar to the interface exposed by libdl for notifying debuggers when libraries are loaded dynamically at run time.amd64 and gnu syntaxAs usual, everything below refers to amd64 unless otherwise noted. Also, all assembly is in AT&T syntax.software breakpointsIt’s important to begin first by examining how software breakpoints work. We’ll see shortly why this is important, but for now just trust me.A debugger sets a software breakpoint by using the ptrace system call to write a special instruction into a target process’ address space. That instruction raises software interrupt #3 which is defined as the Breakpoint Exception in the Intel 64 Architecture Developers Manual.1 When this interrupt is raised, the processor undergoes a privilege level change and calls a function specified by the kernel to handle the exception.The exception handler in the kernel executes to deliver the SIGTRAP signal to the process. However, if a debugger is attached to a process with ptrace, all signals are first delivered to the debugger. In the case of SIGTRAP, the debugger can examine the list of breakpoints set by the user and take the appropriate action (draw a UI, update the console, or whatever).The debugger finishes up by masking this signal from the process it is attached to, preventing that process from being killed (most processes will not have a signal handler for SIGTRAP).In practice most binaries generated by compilers will not have this instruction; it is up to the debugger to write this instruction into the process’ address space during runtime. If you are so inclined, you can raise interrupt #3 via inline assembly or by calling an assembly stub yourself. Many debuggers will catch this signal and trigger an update of some form in the UI.All that said, this is what the instruction looks like when disassembled:int 0x03You may find it useful to check out an earlier and more in-depth article I wrote a while ago about signal handling.Enumerating threads when first attachingWhen a debugger first attaches to a program the program has an unknown number of threads that must be enumerated. glibc exposes a straightforward API for this called td_ta_thr_iter2 found in glibc at nptl_db/td_ta_thr_iter.c. This function takes a callback as one of its arguments. The callback is called once per thread and is passed a handle to an object describing each thread in the process.We can see the code in GDB3 which uses this API to hand over a callback which will be hit to enumerate the existing threads in a process:static intfind_new_threads_once (struct thread_db_info *info, int iteration, td_err_e *errp){ volatile struct gdb_exception except; struct callback_data data; td_err_e err = TD_ERR; data.info = info; data.new_threads = 0; TRY_CATCH (except, RETURN_MASK_ERROR) { /* Iterate over all user-space threads to discover new threads. */ err = info->td_ta_thr_iter_p (info->thread_agent, find_new_threads_callback, &data, TD_THR_ANY_STATE, TD_THR_LOWEST_PRIORITY, TD_SIGNO_MASK, TD_THR_ANY_USER_FLAGS); } /* ... */That’s pretty straightforward, but there are some hairy race conditions, as we can see in this code snippet from thread_db_find_new_threads_2 which calls find_new_threads_once:if (until_no_new) { /* Require 4 successive iterations which do not find any new threads. The 4 is a heuristic: there is an inherent race here, and I have seen that 2 iterations in a row are not always sufficient to "capture" all threads. */ for (i = 0, loop = 0; loop < 4; ++i, ++loop) if (find_new_threads_once (info, i, NULL) != 0) /* Found some new threads. Restart the loop from beginning.»·*/ loop = -1; }It's fiiiiiiiiiinnnneeee.Now, on to the more interesting interface that is, IMHO, much less straightforward.Notification of thread create and destroyA debugger can also gather thread create and destroy events through an interesting asynchronous interface. Let's go step by step and see how a debugger can listen for create and destroy events.Enable event notificationFirst, process wide event notification has to be enabled. This API looks very much like some pieces of the signal API. First we have to create a set of events of we care about (from GDB4 ):static voidenable_thread_event_reporting (void){ td_thr_events_t events; td_err_e err; /* ... */ /* Set the process wide mask saying which events we're interested in. */ td_event_emptyset (&events); td_event_addset (&events, TD_CREATE); /* ... */ td_event_addset (&events, TD_DEATH); /* NB: the following is just a pointer to the function td_ta_set_event on linux */ err = info->td_ta_set_event_p (info->thread_agent, &events);The above code adds TD_CREATE and TD_DEATH to the (empty) set of events that GDB wants to get notifications about. Then the event mask is handed over to glibc with a call to the function td_ta_set_event, which just happens to be stored in a function pointer named td_ta_set_event_p in GDB.Set asynchronous notification breakpointsThe next step is interesting.The debugger must use an API to get the addresses of a functions that will be called whenever a thread is created or destroyed. The debugger will then set a software breakpoint at those addresses. When the program creates a thread or a thread is killed the breakpoint will be triggered and the debugger can walk the thread list and update its internal state that describes the threads in the process.This API is td_ta_event_addr. Let's check out how GDB uses this API. This code is from the same function as above, but happens after the code shown above:static voidenable_thread_event_reporting (void){ /* ... code above here ... */ /* Delete previous thread event breakpoints, if any. */ remove_thread_event_breakpoints (); info->td_create_bp_addr = 0; info->td_death_bp_addr = 0; /* Set up the thread creation event. */ err = enable_thread_event (TD_CREATE, &info->td_create_bp_addr); /* ... */ /* Set up the thread death event. */ err = enable_thread_event (TD_DEATH, &info->td_death_bp_addr);GDB's helper function enable_thread_event is pretty straightforward:static td_err_eenable_thread_event (int event, CORE_ADDR *bp){ td_notify_t notify; td_err_e err; struct thread_db_info *info; info = get_thread_db_info (GET_PID (inferior_ptid)); /* Access an lwp we know is stopped. */ info->proc_handle.ptid = inferior_ptid; /* Get the breakpoint address for thread EVENT. */ err = info->td_ta_event_addr_p (info->thread_agent, event, ¬ify); /* ... */ /* Set up the breakpoint. */ gdb_assert (exec_bfd); (*bp) = (gdbarch_convert_from_func_ptr_addr (target_gdbarch, /* Do proper sign extension for the target. */ (bfd_get_sign_extend_vma (exec_bfd) > 0 ? (CORE_ADDR) (intptr_t) notify.u.bptaddr : (CORE_ADDR) (uintptr_t) notify.u.bptaddr), ¤t_target)); create_thread_event_breakpoint (target_gdbarch, *bp); return TD_OK;}So, GDB stores the addresses of the functions that get called on TD_CREATE and TD_DEATH in td_create_bp_addr and td_death_bp_addr, respectively and sets breakpoints on these addresses in enable_thread_event.Check if the event has been triggered and drain the event queueNext time a thread is stopped because a breakpoint has been hit, the debugger needs to check if the breakpoint occurred on an address that is associated with the registered events. If so, the thread event queue needs to be drained with a call to td_ta_event_getmsg and the thread's information can be retrieved with a call to td_thr_get_info .GDB does all this in a function called check_event:/* Check if PID is currently stopped at the location of a thread event breakpoint location. If it is, read the event message and act upon the event. */static voidcheck_event (ptid_t ptid){ /* ... */ td_event_msg_t msg; td_thrinfo_t ti; td_err_e err; CORE_ADDR stop_pc; int loop = 0; struct thread_db_info *info; info = get_thread_db_info (GET_PID (ptid)); /* Bail out early if we're not at a thread event breakpoint. */ stop_pc = /* ... */ if (stop_pc != info->td_create_bp_addr && stop_pc != info->td_death_bp_addr) return; /* Access an lwp we know is stopped. */ info->proc_handle.ptid = ptid; /* ... */ /* If we are at a create breakpoint, we do not know what new lwp was created and cannot specifically locate the event message for it. We have to call td_ta_event_getmsg() to get the latest message. Since we have no way of correlating whether the event message we get back corresponds to our breakpoint, we must loop and read all event messages, processing them appropriately. This guarantees we will process the correct message before continuing from the breakpoint. Currently, death events are not enabled. If they are enabled, the death event can use the td_thr_event_getmsg() inter
