如 cmets 中所述，默认情况下禁用内核调试，因为它允许（即使在 64 位 Windows 上）加载非真正签名（自签名）的内核驱动程序。 （以及禁用 PatchGuard 等）
当然，关于“管理员仍然生活在用户空间”的评论是无稽之谈。评论者应该继续阅读Raymond Chen关于“beingontheothersideofthisairtighthatchway”的帖子。请允许我用他的话：
我想你知道这个故事的结局。如果您有管理员权限，那么您已经在密闭舱口的另一边。您可以使用管理员权限来 pwn 这台机器并不有趣，因为作为管理员，您已经 pwn 了这台机器。
Administrator 和 SYSTEM 之间在形式上是有区别的，因为它们是 ACL 的一些东西，因此 SYSTEM 可以执行它们而不是任意管理员，但这种区别是正式的而不是实际的。想要让某些代码以 SYSTEM 身份运行的管理员可以安装以 SYSTEM 身份运行的服务。或者使用 Debug Privilege 接管作为 SYSTEM 运行的进程（例如，服务）。或者只需以 SYSTEM 身份打开命令提示符并前往城镇。无需通过复杂的操作Q来获得SYSTEM权限。
如果您将 SYSTEM 替换为内核模式驱动程序，则第一句话成立。
您在删除的评论中说管理员可以加载驱动程序是正确的，但在 x64 上必须对其进行签名。
能够加载未签名的驱动程序为您节省的不是 75 美元或填写在线表格，而是提供可证明的身份。内核模式代码签名证书与域验证 SSL 证书不同。
请注意，Microsoft打算要求内核模式驱动程序经过 WHQL 认证（或使用“证明签名”，据说仅在非服务器 SKU 上），这需要将驱动程序提交给 Microsoft，并且使用 EV 证书打开 Windows 硬件开发人员帐户。嘿！那是怎么回事？这是与 CA 勾结，让我们为证书支付更多费用的阴谋吗？可能是。也许他们想确定你的身份，并将验证委托给 CA（假设 EV 做了它应该做的事情）。
在安全方面，这并没有建立真正的安全边界，而是一种温和的缓解措施。但还有其他考虑：微软不希望软件发行商安装糟糕的驱动程序，从而使 Windows 随他们一起崩溃。而且，如果他们碰巧这样做了，微软想知道是谁编写了这些驱动程序。这就是证明签名背后的基本原理。
如果您可以轻松启用内核调试，那么您可以打赌，一些二流的 ISV 会编写糟糕的驱动程序，而无需费心对其进行测试或签名，并且会使用该 hack 来安装它。 （实际上，我今天知道一些不太糟糕的 ISV 签署了他们的驱动程序但没有 WHQL 认证它们，并使用黑客在没有任何提示的情况下安装它们。这是真实的。）
当然，同样糟糕的 ISV 可以在其安装程序（运行提升）中启用内核调试，并且可以在下次重新启动后加载其驱动程序。但是桌面上有一条烦人的消息说你正在测试签名模式下运行以保护你免受这种情况的影响。当然，同样糟糕的 ISV 可以四处乱窜并隐藏消息，但此时获取证书可能更容易。这并没有阻止任何事情，但它通过让它变得足够烦人来缓解他们的烦恼。
如果您想知道为什么启用内核调试会使您进入测试签名模式，答案是：因为这是通常的预期场景。即使在内核调试时，您也可以更改注册表值以要求生产签名，但这是例外情况。对于常见场景，默认值是正确的。你有 LiveKD。微软没有理由向后弯腰来处理一个没有真正发生的场景。他们有足够的问题。就像在 Microsoft Edge 中修复所有这些崩溃一样。