摘2个windbg文章
看到2个windbg文章贴在这里，回家翻译！suspend count of threads:
Freezing and Suspending Threads
The debugger can change the execution of a thread by suspending the thread or by freezing the thread. These two actions have somewhat different effects.
Each thread has a suspend count that is associated with it. If this count is one or larger, the system does not run the thread. If the count is zero or lower, the system runs the thread when appropriate.
Typically, each thread has a suspend count of zero. When the debugger attaches to a process, it increments the suspend counts of all threads in that process by one. If the debugger detaches from the process, it decrements all suspend counts by one. When the debugger executes the process, it temporarily decrements all suspend counts by one.
You can control the suspend count of any thread from the debugger by using the following methods:
The ~n (Suspend Thread) command increments the specified thread's suspend count by one.
The ~m (Resume Thread) command decrements the specified thread's suspend count by one.
The most common use for these commands is to raise a specific thread's suspend count from one to two. When the debugger executes or detaches from the process, the thread then has a suspend count of one and remains suspended, even if other threads in the process are executing.
You can suspend threads even when you are performing noninvasive debugging.
The debugger can also freeze a thread. This action is similar to suspending the thread in some ways. However, "frozen" is only a debugger setting. Nothing in the Windows operating system recognizes that anything is different about this thread.
By default, all threads are unfrozen. When the debugger causes a process to execute, threads that are frozen do not execute. However, if the debugger detaches from the process, all threads unfreeze.
To freeze and unfreeze individual threads, you can use the following methods:
The ~f (Freeze Thread) command freezes the specified thread.
The ~u (Unfreeze Thread) command unfreezes the specified thread.
In any event, threads that belong to the target process never execute when the debugger has broken into the target. The suspend count of a thread affects the thread's behavior only when the debugger executes the process or detaches. The frozen status affects the thread's behavior only when the debugger executes the process.
Noninvasive Debugging ：
If a user-mode application is already running, the debugger can debug it noninvasively. With noninvasive debugging, you do not have as many debugging actions. However, you can minimize the debugger's interference with the target application.
In noninvasive debugging, the debugger does not actually attach to the target application. The debugger suspends all of the target's threads and has access to the target's memory, registers, and other such information. However, the debugger cannot control the target, so commands like g (Go) do not work.
If you try to execute commands that are not permitted during noninvasive debugging, you receive an error message that states, "The debugger is not attached, so process execution cannot be monitored."
When you end the debugging session, the debugger releases the target application, and the application continues running. You should close the session by using q (Quit), .detach (Detach from Process), or WinDbg's Debug | Detach Debuggee or Debug | Stop Debugging command. (If you close the debugging session by closing the debugger window or by using the Exit command on the File menu in WinDbg, your target application typically stops responding.)
Noninvasive debugging is useful if you do not want to end the target application at the end of the session, and the target application is running on Microsoft Windows 2000. (These operating systems do not support detaching from a target that the debugger has actually attached to.) Noninvasive debugging is also useful if the target application has stopped responding and cannot open the break thread that you need to attach.
Selecting the Process to Debug
You can specify the target application by the process ID (PID) or process name.
If you specify the application by name, you should use the complete name of the process, including the file name extension. If two processes have the same name, you must use the process ID instead.
For more information about how to determine the process ID and the process name, see Finding the Process ID.
The following sections in this topic describe several ways to begin a noninvasive debugging session, organized by the location from which you are starting the session.
CDB Command Line
To noninvasively debug a running process from the CDB command line, specify the -pv option, the -p option, and the process ID, in the following syntax.
cdb -pv -p ProcessID
Or, to noninvasively debug a running process by specifying the process name, use the following syntax instead.
cdb -pv -pn ProcessName
There are several other useful command-line options. For more information about the command-line syntax, see CDB Command-Line Options.
WinDbg Command Line
To noninvasively debug a running process from the WinDbg command line, specify the -pv option, the -p option, and the process ID, in the following syntax.
windbg -pv -p ProcessID
Or, to noninvasively debug a running process by specifying the process name, use the following syntax instead.
windbg -pv -pn ProcessName
There are several other useful command-line options. For more information about the command-line syntax, see WinDbg Command-Line Options.
WinDbg Menu
When WinDbg is in dormant mode, you can noninvasively debug a running process by clicking Attach to a Process on the File menu or by pressing F6.
When the Attach to Process dialog box appears, select the Noninvasive check box. Then, select the line that contains the process ID and name that you want. (You can also enter the process ID in the Process ID box.) Finally, click OK.
Debugger Command Window
If the debugger is already active, you can noninvasively debug a running process by using the .attach -v (Attach to Process) command in the Debugger Command window.
You can use the .attach command if the debugger is already debugging one or more processes invasively. You can use this command in CDB if it is dormant, but not in a dormant WinDbg.
If the .attach -v command is successful, the debugger debugs the specified process the next time that the debugger issues an execution command. Because execution is not permitted during noninvasive debugging, the debugger cannot noninvasively debug more than one process at a time. This restriction also means that using the .attach -v command might make an existing invasive debugging session less useful.
Beginning the Debugging Session
For more information about how to begin a debugging session, see Debugger Configuration, Symbols, Debugger Operation (General) and Debugger Operation (User Mode).
好文章！
starting zhuang bi：
线程的挂起计数器
冻结和挂起程。。。。
failed to load zhuang bi system
后面翻不来了
天尊兄加油！！ 冻结和挂起线程：
调试器可以通过挂起或冻结线程的方式改变线程执行状态，这两种方式有一些不同之处。
每个线程有一个挂起计数，如果该值大于等于1则系统不会运行该线程。如果该值小于等于0则系统在适当时机运行该线程。
通常每个线程的挂起计数为0，当调试器附加到进程时会将进程的所有线程挂起计数加1，同样在调试器分离进程时会将计数减1，而在调试器执行进程时，会临时将挂起计数减1。
以下几种方式可以控制调试器操作线程挂起计数：
~n(挂起线程)命令 挂起计数增1
~m(恢复线程)命令 挂起计数减1
这些指令通常用于将线程挂起计数从1提升到2，当调试期执行或分离进程时，线程的挂起计数为1，因此依然处于挂起状态，即使进程中的其他线程在执行。
在执行“非侵入式调试”时仍然可以挂起线程
调试器也可以冻结线程，有点类似于挂起线程，不同的是冻结只是调试器的一个设置，并不会在windows系统中造成任何改变
默认所有线程都是解冻状态，当调试器执行进程时线程处于冻结状态不执行，而在分离进程时所有线程都会解冻。
以下几种方式可以冻结解冻单个线程：
当目标进程在调试器中中断时，无论是哪种调试事件，其线程均不会执行，线程的挂起计数只有在调试器执行时或从调试器分离时才会生效。而冻结状态只有在调试器执行进程的时候影响线程的行为
非入侵式调试；
如果用户态程序在运行，调试器可以以非入侵方式进行调试，此时很多调试操作无法进行，但是可以最小化调试器对进程的影响，调试器并没有真正附加到目标进程，调试器挂起所有目标线程，访问其内存、寄存器和其他信息，然而调试器并不能控制目标进程，因此类似于g的指令无法运行。如果试图执行不允许的指令会得到错误提示。在结束调试会话时调试器释放目标进程，而进程继续执行。blablabla..........
在Windows2000系统（不支持从调试器分离进程）上如果不想在会话结束时结束目标程序，非侵入式调试是必要的。如果目标进程已停止响应而不能打开暂停的线程时，也可以使用非侵入式调试blablabla..........
页:
[1]