用户模式调试比内核模式调试有优势吗？
Is There Ever an Advantage to User Mode Debug over Kernel Mode Debug?
据我了解，在较高层次上，用户模式调试使您可以访问进程的私有虚拟地址。调试会话仅限于该进程，它不能覆盖或篡改其他进程的虚拟地址 space/data.
内核模式调试，据我所知，除了原始进程地址 space.
之外，还提供对其他需要完全访问多个资源的驱动程序和内核进程的访问
由此，我开始认为内核模式调试似乎比用户模式调试更健壮。这对我提出了一个问题：是否有一段时间，当两种调试模式选项都可用时，选择用户模式而不是更健壮的内核模式是否有意义？
我对这个概念还很陌生，所以我可能对这两种模式的理解有误。我也很感激那里的任何见解，以更好地理解我可能遗漏的任何内容。我只是注意到很多人似乎都在试图避免内核调试。我不完全确定为什么，因为它看起来更强大。
以下主要来自Windows背景，不过我想Linux应该也可以。概念没有太大区别。
首先是一些内联答案
From what I understand, on a high level, user mode debugging provides you with access to the private virtual address for a process.
正确。
A debug session is limited to that process
没有。您可以同时附加到多个进程，例如使用 WinDbg 的 .tlist/.attach 命令。
and it cannot overwrite or tamper w/ other process' virtual address space/data.
没有。您可以修改内存，例如使用 WinDbg 的 ed 命令。
Kernel mode debug, I understand, provides access to other drivers and kernel processes that need full access to multiple resources,
正确。
in addition to the original process address space.
据我所知，您只能访问物理 RAM。某些虚拟地址 space 可能会被交换，因此无法使用完整地址 space。
From this, I get to thinking that kernel mode debugging seems more robust than user mode debugging.
我认为恰恰相反。如果您在内核模式的某处写入不正确的值，PC 会崩溃并出现蓝屏。如果您在用户模式下执行此操作，则只有应用程序会崩溃。
This raises the question for me: is there a time, when both options of debug mode are available, that it makes sense to choose user mode over a more robust kernel mode?
如果只调试应用程序，不涉及驱动程序，我更喜欢用户模式调试。
恕我直言，内核模式调试并不更健壮，它更脆弱——你真的可以在最低级别上破坏一切。用户模式调试提供了针对 OS.
崩溃的典型保护
I just seem to notice that a lot of people seem to try to avoid kernel debugging
我也观察到同样的情况。一旦他们尝试了，通常就不会那么困难了。在我的调试研讨会上，我从内核的角度解释进程和线程，并在内核中进行。一旦人们尝试内核调试，它就不再那么神秘了。
I'm not entirely sure why, as it seems more robust.
好吧，你真的可以在内核模式下炸毁一切。
用户模式调试
用户模式调试是任何 IDE 都会执行的默认设置。集成通常很好，在某些 IDE 中感觉很原生。
在用户模式调试期间，事情很简单。如果您访问被分页到磁盘的内存，OS 仍然是 运行 并且只会将其分页，因此您可以读取和写入它。
您可以访问您从应用程序开发中了解到的一切。有线程，您可以暂停或恢复它们。您从应用程序开发中获得的知识足以操作调试器。
您可以设置断点和检查变量（只要您有正确的符号）。
某些类型的调试仅在用户模式下可用。例如。用于 WinDbg 调试 .NET 应用程序的 SOS 扩展仅在用户模式下有效。
内核调试
内核调试相当复杂。通常，您不能简单地进行本地内核调试 - 如果您在内核的某个地方停止，您如何控制调试器？系统只会冻结。因此，对于内核调试，您需要 2 台 PC（或虚拟 PC）。
在内核模式调试期间，事情很复杂。当你只是在一个应用程序中时，一毫秒后，一些中断发生并做一些完全不同的事情。您不仅有线程，还需要处理应用程序外部的调用堆栈，您会看到 CPU 寄存器内容、指令指针等。这些都是 "normal" 应用程序开发人员所做的事情不想理会。
您不仅可以访问您实施的所有内容。您还可以访问 Microsoft、Intel、NVidia 和许多其他公司开发的所有内容。
你不能简单地访问所有内存，因为一些被调出到交换文件的内存将首先产生一个页面错误，然后涉及一些磁盘驱动程序来获取数据，可能调出一些其他数据，等等
内核模式中有很多内容，为了不破坏它，您需要对所有这些主题有真正专业的理解。
结论
大多数开发者只想关心他们的源代码。因此，如果他们正在编写程序（又名应用程序、脚本、工具、游戏），他们只需要用户模式调试。如果"their code"是驱动代码，当然要内核调试了。
当然，安全专家和破解者需要内核模式调试，因为他们需要特权。
据我了解，在较高层次上，用户模式调试使您可以访问进程的私有虚拟地址。调试会话仅限于该进程，它不能覆盖或篡改其他进程的虚拟地址 space/data.
内核模式调试，据我所知，除了原始进程地址 space.
之外，还提供对其他需要完全访问多个资源的驱动程序和内核进程的访问由此，我开始认为内核模式调试似乎比用户模式调试更健壮。这对我提出了一个问题：是否有一段时间，当两种调试模式选项都可用时，选择用户模式而不是更健壮的内核模式是否有意义？
我对这个概念还很陌生，所以我可能对这两种模式的理解有误。我也很感激那里的任何见解，以更好地理解我可能遗漏的任何内容。我只是注意到很多人似乎都在试图避免内核调试。我不完全确定为什么，因为它看起来更强大。
以下主要来自Windows背景，不过我想Linux应该也可以。概念没有太大区别。
首先是一些内联答案
From what I understand, on a high level, user mode debugging provides you with access to the private virtual address for a process.
正确。
A debug session is limited to that process
没有。您可以同时附加到多个进程，例如使用 WinDbg 的 .tlist/.attach 命令。
and it cannot overwrite or tamper w/ other process' virtual address space/data.
没有。您可以修改内存，例如使用 WinDbg 的 ed 命令。
Kernel mode debug, I understand, provides access to other drivers and kernel processes that need full access to multiple resources,
正确。
in addition to the original process address space.
据我所知，您只能访问物理 RAM。某些虚拟地址 space 可能会被交换，因此无法使用完整地址 space。
From this, I get to thinking that kernel mode debugging seems more robust than user mode debugging.
我认为恰恰相反。如果您在内核模式的某处写入不正确的值，PC 会崩溃并出现蓝屏。如果您在用户模式下执行此操作，则只有应用程序会崩溃。
This raises the question for me: is there a time, when both options of debug mode are available, that it makes sense to choose user mode over a more robust kernel mode?
如果只调试应用程序，不涉及驱动程序，我更喜欢用户模式调试。
恕我直言，内核模式调试并不更健壮，它更脆弱——你真的可以在最低级别上破坏一切。用户模式调试提供了针对 OS.
崩溃的典型保护I just seem to notice that a lot of people seem to try to avoid kernel debugging
我也观察到同样的情况。一旦他们尝试了，通常就不会那么困难了。在我的调试研讨会上，我从内核的角度解释进程和线程，并在内核中进行。一旦人们尝试内核调试，它就不再那么神秘了。
I'm not entirely sure why, as it seems more robust.
好吧，你真的可以在内核模式下炸毁一切。
用户模式调试
用户模式调试是任何 IDE 都会执行的默认设置。集成通常很好，在某些 IDE 中感觉很原生。
在用户模式调试期间，事情很简单。如果您访问被分页到磁盘的内存，OS 仍然是 运行 并且只会将其分页，因此您可以读取和写入它。
您可以访问您从应用程序开发中了解到的一切。有线程，您可以暂停或恢复它们。您从应用程序开发中获得的知识足以操作调试器。
您可以设置断点和检查变量（只要您有正确的符号）。
某些类型的调试仅在用户模式下可用。例如。用于 WinDbg 调试 .NET 应用程序的 SOS 扩展仅在用户模式下有效。
内核调试
内核调试相当复杂。通常，您不能简单地进行本地内核调试 - 如果您在内核的某个地方停止，您如何控制调试器？系统只会冻结。因此，对于内核调试，您需要 2 台 PC（或虚拟 PC）。
在内核模式调试期间，事情很复杂。当你只是在一个应用程序中时，一毫秒后，一些中断发生并做一些完全不同的事情。您不仅有线程，还需要处理应用程序外部的调用堆栈，您会看到 CPU 寄存器内容、指令指针等。这些都是 "normal" 应用程序开发人员所做的事情不想理会。
您不仅可以访问您实施的所有内容。您还可以访问 Microsoft、Intel、NVidia 和许多其他公司开发的所有内容。
你不能简单地访问所有内存，因为一些被调出到交换文件的内存将首先产生一个页面错误，然后涉及一些磁盘驱动程序来获取数据，可能调出一些其他数据，等等
内核模式中有很多内容，为了不破坏它，您需要对所有这些主题有真正专业的理解。
结论
大多数开发者只想关心他们的源代码。因此，如果他们正在编写程序（又名应用程序、脚本、工具、游戏），他们只需要用户模式调试。如果"their code"是驱动代码，当然要内核调试了。
当然，安全专家和破解者需要内核模式调试，因为他们需要特权。