Well, solved is a bit of an overstatement, but the disk problem has been determined and we can’t do more about it.

disk error The device Device Harddisk1DR1 is not ready for access yet
07:00 The device, \Device\Harddisk1\DR1, is not ready for access yet.
10:00 The device, \Device\Harddisk1\DR5, is not ready for access yet.
13:00 The device, \Device\Harddisk1\DR7, is not ready for access yet.
16:00 The device, \Device\Harddisk1\DR21, is not ready for access yet.

and days later we see the errors continue, like:

07:00 The device, \Device\Harddisk1\DR141, is not ready for access yet.

We have a client who has many EVENT ID 15 disk errors in the System Event Log each day like

We have an article explaining how to list the names and details on all disks, but none of the disks on our systems have numbers as high as DR161; in fact most of them have names like:

\URTAD1\root\cimv2:Win32_Volume.DeviceID="\\\\?\\Volume{9e1805e9-5ee2-427f-8980-7632f

It is difficult to troubleshoot disk errors when you can’t find the disk!

After some digging we noticed two patterns with the errors:

  1. The errors were occurring exactly on the hour
  2. The DR number was increasing over time

That got us to thinking about snapshots and that is when we found the problem.

We have our servers set to take snapshots every few hours and that got us to thinking about what so many other articles say about checking for firmware and driver updates.

The server in question is running on VMware and has the latest VMware Tools installed (currently 12.0.6.2xxx) on VMware 7.

and then we found this from VMWare:

Cause

In current design of “VMware Snapshot Provider”, the snapshot disks are hot-removed without prompt notification to the Windows OS, this will cause the device to be unexpectedly removed without notifying the guest OS, which causes the device to not be accessible (event 15).

When quiesced snapshot process begin, VMware snapshot provider hot-adds the writable snapshot disks (shadow copy volume disks); When quiesced snapshot process ends, VMware snapshot provider hot-removes the writable snapshot disks (shadow copy volume disks), then event15 is generated for “writable snapshot disk” because the writable snapshot disks are removed forcibly from Windows perspective.

 

Impact / Risks

None.

For VSS snapshot process, the snapshot disk data is consistent when it comes to the stage of hot-removing snapshot disks. The event error is benign and can be safely ignored.

Resolution

There is no fix, at the moment, but VMware engineering is investigating.

https://kb.vmware.com/s/article/85148

This means there is nothing to be done about this at this time.



0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *