> For the complete documentation index, see [llms.txt](https://docs.hyperdbg.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hyperdbg.org/using-hyperdbg/kernel-mode-debugging/examples/basics/switching-to-a-specific-process-or-thread.md).

# Switching to a Specific Process or Thread

Using the '.process', and the '.thread' commands

Switching to new processes/threads is useful when debugging a particular process or a user-mode application. These switchings are possible through the '[.process](https://docs.hyperdbg.org/commands/meta-commands/.process)' and '[.thread](https://docs.hyperdbg.org/commands/meta-commands/.thread)' commands.

In HyperDbg, there are different implementations of these switchings. You can read more about these differences [here](https://docs.hyperdbg.org/tips-and-tricks/considerations/difference-between-process-and-thread-switching-commands).

In this example, we walk through a C code to show how to use these commands.

Imagine we compiled the following program. It's an infinite loop that prints a counter every **1000000000** times.

```clike
#include <Windows.h>
#include <conio.h>
#include <iostream>

int main() {

	bool Test = true;
	UINT64 Counter = 0;

	while (Test) {

		if (Counter % 1000000000 == 0) {
			printf("Thread is running (%lld)...\n", Counter);
		}
		Counter++;
	}

	printf("Thread is closed!\n");
	_getch();
}
```

After compiling and running the above code, we use the command shown in the picture to view the list of processes and other information about the processes running in the system.

```
3: kHyperDbg> .process list
```

![View process list](https://1255335821-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M2wWz6ePF27bvsJcWed%2Fuploads%2Fgit-blob-e47c7120b3c2b9b49dfaee6c747acbf93281f22e%2F1-process-list.png?alt=media)

We find our target program which its name is "**Test.exe**". Then, we see a list of running threads based on this process. For this purpose, we used the process object address (`nt!_EPROCESS`).

```
3: kHyperDbg> .thread list process ffff948cc16c3080
```

![View list of threads of a process](https://1255335821-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M2wWz6ePF27bvsJcWed%2Fuploads%2Fgit-blob-3701152301c8208403bc015913ab4d9b47206a76%2F2-find-threads-of-test-process.png?alt=media)

Now, we can switch to the target thread and continue the debuggee. Whenever the system reaches the target thread, it will be halted again and run new commands.

Note that it's a 32-bit program, so we use the '[u2](https://docs.hyperdbg.org/commands/debugging-commands/u)', which is the 32-bit version of the disassembler in this case.

```
3: kHyperDbg> .thread tid b10
```

![Switch to a new thread](https://1255335821-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M2wWz6ePF27bvsJcWed%2Fuploads%2Fgit-blob-b3fa445971a96042bdc7be834e9f9318425d11d8%2F3-switch-to-the-target-thread.png?alt=media)

After analyzing the program, we find the jumps in the assembly code. You can also see the calls that are probably a link to the `printf` function.

```
2: kHyperDbg> u2 00e249f6
```

![Disassemble the target thread](https://1255335821-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M2wWz6ePF27bvsJcWed%2Fuploads%2Fgit-blob-e26a53cfef11936fde9f1d7ec3888f43b20d1e50%2F4-disassembling-and-finding-jumps.png?alt=media)

Then, we step through the instructions to better understand how this program works.

![Step through the instructions](https://1255335821-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M2wWz6ePF27bvsJcWed%2Fuploads%2Fgit-blob-8592b001fa07fe3617e545c2ce9a6f7fafd09207%2F5-stepping-and-investigate-the-test-program.png?alt=media)

After some investigation, we can conclude that the guilty jump is located at `0xe24a31`, so we'll modify the memory and patch it by using nop instructions(0x90).

```
2: kHyperDbg> eb 00e24a31 90 90
```

![Patch the program's execution flow](https://1255335821-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M2wWz6ePF27bvsJcWed%2Fuploads%2Fgit-blob-0cde723231e01242bc7e29db5cee11d8f301e7ce%2F6-patch-the-target-jump.png?alt=media)

If we continue the debuggee again, you can see that the patched program jumps out of the infinite loop and show the '**thread is closed!**' message.

![The result of patched program](https://1255335821-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M2wWz6ePF27bvsJcWed%2Fuploads%2Fgit-blob-f9a7d01e8df2f3cc6dba0e05d275096af9a0c92d%2F7-result-of-patching-target-program.png?alt=media)

It was a simple example of how to use thread and process switching commands in HyperDbg. You can think about different approaches that you can use to change the program's execution flow (like changing the RFLAGS, etc.) or analyze any other programs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.hyperdbg.org/using-hyperdbg/kernel-mode-debugging/examples/basics/switching-to-a-specific-process-or-thread.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.