![Win7 x64 一分钟左右无响应。高清故障?](https://linux22.com/image/1336255/Win7%20x64%20%E4%B8%80%E5%88%86%E9%92%9F%E5%B7%A6%E5%8F%B3%E6%97%A0%E5%93%8D%E5%BA%94%E3%80%82%E9%AB%98%E6%B8%85%E6%95%85%E9%9A%9C%EF%BC%9F.png)
在完全更新的 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 here
another 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 并扫描坏扇区?