DX4000 - recovery setup halts with "0x80070002" [SOLVED with workaround]

WD Legacy Products Sentinel Products
1

After reading many alarming posts on this forum re. recovering DX4000’s, decided to test recovery on a non-crucial DX4000 4TB at one of my client’s sites.

NAS is fully functional, I can RDP in, Dashboard states: storage OK, 2x 2TB disks healthy.

I’m testing reset to factory defaults of a DX4000 .
Using EMEA_SvrRecovery_1_7_5_17.iso (http://download.wdc.com/sentinel/EMEA_SvrRecovery_1_7_5_17.iso)
md5 hash verified.
ISO mounted with Virtual Clonedrive.
Using 16GB Transcend USB stick.
PC + DX4000 connected to same switch. DHCP active on a router also connected to switch.

Step 1: Recreate my Storage … results in “Storage OK” on the DX display.

Step 2: Perform a recovery
Starting recovery in the usual way: insert USB stick, press Reset button until “Recovery loading”, waiting until DX displays “Recovery Started”.

At this point the setup.exe on the client detects the DX4000 - … “Finding your server… connection to your server is succesfull”

Next screens I choose (o) Reset to factory default settings - do not delete data - I understand…
“Click next to begin the reset process”.

Next screen gives error: “Could not reset the server to factory default settings. Your server was not reset to factory settings. Resolve the issue, and then restart the server recovery process. Error code: 0x80070002”

At this point I verified that the DX4000 is visible over IP, but does not respond to IP, this is exspected.

On the USB stick, ServerRecovery.log contains this :
[02/29/2016 12:11:17 6bc] Starting ServerRecovery.
[02/29/2016 12:11:17 6bc] AddFirewallException
[02/29/2016 12:11:17 6bc] Listener CListener created
[02/29/2016 12:11:17 6bc] Listener UDP listener created
[02/29/2016 12:11:17 6bc] Listener UDP listener created
[02/29/2016 12:11:17 6bc] Listener TCP listener created
[02/29/2016 12:11:17 6bc] ServerRecovery started and is listening for request.
[02/29/2016 12:13:22 6f0] Listener TCPListener::TcpEventCallbackStatic
[02/29/2016 12:13:22 6f0] Listener TcpEventCallback
[02/29/2016 12:13:22 6f0] Listener TCPListener::TcpConditionCallback
[02/29/2016 12:13:22 6f0] Listener TcpConditionCallback from 192.168.0.108
[02/29/2016 12:13:22 6f0] NumberUnauthenticatedSessions is called.
[02/29/2016 12:13:22 6f0] StartSession
[02/29/2016 12:13:22 6f0] Received connection.
[02/29/2016 12:13:22 510] Entering HandshakeThread
[02/29/2016 12:13:22 510] Exiting HandshakeThread
[02/29/2016 12:13:23 6f0] Processing query system disk request.
[02/29/2016 12:13:23 6f0] Found extent with VDS_DISK_EXTENT_TYPE = 4 that is not a volume.
[02/29/2016 12:13:23 6f0] Found extent with VDS_DISK_EXTENT_TYPE = 6 that is not a volume.
[02/29/2016 12:13:23 6f0] PopulateVolumePartition failed with hr = 0x80070002
[02/29/2016 12:13:23 6f0] PopulateDiskInfo failed with hr = 0x80070002
[02/29/2016 12:13:23 6f0] DoDisks failed with hr = 0x80070002
[02/29/2016 12:13:23 6f0] ForDisk failed with hr = 0x80070002
[02/29/2016 12:13:23 6f0] QuerySystemDisk failed with hr = 0x80070002
[02/29/2016 12:13:23 6f0] End processing query system disk request.

I tried different USB sticks, connecting pc directly to NAS using straight and crossed ethernet cable.
Also tried different ISO downloads, but 1_7_5_17 is the only I have a MD5 hash from, to rule that out.

Can anyone shed a light on this and any solutions / other test steps ?
NAS can be bricked completely if necessary, including taking disks out, formatting them externally etc.
Just looking to establish & document a repeatable reliable recovery procedure in case of…, preferably while retaining data on the NAS.

2

You say you are now using 2 drives. When it was running was it 2 drives then?
Did you look at the end of the log file for recreate storage?

My vote would be to Diskpart clean on your 2 drives and try again

3

I see now you said and keep data. I suppose you might try a different USB stick on a different client PC before diskpart…

Does your client PC have any kind of 3rd party AV that might touch the thumb drive in any way?

In any event I would do recreate again and look at the log. That said, if the box was running and just the OS went bad you should not have to recreate.

I applaud you for your research and efforts to be able to recover. But a backup is your best plan

4

Hi Gramps, thanks for chiming in, read many of your reponses, you seem to be the only source of usable DX4000 answers.

The recreate storage log on the first USB stick \WDRECOVERY\recovery.log is quite long, but seems to end in success:

******************** Driver Version Check DISABLED ********************
Port,Model,SerialNumber,FirmwareVersion,Array,Status,Size,Free,Type
2,“WDC WD2002FYPS-02W3B”,“WD-WCAVY7407628”,“04.01G0”,0,“Normal”,3907029168,5391,“ArrayMember”
3,“WDC WD2002FYPS-02W3B”,“WD-WCAVY7430015”,“04.01G0”,0,“Normal”,3907029168,5391,“ArrayMember”

2016.02.29 10:57:29 - INFO - RaidCfg64 detected 2 drives
2016.02.29 10:57:29 - INFO - RaidCfg64 drive WD-WCAVY7407628: port=2
2016.02.29 10:57:29 - INFO - RaidCfg64 drive WD-WCAVY7430015: port=3
2016.02.29 10:57:29 - INFO - Matched drive 0 serial WD-WCAVY7407628 model WDC WD2002FYPS-02W3B1 with white list entry Enterprise Storage 2 TB
2016.02.29 10:57:29 - INFO - Matched drive 1 serial WD-WCAVY7430015 model WDC WD2002FYPS-02W3B1 with white list entry Enterprise Storage 2 TB
2016.02.29 10:57:29 - INFO - Checking RAID status (2): Volume Good
2016.02.29 10:57:30 - INFO - No need to re-create RAID volume
2016.02.29 10:57:35 - INFO - =========== Recovery app END (0) ===========

To be sure: the box I’m testing this on is running, has always run with 2x 2TB drives, box is usable in every normal way from the client pc’s view, is not displaying abnormal errors, RAID is OK.

There is some previous history though: drive bay 2 had failed last week.
I took it out, re-inserted it, had it rebuild, but rebuild stopped again due to Drive Failed.
Tried another drive type that was not on the compatible list (although listed on the official compatible drive listing on the WD site - luckily my distributor played along and is taking back the drive with refund).
Tried modifying the whitelist.xml as explained on other fora but this this produced Dashboard-Monitor-Storage “No information available”.
Spent time redoing this making sure no errors on my part.
Finally solved this using the uninstall/reinstall with a WDStorageSetup.msi from an identical DX4000 software version. I had apparently been using the WDStorageSetup.msi from a newer software version.

Somewhere during this, over RDP in Computer Mgmt - Disk mgmt I saw 2 D: partitions. This is impossible, but it was there. I removed the smallest one, Windows did not complain but warned me to restart. After a restart there was only 1 D: partition left, like it should be.
Don’t remember if this was before or after the whitelist.xml modification attempt.

So assuming the failed drive bay 2 was really failed mechanically and waiting for another compatible drive, I played several days with the box running with “Drive failed”, trying ISO recoveries with several ISO versions etc…
But they always aborted with the 0x80070002 error in the setup.exe. Assuming this was due to the failed drive and RAID being invalid.
But guess what: yesterday reinserted the failed drive, it is now again functional, RAID rebuilt and has healthy status … ?

However, the setup.exe aborting at 0x80070002 persists even with healthy RAID, so must be something else.
Is it possible that I introduced some inconsistency by installing WDStoragesetup.msi from a newer software version, that this created the 2 D: partitions and that this now is causing the 0x80070002 during recovery ?

Other sidenote: will take your advise at heart but had already decided after reading all other posts: this device will never be first-line storage, only backup.

5

Does that recreate log show anywhere Raid 1 (or 5) Just curious, been a long time but mine showed something at the end, but I did recreate from scratch.

As well do you actually have the drives in the 2 middle bays, and empty one on each outside? Again wondering why it says port 2 and 3 but again, that may be what it is supposed to say.

I do have a link in here from web archive something that you might find a hash file for the older download if you want to try that

Since you mention a drive being “iffy” just not sure. For giggles you might try recovery with just the known good drive? (in Bay 1) If still no progress I would say go ahead and clean the drives with diskpart. While they are in another system you might look for a drive diag to run against them ?

6

I don’t read very well. Looks like you tried to recover with jus one drive already

7

Yes, I tried various recoveries with 1 drive functional.

8

Yes, the recovery.log states in several places :
RaidLevel: 1 MemberDisks:02 Domains/Mirrors:02 TargetId:0x01

Two drives are in leftmost 2 bays, they’re numbered 1,2,3,4 on the housing. Strange indeed it says port 2 and 3 in the logs… ?

I’ll just wipe the drives than, and see what it gives. Still is a test system, no data on it, wanna build up a working recovery scenario.

Do you have any working links for MD5 hashes or even older ISO’s ? My test box has 1.2.19.381 (2nd newest is 1.7.5.17)

Thanks!

9

you can poke around here for hash files
http://web.archive.org/web/20130515000000*/http://support.wdc.com/product/download.asp?groupid=1601&sid=162&lang=en

Ok, good on the raid 1 stuff.

I think you will get it. Let me know please.

10

No luck.
Cleaned both 2x 2TB disks.

(Procedure: connect in external USB case
Win7 disk mgmt: “drive invalid” → convert to Dynamic, showed 2 partitions: 100MB EFI, 1900MB empty (?) …
cmd as admin
diskpart: sele disk, sele part 1/2, delete part override
start DX with 2 drives: Startup error 0xD9 (exspected?))

EMEA_SvrRecovery_1_7_5_17.iso, md5-verified, mounted using Virtual Clonedrive.

Proceeded to 2. Recreate storage, using old USB stick 500MB.
Tried twice, both fail with “Recreate storage failed” on the LCD.

\WD\recovery.log ends twice with the same error:

2016.03.04 15:54:48 - INFO - RaidCfg64 detected 2 drives
2016.03.04 15:54:48 - INFO - RaidCfg64 drive WD-WCAVY6875326: port=3
2016.03.04 15:54:48 - INFO - RaidCfg64 drive WD-WCAVY7407628: port=2
2016.03.04 15:54:48 - INFO - Matched drive 1 serial WD-WCAVY6875326 model WDC WD2002FYPS-02W3B0 with white list entry Enterprise Storage 2 TB
2016.03.04 15:54:48 - INFO - Matched drive 0 serial WD-WCAVY7407628 model WDC WD2002FYPS-02W3B1 with white list entry Enterprise Storage 2 TB
2016.03.04 15:54:48 - INFO - Checking RAID status (2): Volume Good
2016.03.04 15:54:49 - INFO - Enabling write-cache
2016.03.04 15:54:49 - INFO - Attempt to find ATA disk Volume0
2016.03.04 15:54:49 - INFO - Obtained 21 bytes of VPD SERIAL DATA out of 25 transferred
2016.03.04 15:54:49 - DEBUG - \.\PhysicalDrive2 serial=‘’
2016.03.04 15:54:49 - ERROR - Failed to query write-cache status on volume Volume0
2016.03.04 15:54:51 - INFO - =========== Recovery app END (4) ===========

11

I may be onto something, based on Helpful Information for WD Sentinel DX4000 Users installing New Hard Disk

My DX is from July 2012, came with software v.1.2.19.381.
For recovery, I am using ISO software 1_7_5_17, contains RAIDCFG64.exe dated Sep 22 2014, version 10.5.6.1002.
Probably my DX contains older Intel RAID firmware, and RAIDCFG64.EXE on the storage recreation stick is too recent ?

Q: How to make a 1.2.19.381 storage recreation recovery stick without the .ISO ?
Can I cobble this together manually ?
I have another working DX 1.2.19.381, but not the recovery ISO.
This has a C:\WD dir containing about 111MB of files.
From what I’ve seen on other ISO’s and DX’s, this is just the “firmware” file, named software_version_xxxxx or sentinel_firmware_xxxx on some download sites, also referenced as such in official DX release documents, e.g. http://support.wdc.com/download/notes/WD_Sentinel_Software_Release_Notes_1_5_7_30.pdf?r=376

Probably confirmed by the storage recreation \WD\recovery.log :
2016.03.04 15:35:47 - INFO - C:\wdrecovery\raidcfg64.exe /i
2016.03.04 15:35:47 - INFO - raidcfg64.exe /i Output:
Version Tables:
Driver Version: 10.8.0.1003 <<<<< newer driver on the stick
OROM Version: 10.5.5.1050 <<<<< older firmware
App Version: 10.5.6.1002

From the 1.7.5.17 recreate storage stick, extracted SOURCES\BOOT.WIM using 7-zip, search “iastor.sys” :
in windows\system32\drivers, finding these:
iaStor.sys Sep 22 2014 v.10.8.0.1003
iaStorV.sys Jul 14 2009 v.8.6.2.1012

On the other working DX from same year, these are the versions in c:\windows\system32\drivers:
iaStor.sys Oct 12 2011 v.10.5.6.1001 <<< is older than on recovery stick
iaStorV.sys Jul 14 2009 v.8.6.2.1014 >>> is newer than on recovery stick ??

12

you did not clean the disc, try that first
diskpart
select disc
clean

13

That did it !!! Storage OK ! Gramps, thanks, you live up to the exspectations ;).

Now continuing with ISO recovery, let’s see how that works out.

It’s good news that the “recreate storage” failure is not due to conflict between the newer RAID64CFG.EXE on the recovery stick and older firmware.
Driver Version: 10.8.0.1003 <<<<< newer driver on the stick
OROM Version: 10.5.5.1050 <<<<< older firmware

If it would be the cause, there would not be any scenario possible to recover a bricked older (2012) DX using more recent ISO, since those are the only ones that still are around to download.

14

I think that thread was about 2 diff versions of software. Well software and a driver, not firmware on the MB

Anyways, perhaps in 5 hours it will boot

15

Left it running during the night, in the morning server was configured.
Just a small glitch connecting to the setup page: http://xxx.xxx.xxx.xxx/connect gave a “Forbidden access”, without /connect it connected fine.

TOPIC ROUNDUP
(1) the issue with the initial recovery halting with “0x80070002” never got explained nor solved. May have been caused by one of the following:

    • a disk having failed temporarily but coming back online later (still running without errors now, never seen this before)
    • attempt to replace WDStorageProvider.msi with a wrong (later) version, to modify whitelist.xml to allow other than the “compatible” drive types listed in Dashboard
      (note: this does work when using sentinel_firmware_x_x_x_x corresponding to the boxes own software version in Dashboard-Monitor-Software update)
    • file system messed up due to one or both of the above, since I saw 2x D: partitions at a certain point
      The only solution was a full re-install using recovery ISO.

(2) needed to “diskpart clean” as well to succeed in step 1. Recreate storage

(3) step 2. Perform recovery - factory defaults went OK

Thanks to Gramps for guidance and clarifications.

16

correct slash connect will not work until setup has be completed

Do you remember since it is fresh in your mind, what did the lcd say during the middle recreate step and how long did it take?

There is a another fellow in here currently having problems with recreate that does not appear to complete

Thanks, and great job !

17

Thanks !

Not sure, I’ll run a recreate storage again against diskpart clean’d disks (2x 2TB WD2002FYPS-02W3B0), watch and time the LCD and post the log

18

I just wanted to know if you remembered anything
It goes fairly quick I thought?

19

I don’t mind helping back.

Yes… takes less than 5 minutes, this is what appears on LCD:
(blue power led blinking all the time)
initializing
checking storage
cleaning storage
creating storage
verifying storage

In my case failing getting again now with: [quote=“PatrickE, post:10, topic:153297”]
2016.03.04 15:54:49 - ERROR - Failed to query write-cache status on volume Volume0
[/quote]
I surely did diskpart clean …
Retrying, making sure to clean eject USB after diskpart clean.
…
Getting “Recovery invalid config”. Probably because I used the same stick, only erasing the log files.
Try again with a fresh stick
…
Storage recreation finishes OK within 2 minutes after LCD “loading recovery”

20

Thanks for the help. Yes, a file gets deleted when that thumb is processed and has to be recreated each time.