Do not try to rebuild if one of the disks has failed replace it with a new one then Rebuild.
If this is what you have done Install RST 10
also any software to do with HDD's needs to be disabled like Defrag and SMART in the main BIOS may need to be disabled.
Was attempting to rebuild to a NEW disk, per the RST help. Disbled SMART in BIOS and updated to RST 10 (10.1.0.1008) was using RST 9 prior. Still the same behavior. Before I received your response, immediately a restart, and prior to doing as you suggested, the problematic drive started reporting as "at risk", rather than requiring a rebuild (to another new disk). Even so, the error is exactily the same if one tries to "reset disk to normal" for the problematic drive, or if one tries to "mark as spare" the new, fifth drive. The error message is the same for both scenarios, however, immediatley after a reboot, the error does not appear immediately, but rather takes 53 seconds to appear, after clicking one of the two possibilities above. After one attempt (and prior to another reboot), the error appears immediately. I've tried using yet another NEW drive. Makes no difference. The firmware on the original four drives is CC36, whereas the firmware on the new drives is CC38. What is RST trying to do during those 53 seconds that is the same for both "reset..." and "mark....". It is trying to do "it" to different drives so it doesn't seem reasonable that it is the drive firmware. It seems there might be some other process that is preventing RST from completing its operation as it takes a while to timeout, then doesn't in subsequent attempts. Perhaps RST is initiating the starting of a service, which causes a delay, then when that service is running, the delay does not occur. Just thinking - maybe I'll check out what processes are running before, and after. Any help would be suggested. It's irritating that the software author doesn't at least advise in an error message what was being attempted when the failure occured. Lazy. Any help would be appreciated.
When it was requiring a rebuild, I tried it both ways: replacing the bad with a NEW fourth drive, and leaving the bad drive attached with a NEW fifth drive. No difference. Now that it is reporting the bad drive as only being "at risk", I again tried all permutations. The error is exactly the same in all cases. Besides, the (same) error occurs even if I only try to mark the new drive as a spare. So, going back to my thinking that the problem is related to a service I noticed this Intel authored service as being related: "IAStorDataMgrSvc.exe", and I checked out the event manager logs and this is what I found: 1)Application Log: the mentioned service starts normally, but these errors occured:
Information: Service started successfully.
Information: Started event manager
Error: IAStorUtil.StorageAction.DiskMarkAsSpare action failed: FailedToClaimDevice
Error: IAStorUtil.StorageAction.DiskResetSmart action failed: FailedToResetSmartEvent
Error: IAStorUtil.StorageAction.VolumeModify action failed: FailedToClaimDisks
And in the System Log:
Erroe: DCOM got error "The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. " attempting to start the service SeaPort with arguments "-Service" in order to run the server:
But I checked and DCOM service started and is running normally.
Started to do as you suggest, even though it seems to me that one would rather try to find the problem so as to prevent it in the future, and noticed that the new drive that I plugged in, even though it was noticed by the RST application, it was not initialized in the system's "Disk Management" (DM) administrative application. So, I initialized it as Basic, tried RST, still same behavior, the changed the new drive from Basic to Dynamic, tried RST, still same behavior. The new drive shows that it is "unallocated". I noticed this: anytime I tried RST, the newly added drive disappeared from DM, and would only reappear upon reboot. I don't think DM is the problem as RST recognizes the new drive, and trying to "reset" the bad drive (which doesn't involve the new drive in any way) produces the same error Anyway how should that new disk be configured in the DM admin to satisfy RST's requirement? How should the new drive be configured in DM if I were going to use it to add the 2nd OS? The system has four drives (one bad) plus the new one. Where does the 2nd OS get installed? And back to the original question: why do I get the same error when trying to just reset the bad drive? According to the documentation, that should be possible.