概括：
我遇到了卷损坏：具体来说，这是chkdsk第 3 阶段错误。在第 3 阶段，Chkdsk验证安全描述符和 USN 日志。但是，chkdsk /fWindows 重启时修复无法运行。
细节：
我已经运行了chkdsk。它报告没有问题。但是，当我运行chkdsk /scan，对 NTFS 文件系统执行进一步检查时，我在第 3 阶段收到错误。chkdsk 过程的第 3 阶段验证安全描述符和 USN 日志（USN = 唯一序列号）。 Chkdsk报告以下消息：
“Windows 发现必须离线修复的问题。请运行“chkdsk /f”来修复该问题。”
当我fsutil dirty query在命令提示符下执行时，得到结果：“
卷 C：很脏
这意味着该卷已设置脏位，标记驱动器已损坏且需要修复chkdsk。
但是，当我尝试在下次重新启动 Windows 时运行时chkdsk /f，我收到消息“正在扫描和修复”，但没有看到任何进度百分比来表明正在进行修复。Windows 成功启动并执行此操作迅速地进一步表明修复未运行。当我fsutil dirty query再次运行时，我发现脏位仍然设置，并且运行 chkdsk /scan 继续报告第 3 阶段错误。
每次启动 Windows 时，我都会看到“正在扫描和修复驱动器 (c:)。每次启动时，Windows 都会检测脏位并尝试运行修复，但甚至无法开始修复（因为我没有看到任何进度指示器）。
其中一个症状是我无法进行备份（具体来说，我使用失败的旧版 Windows 7 备份），因为 Windows 报告备份失败，因为我的磁盘已损坏。当备份因卷损坏而失败时，我相信，这表明 NTFS USN 日志存在问题（我只是猜测）。
我读到，当 NTFS 日志损坏时，chkdsk /f 和 defrag 可能无法运行，而日志重置可以解决此问题。这可以通过fsutil usn deletejournal在具有管理员权限的命令提示符下运行命令来完成。可能需要应用 /d /n 开关，然后通过运行命令重新创建日志fsutil usn createjournal。但是，我不知道删除日志是否安全。此外，我不确定开关：/d 似乎禁用了日志。这是永久性的吗？我甚至不知道这是什么意思。
要重新创建日志，需要提供各种参数fsutil usn createjournal，但我不知道它们应该是什么或如何正确运行该命令。
还请注意：我在此推测删除并重新创建 NTFS 日志是一种可能的解决方案。
有人能为我的问题提出一些解决方案吗？谢谢。
答案1
好的，为了其他人的利益，我将向您提供我所获得的所有知识，这些知识帮助我解决了这个问题。
就我的情况而言，每次 Windows 启动时，chkdsk 都无法在我的计算机上执行修复。设置了脏位后，Windowschkdsk /f每次启动时都会尝试执行修复，但修复执行失败。我怀疑原因可能是我的计算机相当新，驱动器上启用了 BitLocker 加密。因此，当我重新启动 PC 时，chkdsk 会失败，因为在启动 chkdsk 时驱动器仍处于 RAW 和加密状态。如果我没记错的话，那么随着带有加密驱动器的计算机的销售成为常态，这可能会成为一个越来越普遍的问题。微软也需要重新审视这个问题。由于加密阻止 chkdsk 在 Windows 启动时运行，因此需要重新审视其在主驱动器上执行 chkdsk 的工作方式的设计。
我听从了@的建议tsc_chazz并启动到命令提示符，然后chkdsk /f从那里运行。砰！问题解决了！我简直不敢相信，它成功了！当然，由于驱动器已加密，我必须提供 48 个字符的加密密钥（我对此一无所知，必须通过 Microsoft 获取aka.ms/myrecoverykey）。在第一次尝试时，我跳过了要求输入恢复密钥（即：bitlocker 加密密钥）的页面，当我尝试chkdsk /f从启动到命令提示符环境运行时，收到错误消息。Chkdsk 失败，指出卷的类型为 RAW，并且 chkdsk 不能在 RAW 卷上运行。
所有这些还表明，在驱动器外部安装时，任何尝试在驱动器上运行 chkdsk 的操作也可能会失败。例如，如果我要启动到 USB 恢复磁盘并从此恢复环境在我的主分区上运行 chkdsk，它也会失败，因为驱动器仍然处于加密状态。解决这个问题的方法是事先通过控制面板关闭驱动器上的 BitLocker。请参阅指南这里。驱动器的解密过程可能需要很长时间。但是，此步骤不是必需的，因为启动到命令提示符会将您带到不同的驱动器（在我的情况下是 X:），从而允许您chkdsk /f在主分区上运行（通常是 c: 驱动器）。
因此，总而言之，启动到命令提示符并在解密驱动器的过程中输入恢复密钥，然后chkdsk /f从那里运行，为我解决了这个问题。此外，无需运行chkdsk /r。这需要更长的时间（数小时到数天），并且通常没有必要，因为物理问题（坏簇）不太可能是损坏的罪魁祸首或原因。
但是，如果这不起作用，我将重新创建 NTFS 文件系统的 USN 日志。这是因为 chkdsk 第 3 阶段损坏与这些日志的损坏有关 - 我猜想 USN（更新序列号）会出现问题。据指出，这种损坏本身可能是 chkdsk 无法运行的原因。此处的损坏还可能导致备份和碎片整理失败。运行备份（例如 Windows 7 备份）时，您可能会看到一条错误消息，内容如下...
以下文件的备份失败，因为它们位于 损坏的驱动器 c:
要重新创建 NTFS USN 日志，请先删除日志，然后重新创建日志。
删除日志
您可以使用以下方法删除 NTFS USN 日志...
fsutil usn deletejournal /d /n c:
如果您使用 /n 开关，此操作可能需要数小时才能运行，并且会“锁定您的 PC”直至完成。因此，您也可以省略 /n 开关，它会在后台删除日志，并在必要时重新启动。
/d 和 /n 开关的文档记录不全。Microsoft 文档这里与在命令提示符下查询命令的使用时显示的信息相冲突：
两者都不准确！命令提示符文档是错误的，因为两个开关都会删除日志，而不仅仅是 /d。Microsoft 网页文档具有误导性，因为日志实际上是被删除而不是禁用。开关指示了如何删除它。
由于删除日志可能需要很长时间，因此开关允许您控制它是在进程内运行还是在进程外运行。/n 开关在进程中执行 deletejournal 并锁定它的句柄（将其视为“锁定计算机”）。这会迫使您等到它完成。/d 开关在进程外执行并允许您继续工作。删除日志可能需要几个小时才能运行，并且会在连续重新启动后继续运行，直到完成。我见过有人在两个开关互斥时同时应用这两个开关。
删除日志几乎总是安全的，但有时会对备份过程产生影响。使用日志的应用程序将看不到上次运行应用程序和删除日志之间的文件更改。编程良好的应用程序将检测到日志已被删除，并将恢复到查找更改文件的替代方法或重新创建它。我建议尽管有后果，但删除是安全的，因为在最坏的情况下，您只会损害备份的增量能力。您仍然可以进行完整备份并重新开始；至少您的数据没有丢失！
重建日记
我被告知不需要手动重新创建日志，只需通过控制面板运行备份程序（例如 Windows-7 备份选项）即可（尽管名称不同，但此选项在 Windows 8/8.1 和 10 上也可用）将自动重新创建 NTFS 日志。
如果要手动重新创建日志，请在命令提示符下运行：
fsutil usn createjournal m=536870912 a=67108864 C:
...如果您有一个非常大的驱动器（4TB+，包含400,000+个文件）；
或者对于文件较少的较小驱动器，运行：
fsutil usn createjournal m=67108864 a=8388608 C:
如果您好奇这些数字的来源，它们是位状态数的充分幂，可提供日志日志的字节大小。IE：这些数字是 2^x，可给出精确的大小以字节为单位大约是您想要的大小。日志的大小通常保持在 30Mb 到 40MB 之间。因此，我将 maxSize (m) 参数设置为下一个最高可用大小 (67Mb)：
2^25 字节 x 2 = 33Mb x 2 = 67Mb
分配增量 (a) 参数需要约为 m 的 1/8，即 8Mb 左右。您在互联网上其他任何地方都找不到此解释！！！尤其是微软，可耻地未能充分记录这两个日志命令的使用。
仅供参考：您可以通过在提升的权限下在命令提示符下键入以下命令来查询日志的当前大小：
C:\Windows\system32> fsutil usn queryjournal C:
您将获得类似这样的输出：
和参数am以字节为单位，以十六进制表示。对于我的 Windows 8.1 PC，其主分区为 2TB，其值等于：
m = 33,554,432 字节 = 33Mb
a = 8,388,608 字节 = 8Mb
您可以通过在提升权限的命令提示符下执行以下命令来查询系统上的文件数量：
C:\Windows\system32> dir C:\ /s /a /w
您将看到如下输出...
将文件和目录的数量加在一起，得到总数；本例中为 1,616,718。
然后，您可以使用下表（转载自这一页) 作为替代指南来查找最大大小和分配增量的适当值。
答案2
我认为在这种情况下你可能必须认真对待。如果是我的系统，我要做的第一件事是尝试返回命令提示符 - 在登录屏幕上，按住 Shift 并选择重新启动；启动修复你的电脑，转到高级页面并启动命令提示符 - 确认包含实时 Windows 安装的磁盘号，然后chkdsk /f从那里开始。或者，可以拔出磁盘，并使用 USB/SATA 适配器将其作为外部设备连接到其他可以执行的机器chkdsk。我不愿意建议从 Linux 发行版启动并运行 Linux fsck，因为虽然它们的 NTFS 实现非常好，但可能缺少一些更精细的细节。