在完全更新的 Win7 x64 上，系统时不时会停滞一分钟左右。这种情况已经持续了几个月。停滞是指鼠标有反应，我可以移动窗口，但任何打开的窗口、任何程序，当我选择它时都会变成白色，并且任何新程序都不会打开。不管是什么类型的程序。当停滞停止时，我所做的所有点击（例如打开新程序）都会生效。
事件日志中没有持续显示任何内容（每次发生这种情况时都是这样）。今天我找到了一些东西，但除了“系统无响应”之外，没有显示太多信息。它显示为 7009，表示“等待 Windows 错误报告服务连接时超时（30000 毫秒）。“
我是否插入任何 USB 设备都没关系。我已经运行了 Microsoft Security Essentials 和 Malwarebytes。
当机器没有响应时，我注意到 D 盘（这台笔记本电脑中单个内置硬盘上的另一个分区）在资源管理器中显示如下。C 盘或机器上的任何其他盘从未出现过这种情况
。
物理驱动器的 SMART 报告：
通过 HD Tune 5 Pro 读取基准测试，这可能是最能说明问题的一块拼图。难道这还不足以说明驱动器存在问题吗，无论无响应是否由这种所谓的问题引起？ 
以下是一份简短的硬件报告：
Computer: LENOVO ThinkPad T520
CPU: Intel Core i5-2520M (Sandy Bridge-MB SV, J1)
2500 MHz (25.00x100.0) @ 797 MHz (8.00x99.7)
Motherboard: LENOVO 423946U
Chipset: Intel QM67 (Cougar Point) [B3]
Memory: 8192 MBytes @ 664 MHz, 9.0-9-9-24
- 4096 MB PC10600 DDR3 SDRAM - Samsung M471B5273CH0-CH9
- 4096 MB PC10600 DDR3 SDRAM - Patriot Memory (PDP Systems) PSD34G13332S
Graphics: Intel Sandy Bridge-MB GT2+ - Integrated Graphics Controller [D2/J1/Q0] [Lenovo]
Intel HD Graphics 3000 (Sandy Bridge GT2+), 3937912 KB
Drive: ST320LT007, 312.6 GB, Serial ATA 3Gb/s
Sound: Intel Cougar Point PCH - High Definition Audio Controller [B2]
Network: Intel 82579LM (Lewisville) Gigabit Ethernet Controller
Network: Intel Centrino Advanced-N 6205 AGN 2x2 HMC
OS: Microsoft Windows 7 Professional (x64) Build 7601
该硬盘使用不到 1 年。我的硬盘有缺陷吗？Seagate Tools 诊断显示硬盘没有问题...
更新：我注意到 Windows 错误报告服务进入了运行状态，然后进入了停止状态，两个事件之间的间隔正好是 2 分钟。我不知道它试图报告哪个错误。我检查了“可靠性监视器”，它显示没有要报告的错误。我已禁用 Windows 错误报告服务，看看问题是否停止。
答案1
根据您提供的新信息，我可以说实际上根本没有问题。那么为什么在暂停客户操作系统后它会“离线”几秒钟，最长可达三分钟？因为正如您所说，由于硬盘使用频繁，硬盘 LED 灯保持亮起，而硬盘保持无响应。
实际情况是，当您使用完 VMWare 并希望让客户操作系统休眠时，您使用的是待机或休眠功能，而不是关闭。这会导致 VMWare 将 VM 的 RAM 内容复制到磁盘，以便它可以从中断的地方恢复，而无需重新启动。根据您为 VM 分配的内存量以及使用的内存量，这可能意味着 VMWare 必须将大量数据（千兆字节）写入磁盘。
当 VMWare 将内存复制到磁盘时，驱动器或多或少会变得对新的磁盘操作没有响应，直到当前磁盘操作（将 RAM 写入文件）完成。因此，当您打开我的电脑，Windows 尝试刷新数据，但无法读取驱动器以获取所需数据，因为所有写入命令都已排队等待执行。因此，它将其留空并看起来像处于离线状态，直到它能够设法插入这些读取请求（在 VMWare 的写入操作之间）。
如果您在资源管理器中打开该驱动器，您将看到它要么在一段时间内根本无法打开它，要么会打开它并在地址栏中闪烁绿色进度条，就像每次进行冗长的文件操作（例如搜索数千个文件）时一样。
总而言之，这种情况没有什么令人惊讶或神秘的。如果您没有将 VMWare 客户操作系统置于待机状态，而是手动将一个巨大的文件复制到驱动器，结果将完全相同。
那么你能做些什么来解决这个问题呢？除了换一个更快的驱动器（如果D:是外置驱动器，则使用内置驱动器）之外，最好的办法是对驱动器进行碎片整理。如果D:碎片太多，那么当 VMWare 尝试将 RAM 刷新到磁盘时，会导致驱动器乱七八糟很多同时将巨型文件的块写入不同区域（当然这是假设它不是 SSD，如果它D:仍然是同一个 0ST320LT007 驱动器上的分区C:，那么它就不是）。
如果对驱动器进行碎片整理（假设有足够的可用空间），则系统可以仅使用大范围的少量文件操作（例如write 1GB of data at cluster X）来写入 RAM 文件，而不是执行许多小操作（write 1MB here、、、…… ）然后write 245.18MB there，VM 的睡眠过程将更快完成，驱动器的响应也将更快。4KB hereanother 18.1MB somewhere else
要准确找出导致驱动器处于活动状态且繁忙的访问，您可以使用类似进程监控。运行它并单击类过滤器以仅选择文件类过滤器，如下所示。
现在您可以看到正在访问哪些文件和文件夹。请务必记住启动和停止活动捕获的热键 ( Ctrl+ E)，以便在开始充斥可能是来自 VMWare 的磁盘操作时可以停止它。
答案2
所描述的症状确实是坏驱动器的常见症状。当磁盘没有响应时，系统会等待看似无法估量的时间，然后才会超时并抛出错误。
话虽如此，奇怪的是它似乎只发生在D:卷上（您暗示它是与 位于同一物理驱动器上的分区C:）。如果是软件问题（例如， 上的文件系统损坏D:），那么它不应该间歇性发生，而硬件问题确实可能会间歇性发生，例如，如果盘片内部只有几个坏扇区并且系统只是偶尔碰到它们。当然你已经说过 HD Tune 没有报告任何坏扇区。但是，正如您所想，现代驱动器确实会隐藏坏扇区。它们通常有许多备用扇区可以将坏扇区重新映射到这些扇区，是的，它们以透明的方式执行此操作，以便操作系统不知道它们（除了通过 SMART 的一般信息）。
如果数据列报告的是原始数据，那么是的，2,465 个重新定位的扇区数量很多。如果只发生在 上D:，那么坏扇区可能集中在磁头停放的盘片中心，因此驱动器可能在关闭/旋转时受到挤压。
该卷的用途是什么？如果它用于存储目录temp等，操作系统或程序偶尔会访问它，那么它可以是一个损坏的文件系统（当然你说你运行了chkdsk，所以它应该不是）。
您可以通过打开事件查看器 ( eventvwr.exe) 并检查System日志中的事件来检查/确认这是否是驱动器的物理问题来源的Disk。您可以在磁盘管理MMC 管理单元 ( diskmgmt.msc)。
答案3
问题已追溯到 VMWare Player。VMWare 客户操作系统关闭后不久就会发生这种情况。更多信息这里。
在我的案例中，解决方案是禁用 VMware 授权服务。仅当虚拟机需要由非管理员运行时才需要此服务。
更新：禁用 VMware auth 服务并重新启用应用程序体验服务（我已将其禁用，因为我认为它没有必要）解决了该问题。
即使我更换了硬盘，D: 驱动器仍会“离线”几秒钟。这不会导致整个机器无响应，只有依赖于存储在 D: 上的数据的特定应用程序（如我的配置中的 Outlook）才会无响应。我将把 D: 驱动器离线问题视为一个单独的问题。
答案4
从您提供的信息来看，这个问题很难诊断（信息量很大，别误会我的意思）。诊断硬件问题的一种方法是尝试通过 Linux 安装重现该问题，例如通过 wubi。
我曾见过硬盘上有坏扇区时发生类似的事情。但我也见过因驱动程序故障而导致的类似问题。
您是否尝试过 CHKDSK 并扫描坏扇区？