Windbg DEBUG command 7 (! Runaway ,~)

Windbg DEBUG command 7 (! Runaway ,~)

1.! Runaway

! RunawayCommand to display the consumption time of each thread

Bit 0 (0x1) enables the debugger to display the user time consumed by each thread. The default value 0x1 is not added.

Bit 1 (0x2) shows the Kernel Time consumed by each thread ).

Bit 2 (0x4) shows how long each thread has elapsed since its creation.

Is the combination of the three: 1 2 3 4 5 6 7

0: 002>! Runaway
User Mode Time
Thread time
0: 890 0 days 0:00:00. 031
2: a00 0 days 0:00:00. 000
1: 1174 0 days 0:00:00. 000
0: 002>! Runaway 1
User Mode Time
Thread time
0: 890 0 days 0:00:00. 031
2: a00 0 days 0:00:00. 000
1: 1174 0 days 0:00:00. 000
0: 002>! Runaway 2
Kernel Mode Time
Thread time
0: 890 0 days 0:00:00. 062
2: a00 0 days 0:00:00. 000
1: 1174 0 days 0:00:00. 000
0: 002>! Runaway 3
User Mode Time
Thread time
0: 890 0 days 0:00:00. 031
2: a00 0 days 0:00:00. 000
1: 1174 0 days 0:00:00. 000
Kernel Mode Time
Thread time
0: 890 0 days 0:00:00. 062
2: a00 0 days 0:00:00. 000
1: 1174 0 days 0:00:00. 000
0: 002>! Runaway 4
Elapsed time
Thread time
0: 890 0 days 0:38:34. 825
1: 1174 0 days 0:38:34. 793
2: a00 0 days 0:38:24. 528
0: 002>! Runaway 7
User Mode Time
Thread time
0: 890 0 days 0:00:00. 031
2: a00 0 days 0:00:00. 000
1: 1174 0 days 0:00:00. 000
Kernel Mode Time
Thread time
0: 890 0 days 0:00:00. 062
2: a00 0 days 0:00:00. 000
1: 1174 0 days 0:00:00. 000
Elapsed time
Thread time
0: 890 0 days 0:38:41. 825
1: 1174 0 days 0:38:41. 793
2: a00 0 days 0:38:31. 528

This extended command can be used to quickly find out which thread loops consume too much CPU time. In the output, each thread is identified by the Internal Thread number and hex thread ID of the debugger. The debugger ID is displayed. Of course, it is mainly used to analyze the dump file.

2~

Waveform character (~) Command to display the information of the specified thread or all threads in the current process
This command displays all threads

0: 001>~

This command also displays all threads.

0: 001>~ *

The following command displays the current active thread.

0: 001>~.

The following command shows the original abnormal thread (or the active thread when the debugger is attached to the process ).

0: 001>~ #

The thread number 2 is displayed below.

0: 001>~ 2

 

0: 002> ~
0 ID: 17a4. eb4 suspend: 1 Teb: 7ffdf000 unfrozen
1 ID: 17a4. d4c suspend: 1 Teb: 7ffde000 unfrozen
. 2 ID: 17a4. AAC suspend: 1 Teb: 7ffdd000 unfrozen
0: 002> ~ *
0 ID: 17a4. eb4 suspend: 1 Teb: 7ffdf000 unfrozen
Start: calc! Winmaincrtstartup (01012475)
Priority: 0 priority class: 32 affinity: F
1 ID: 17a4. d4c suspend: 1 Teb: 7ffde000 unfrozen
Start: winimhc! Tgetlogconfig + 0x507b (10012f7b)
Priority: 0 priority class: 32 affinity: F
. 2 ID: 17a4. AAC suspend: 1 Teb: 7ffdd000 unfrozen
Priority: 0 priority class: 32 affinity: F
0: 002> ~ 0
0 ID: 17a4. eb4 suspend: 1 Teb: 7ffdf000 unfrozen
Start: calc! Winmaincrtstartup (01012475)
Priority: 0 priority class: 32 affinity: F
0: 002> ~ #
. 2 ID: 17a4. AAC suspend: 1 Teb: 7ffdd000 unfrozen
Priority: 0 priority class: 32 affinity: F

We can find that ,~ And ~ * It is a little different ,~ * The entry function and priority are printed out,

0 ID: 17a4. eb4 suspend: 1 Teb: 7ffdf000 unfrozen indicates Thread 0, process ID is 17a4, thread ID is eb4, pause number is 1, unfrozen

Each thread contains a suspend count and a frozen/unfrozen state.

The pause count is the value used by the Windows Kernel. It can be controlled through the suspendthread and resumethread system functions. In core programming, when a thread is created, the pause count is 1,

After the thread is fully initialized, the system will check whether the create_suspend flag has been passed to createthread. If this flag is not passed, the system will decrease the pause count of the thread to 0,

This thread can be scheduled to a process

You can also use ~ <TID> N adds the pause count. Use ~ <TID> M: reduce the pause count as follows:

0: 002> ~ 0n
0: 002> ~
0 ID: 17a4. eb4 suspend: 2 Teb: 7ffdf000 unfrozen
1 ID: 17a4. d4c suspend: 1 Teb: 7ffde000 unfrozen
. 2 ID: 17a4. AAC suspend: 1 Teb: 7ffdd000 unfrozen
0: 002> ~ 0 m
0: 002> ~
0 ID: 17a4. eb4 suspend: 1 Teb: 7ffdf000 unfrozen
1 ID: 17a4. d4c suspend: 1 Teb: 7ffde000 unfrozen
. 2 ID: 17a4. AAC suspend: 1 Teb: 7ffdd000 unfrozen
0: 002> ~ 0 m
0: 002> ~
0 ID: 17a4. eb4 suspend: 0 Teb: 7ffdf000 unfrozen
1 ID: 17a4. d4c suspend: 1 Teb: 7ffde000 unfrozen
. 2 ID: 17a4. AAC suspend: 1 Teb: 7ffdd000 unfrozen
0: 002> ~ 1 m
0: 002> ~
0 ID: 17a4. eb4 suspend: 0 Teb: 7ffdf000 unfrozen
1 ID: 17a4. d4c suspend: 0 Teb: 7ffde000 unfrozen
. 2 ID: 17a4. AAC suspend: 1 Teb: 7ffdd000 unfrozen

For example, I only call it once ~ 0n, then the reference count of the main thread is changed to 2. I call G again and the reference count of the main thread is changed to 1. Our calc cannot run!

The frozen state is the state of the debugger, which is not supported in the window operating system. The debugger will remember this state for every frozen thread, the thread suspension count is increased before the debugging event is processed. When the debugging event is processed, the suspension count is decreased. The corresponding command is:

Freeze ~ <TID> F

Restore ~ <TID> U

The number of freeze commands must be the same as the number of unfreeze commands.