线程进入和线程启动之间的确切区别和关系是什么？
What is the exact difference and the relation between thread entry and thread start?
- thread entry and thread start 之间的确切区别是什么？和
- RIP（在动态分析中执行前沿所在的位置）是否总是以相同的可预测顺序到达它们？
- 线程条目是否动态变化（在动态分析中我想我看到它在寄存器和堆栈中被报告）？
我目前理解thread start是从一个角度定义的，例如，在Windows中，它始终是ntdll.RtlUserThreadStart+21（用户），但在程序库级别，它可以是任何函数。但是 thread start 在创建线程之前不会被调用 ntdll.NtCreateThreadEx+14 (System).
thread entry 是作为参数提供给 thread create 函数的（库，即导出的或私有的）函数。
使用 x64dbg 制作的带有线程（threadID、地址、to、from、大小、评论、派对）的调用堆栈示例：
4200
00000076EBDFF9A8 00007FFEC900A34E 00007FFECB4EC034 A0 ntdll.NtWaitForSingleObject+14 System
00000076EBDFFA48 00007FF7987B48A1 00007FFEC900A34E 30 kernelbase.WaitForSingleObjectEx+8E User
00000076EBDFFA78 00007FF7988961A0 00007FF7987B48A1 30 mylibrarydll0.00007FF7987B48A1 User
00000076EBDFFAA8 00007FF7987B13DF 00007FF7988961A0 30 mylibrarydll0.00007FF7988961A0 User
00000076EBDFFAD8 00007FF798B4A175 00007FF7987B13DF 30 mylibrarydll0.00007FF7987B13DF User
00000076EBDFFB08 00007FFECA637034 00007FF798B4A175 30 mylibrarydll0.sub_7FF798B4A0B4+C1 System
00000076EBDFFB38 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EBDFFBB8 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
2736
00000076EB5FF648 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14 System
00000076EB5FF948 00007FFECA637034 00007FFECB4623D7 30 ntdll.TppWorkerThread+2F7 System
00000076EB5FF978 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EB5FF9F8 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
2468
00000076EBBFFB78 00007FFEC900A34E 00007FFECB4EC034 A0 ntdll.NtWaitForSingleObject+14 System
00000076EBBFFC18 00007FF7987B48A1 00007FFEC900A34E 30 kernelbase.WaitForSingleObjectEx+8E User
00000076EBBFFC48 00007FF7988961A0 00007FF7987B48A1 30 mylibrarydll0.00007FF7987B48A1 User
00000076EBBFFC78 00007FF7987B13DF 00007FF7988961A0 30 mylibrarydll0.00007FF7988961A0 User
00000076EBBFFCA8 00007FF798B4A175 00007FF7987B13DF 30 mylibrarydll0.00007FF7987B13DF User
00000076EBBFFCD8 00007FFECA637034 00007FF798B4A175 30 mylibrarydll0.sub_7FF798B4A0B4+C1 System
00000076EBBFFD08 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EBBFFD88 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
3784
00000076EB6FFB88 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14 System
00000076EB6FFE88 00007FFECA637034 00007FFECB4623D7 30 ntdll.TppWorkerThread+2F7 System
00000076EB6FFEB8 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EB6FFF38 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
1928
00000076EB7FFA48 00007FFEC900A34E 00007FFECB4EC034 A0 ntdll.NtWaitForSingleObject+14 System
00000076EB7FFAE8 00007FF7987B48A1 00007FFEC900A34E 30 kernelbase.WaitForSingleObjectEx+8E User
00000076EB7FFB18 00007FF7988961A0 00007FF7987B48A1 30 mylibrarydll0.00007FF7987B48A1 User
00000076EB7FFB48 00007FF7987B13DF 00007FF7988961A0 30 mylibrarydll0.00007FF7988961A0 User
00000076EB7FFB78 00007FF798B4A175 00007FF7987B13DF 30 mylibrarydll0.00007FF7987B13DF User
00000076EB7FFBA8 00007FFECA637034 00007FF798B4A175 30 mylibrarydll0.sub_7FF798B4A0B4+C1 System
00000076EB7FFBD8 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EB7FFC58 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
2276
00000076EB8FF7C8 00007FFEC900A34E 00007FFECB4EC034 A0 ntdll.NtWaitForSingleObject+14 System
00000076EB8FF868 00007FF7987B48A1 00007FFEC900A34E 30 kernelbase.WaitForSingleObjectEx+8E User
00000076EB8FF898 00007FF7988961A0 00007FF7987B48A1 30 mylibrarydll0.00007FF7987B48A1 User
00000076EB8FF8C8 00007FF7987B13DF 00007FF7988961A0 30 mylibrarydll0.00007FF7988961A0 User
00000076EB8FF8F8 00007FF798B4A175 00007FF7987B13DF 30 mylibrarydll0.00007FF7987B13DF User
00000076EB8FF928 00007FFECA637034 00007FF798B4A175 30 mylibrarydll0.sub_7FF798B4A0B4+C1 System
00000076EB8FF958 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EB8FF9D8 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
12168
00000076EB9FF6E8 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14 System
00000076EB9FF9E8 00007FFECA637034 00007FFECB4623D7 30 ntdll.TppWorkerThread+2F7 System
00000076EB9FFA18 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EB9FFA98 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
2428
00000076EBAFF5D8 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14 System
00000076EBAFF8D8 00007FFECA637034 00007FFECB4623D7 30 ntdll.TppWorkerThread+2F7 System
00000076EBAFF908 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EBAFF988 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
- 所涉及的术语在常用行话中不一定有准确的定义。您链接的 x64dbg 文档给出了这些定义：
Thread Entry
Set a single-shoot breakpoint on the entry of the thread when a thread is about to run.
和
Thread Start
Pause when a new thread is about to run.
这些是调试器为它可以提醒您的明显不同类型的事件选择的标签。我的解释与你在问题中描述的一致，是“线程启动”是关于创建一个新线程，显然是在创建线程的上下文中，而“线程进入”是关于执行将 运行 在新线程中的代码，大概在该线程的上下文中。
我倾向于认为，在这些术语中，线程启动必须始终发生在线程进入之前。在线程启动之前，执行不能进入该线程的代码。事实上，我倾向于猜测线程启动事件是调试器可以发出信号的最后一个事件，它肯定发生在相关线程的线程进入之前。
在一般意义上，我希望线程入口地址是线程入口点函数的地址，或者线程主体中第一条指令的地址（不一定是同一事物）。对于不同的入口点函数，这不能期望是一致的，并且对于程序的不同 运行s 上的相同函数，它可能不相同。如果您认为自己看到了其他内容，请查阅该工具的文档。
Windows 向调试器发送一组特定的事件，您可以在 WaitForDebugEvent.
的文档中找到它们
其中一个事件是 CREATE_THREAD_DEBUG_INFO、，它在 Windows 已创建但尚未启动线程 时发送。
在 Windows 中，进程和线程的创建发生在内核中，但它们的最终初始化步骤发生在用户空间中（除非它是一个微进程，我们不会在这里讨论）。 DLL ntdll.dll 在创建后立即映射到线程中，并且线程上下文的 RIP 设置为指向此 DLL 的函数之一。
此函数将执行必要的初始化，然后跳转到 CreateThread 或类似地址中给出的地址。这个函数是线程的一种包装器。
thread start发生在初始化函数的第一条指令即将执行时（可以把它想象成Windows设置了一个断点那里）。
相反，线程条目 只是提供给线程创建的地址API。它很重要，因为它是调用者打算执行的实际代码。事实上，出于调试或 RE 目的，您几乎可以（如果不是总是）忽略线程启动事件。
我们来举个例子。考虑这个简单的 64 位程序。
BITS 64
EXTERN CreateThread
GLOBAL _start
SECTION .text
_start:
and rsp, -16
push 0
push 0
sub rsp, 20h
xor r9, r9
lea r8, [REL _thread1]
xor edx, edx
xor ecx, ecx
call CreateThread
.loop:
TIMES 1000 pause
jmp .loop
_thread1:
TIMES 1000 pause
jmp _thread1
它所做的只是创建一个线程，指向在循环中执行的 pause 条指令。主线程也会执行类似但不同的循环。
循环的目的是让线程的 RIP 发生变化，但仍然不在 Windows API 内。循环中的任何指令，如果没有错误，都可以。我选择 pause，因为 :)
Assemble 和 link 程序。
打开x64dbg，打开程序，然后设置Thread start和Thread entry事件。
现在按F9到达程序入口点，再按F9放手。调试器将收到新线程创建的通知。
请注意，执行在 RtlUserThreadStart 开始时停止。我的 Windows 版本总是这样（Windows 7 something）。鉴于此答案开头的介绍，这是有道理的。
另请注意，线程入口点在 rcx 中，这意味着它是 RtlUserThreadStart.
的第一个参数
现在，这是 Windows 发送给调试器的事件，因此执行到此停止是很自然的。
但是线程入口事件不存在，x64dbg在这里做什么？
您可以通过查看断点选项卡来揭开这个谜团。
您看到调试器在线程入口点设置了一个一次性（即它会被调试器本身自动删除）断点。
因此，虽然 Windows 不支持在线程首次开始执行其用户代码时生成调试事件，但调试器可以通过在线程实际启动之前放置一个断点来轻松模拟它。
请注意，这意味着调试器总是对线程启动事件做出反应，当在选项中禁用时，它不会停止，显示并等待您做某事。
暂停和恢复线程不会更改线程入口点，线程入口点在线程创建时固定。
x64dbg 有一个线程选项卡，允许用户挂起和恢复线程。使用它不会改变线程入口点，只是仍然指向两个循环中某处的 RIPs（为了简化此测试而存在）。
如果线程是使用挂起标志创建的，线程启动事件将在线程恢复之前不会触发。
但是，如果在恢复线程之前，完成了对 Get/SetThreadContext 的一对调用以更改线程的 RIP，那么 RtlUserStartThread 将永远不会被执行（我不知道这个函数到底做了什么，但是线程可以没有它）并且线程启动事件永远不会触发。
执行将直接转到更改后的 RIP.
我不确定这是否是 Windows' 调试界面的遗留错误，可以通过在线程的第一个调度之前设置 TF 来生成线程启动事件（并在捕获时立即删除它相关例外）。
当debugging/REing线程时，我通常做的是在线程入口点（很容易获取）或者被劫持的RIP（也很容易获取，因为这种线程被创建为暂停，所以你知道有些东西是可疑的）。
如果程序很糟糕并且线程 RIP 处的代码尚不清楚（例如，仍然被混淆），请使用硬件断点。
注意同样的事情也发生在进程创建上，完全一样（只是使用 PE 入口点而不是线程入口点）。
- thread entry and thread start 之间的确切区别是什么？和
- RIP（在动态分析中执行前沿所在的位置）是否总是以相同的可预测顺序到达它们？
- 线程条目是否动态变化（在动态分析中我想我看到它在寄存器和堆栈中被报告）？
我目前理解thread start是从一个角度定义的，例如，在Windows中，它始终是ntdll.RtlUserThreadStart+21（用户），但在程序库级别，它可以是任何函数。但是 thread start 在创建线程之前不会被调用 ntdll.NtCreateThreadEx+14 (System).
thread entry 是作为参数提供给 thread create 函数的（库，即导出的或私有的）函数。
使用 x64dbg 制作的带有线程（threadID、地址、to、from、大小、评论、派对）的调用堆栈示例：
4200
00000076EBDFF9A8 00007FFEC900A34E 00007FFECB4EC034 A0 ntdll.NtWaitForSingleObject+14 System
00000076EBDFFA48 00007FF7987B48A1 00007FFEC900A34E 30 kernelbase.WaitForSingleObjectEx+8E User
00000076EBDFFA78 00007FF7988961A0 00007FF7987B48A1 30 mylibrarydll0.00007FF7987B48A1 User
00000076EBDFFAA8 00007FF7987B13DF 00007FF7988961A0 30 mylibrarydll0.00007FF7988961A0 User
00000076EBDFFAD8 00007FF798B4A175 00007FF7987B13DF 30 mylibrarydll0.00007FF7987B13DF User
00000076EBDFFB08 00007FFECA637034 00007FF798B4A175 30 mylibrarydll0.sub_7FF798B4A0B4+C1 System
00000076EBDFFB38 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EBDFFBB8 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
2736
00000076EB5FF648 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14 System
00000076EB5FF948 00007FFECA637034 00007FFECB4623D7 30 ntdll.TppWorkerThread+2F7 System
00000076EB5FF978 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EB5FF9F8 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
2468
00000076EBBFFB78 00007FFEC900A34E 00007FFECB4EC034 A0 ntdll.NtWaitForSingleObject+14 System
00000076EBBFFC18 00007FF7987B48A1 00007FFEC900A34E 30 kernelbase.WaitForSingleObjectEx+8E User
00000076EBBFFC48 00007FF7988961A0 00007FF7987B48A1 30 mylibrarydll0.00007FF7987B48A1 User
00000076EBBFFC78 00007FF7987B13DF 00007FF7988961A0 30 mylibrarydll0.00007FF7988961A0 User
00000076EBBFFCA8 00007FF798B4A175 00007FF7987B13DF 30 mylibrarydll0.00007FF7987B13DF User
00000076EBBFFCD8 00007FFECA637034 00007FF798B4A175 30 mylibrarydll0.sub_7FF798B4A0B4+C1 System
00000076EBBFFD08 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EBBFFD88 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
3784
00000076EB6FFB88 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14 System
00000076EB6FFE88 00007FFECA637034 00007FFECB4623D7 30 ntdll.TppWorkerThread+2F7 System
00000076EB6FFEB8 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EB6FFF38 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
1928
00000076EB7FFA48 00007FFEC900A34E 00007FFECB4EC034 A0 ntdll.NtWaitForSingleObject+14 System
00000076EB7FFAE8 00007FF7987B48A1 00007FFEC900A34E 30 kernelbase.WaitForSingleObjectEx+8E User
00000076EB7FFB18 00007FF7988961A0 00007FF7987B48A1 30 mylibrarydll0.00007FF7987B48A1 User
00000076EB7FFB48 00007FF7987B13DF 00007FF7988961A0 30 mylibrarydll0.00007FF7988961A0 User
00000076EB7FFB78 00007FF798B4A175 00007FF7987B13DF 30 mylibrarydll0.00007FF7987B13DF User
00000076EB7FFBA8 00007FFECA637034 00007FF798B4A175 30 mylibrarydll0.sub_7FF798B4A0B4+C1 System
00000076EB7FFBD8 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EB7FFC58 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
2276
00000076EB8FF7C8 00007FFEC900A34E 00007FFECB4EC034 A0 ntdll.NtWaitForSingleObject+14 System
00000076EB8FF868 00007FF7987B48A1 00007FFEC900A34E 30 kernelbase.WaitForSingleObjectEx+8E User
00000076EB8FF898 00007FF7988961A0 00007FF7987B48A1 30 mylibrarydll0.00007FF7987B48A1 User
00000076EB8FF8C8 00007FF7987B13DF 00007FF7988961A0 30 mylibrarydll0.00007FF7988961A0 User
00000076EB8FF8F8 00007FF798B4A175 00007FF7987B13DF 30 mylibrarydll0.00007FF7987B13DF User
00000076EB8FF928 00007FFECA637034 00007FF798B4A175 30 mylibrarydll0.sub_7FF798B4A0B4+C1 System
00000076EB8FF958 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EB8FF9D8 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
12168
00000076EB9FF6E8 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14 System
00000076EB9FF9E8 00007FFECA637034 00007FFECB4623D7 30 ntdll.TppWorkerThread+2F7 System
00000076EB9FFA18 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EB9FFA98 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
2428
00000076EBAFF5D8 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14 System
00000076EBAFF8D8 00007FFECA637034 00007FFECB4623D7 30 ntdll.TppWorkerThread+2F7 System
00000076EBAFF908 00007FFECB49D0D1 00007FFECA637034 80 kernel32.BaseThreadInitThunk+14 System
00000076EBAFF988 0000000000000000 00007FFECB49D0D1 ntdll.RtlUserThreadStart+21 User
- 所涉及的术语在常用行话中不一定有准确的定义。您链接的 x64dbg 文档给出了这些定义：
Thread Entry
Set a single-shoot breakpoint on the entry of the thread when a thread is about to run.
和
Thread Start
Pause when a new thread is about to run.
这些是调试器为它可以提醒您的明显不同类型的事件选择的标签。我的解释与你在问题中描述的一致，是“线程启动”是关于创建一个新线程，显然是在创建线程的上下文中，而“线程进入”是关于执行将 运行 在新线程中的代码，大概在该线程的上下文中。
我倾向于认为，在这些术语中，线程启动必须始终发生在线程进入之前。在线程启动之前，执行不能进入该线程的代码。事实上，我倾向于猜测线程启动事件是调试器可以发出信号的最后一个事件，它肯定发生在相关线程的线程进入之前。
在一般意义上，我希望线程入口地址是线程入口点函数的地址，或者线程主体中第一条指令的地址（不一定是同一事物）。对于不同的入口点函数，这不能期望是一致的，并且对于程序的不同 运行s 上的相同函数，它可能不相同。如果您认为自己看到了其他内容，请查阅该工具的文档。
Windows 向调试器发送一组特定的事件，您可以在 WaitForDebugEvent.
的文档中找到它们
其中一个事件是 CREATE_THREAD_DEBUG_INFO、，它在 Windows 已创建但尚未启动线程 时发送。
在 Windows 中，进程和线程的创建发生在内核中，但它们的最终初始化步骤发生在用户空间中（除非它是一个微进程，我们不会在这里讨论）。 DLL ntdll.dll 在创建后立即映射到线程中，并且线程上下文的 RIP 设置为指向此 DLL 的函数之一。
此函数将执行必要的初始化，然后跳转到 CreateThread 或类似地址中给出的地址。这个函数是线程的一种包装器。
thread start发生在初始化函数的第一条指令即将执行时（可以把它想象成Windows设置了一个断点那里）。
相反，线程条目 只是提供给线程创建的地址API。它很重要，因为它是调用者打算执行的实际代码。事实上，出于调试或 RE 目的，您几乎可以（如果不是总是）忽略线程启动事件。
我们来举个例子。考虑这个简单的 64 位程序。
BITS 64
EXTERN CreateThread
GLOBAL _start
SECTION .text
_start:
and rsp, -16
push 0
push 0
sub rsp, 20h
xor r9, r9
lea r8, [REL _thread1]
xor edx, edx
xor ecx, ecx
call CreateThread
.loop:
TIMES 1000 pause
jmp .loop
_thread1:
TIMES 1000 pause
jmp _thread1
它所做的只是创建一个线程，指向在循环中执行的 pause 条指令。主线程也会执行类似但不同的循环。
循环的目的是让线程的 RIP 发生变化，但仍然不在 Windows API 内。循环中的任何指令，如果没有错误，都可以。我选择 pause，因为 :)
Assemble 和 link 程序。
打开x64dbg，打开程序，然后设置Thread start和Thread entry事件。
现在按F9到达程序入口点，再按F9放手。调试器将收到新线程创建的通知。
请注意，执行在 RtlUserThreadStart 开始时停止。我的 Windows 版本总是这样（Windows 7 something）。鉴于此答案开头的介绍，这是有道理的。
另请注意，线程入口点在 rcx 中，这意味着它是 RtlUserThreadStart.
现在，这是 Windows 发送给调试器的事件，因此执行到此停止是很自然的。
但是线程入口事件不存在，x64dbg在这里做什么？
您可以通过查看断点选项卡来揭开这个谜团。
您看到调试器在线程入口点设置了一个一次性（即它会被调试器本身自动删除）断点。
因此，虽然 Windows 不支持在线程首次开始执行其用户代码时生成调试事件，但调试器可以通过在线程实际启动之前放置一个断点来轻松模拟它。
请注意，这意味着调试器总是对线程启动事件做出反应，当在选项中禁用时，它不会停止，显示并等待您做某事。
暂停和恢复线程不会更改线程入口点，线程入口点在线程创建时固定。
x64dbg 有一个线程选项卡，允许用户挂起和恢复线程。使用它不会改变线程入口点，只是仍然指向两个循环中某处的 RIPs（为了简化此测试而存在）。
如果线程是使用挂起标志创建的，线程启动事件将在线程恢复之前不会触发。
但是，如果在恢复线程之前，完成了对 Get/SetThreadContext 的一对调用以更改线程的 RIP，那么 RtlUserStartThread 将永远不会被执行（我不知道这个函数到底做了什么，但是线程可以没有它）并且线程启动事件永远不会触发。
执行将直接转到更改后的 RIP.
我不确定这是否是 Windows' 调试界面的遗留错误，可以通过在线程的第一个调度之前设置 TF 来生成线程启动事件（并在捕获时立即删除它相关例外）。
当debugging/REing线程时，我通常做的是在线程入口点（很容易获取）或者被劫持的RIP（也很容易获取，因为这种线程被创建为暂停，所以你知道有些东西是可疑的）。
如果程序很糟糕并且线程 RIP 处的代码尚不清楚（例如，仍然被混淆），请使用硬件断点。
注意同样的事情也发生在进程创建上，完全一样（只是使用 PE 入口点而不是线程入口点）。