Boot problem with win 7 64 after power failure

Hi experts, I have a windows 7 pro box 64 bit with an asus PX-8B server main board. It was built as a small "server" for serving files and running "thin stuff" TS software. It has 2 X 1TB sata drives in RAID 1. We have a power bump and since then this system cannot boot.

I ran recovery on it and it couldnt fing the OS so then followed instructions on rebuilding the BCD store. Now the system starts to boot up but during the initial windows boot screen the system restarts continually. A system recovery now reports that it cannot repair this system - consult sys admin for further instructions - love that ! Theerror info that comes with that sites a corrupt registry as an error but offers no hint on what to do with this. If I boot into safe mode the system restarts as it is displaying the fvevol.sys file during the start up process.

I can use the recovery system to browes the drive and all of the files seem to be there in the correct place. After nearly 48 hours banging away at this I have exhausted my options and need to be pointed to a different direction. Any suggestion would be greatly appreciated at this stage. I would rather not do a re-install from a reformatted disk as all of the user data is still there and it appears that the OS is still there as well - hoping it might be a case of selective recovery of some core system files ?

Thank you.
broadsoftAsked:
Who is Participating?
 
DavidConnect With a Mentor PresidentCommented:
Good, I was pessimistic because I thought the RAID had been off all the time you did a chkdsk, recovery, etc ... and that would have just made it a total write off.

Now you probably have one of those "fakeraid" BIOS-based controllers.  The problem with those (one of many), is that the work is done by a device driver.  So if you do a recovery and don't get the driver mounted during the recovery, then just no telling what happened.  One disk would have been written to, the other would have stale data, before this whole thing started.  Then when you install the driver, it is a reasonable risk that unless you wrote to the original 'C' drive, that it could have synced up the stale data over the live data.

You *really* need to at least use another computer and download/burn an ubuntu livecd.  then you can boot the system read-only, see both disks, and then compare using a binary editor or some native linux utilities.  One disk may be much better off then the other with less corruption.  

You can also create a bootable USB stick if your motherboard will boot a USB and run linux that way. This gives you full control, but requires some linux expertise.

Another freebie, go to runtime.org, download their product called getdataback.  They have instructions on how to make a bootable USB so you don't risk changing anything or need another disk.   You can then run the software for free, it will take a day or so, depending on how  big the HDD, and reconstruct the file system in RAM.  

The great thing is to turn off the RAID & run this on both disks separately.  See if one disk is "better" than the other.     Then, assuming disk 'A' is best, you can have it then reconstruct everything onto disk 'B'  (or vice-versa).  So you end up with a corrupted disk 'A',  a repaired disk 'B'.  The repaired disk will NOT be bootable.  But at least you don't have to buy another disk.

Then you use the broken file system disk and just reload the O/S on it, and then copy over files and such from the repaired 'B' drive.   Unless you have a decent controller, you will not be able to just turn the non-RAIDed disk 'A' into a mirrored disk by switching on the RAID controller in the BIOS.  Such is the price for not obtaining a scratch drive.  

As for the runtime software, it is free to try and let it crunch, and you can view the files to make sure they are good.   Remember, if you just type in DIR, you aren't necessarily seeing the files, you are seeing directory entries, which may be incorrect.  Only way to know for sure if a file is good is to try it




0
 
DavidPresidentCommented:
When a system reports that it can't find the O/S, when you are in a RAID1 config, then things must be done carefully, because root cause could be the RAID config.   Odds are low that a healthy RAID1 config will self-destruct.  So usually it is a RAID controller or metadata or something related to the RAID config.

Having said that, you could have really screwed things up with the system restore to the point that you need to go with a plan 'B'.   If you want any chance of getting something back, then you need to get another HDD, and clone the TWO original drives, and then do a fresh install.

48 hours banging away means there is just no possible way to figure out what you have done and how to get you back.  Gut feeling it was probably something easy, like the surge reset the BIOS so the RAID controller setting was disabled.  It wouldn't boot, so you did a recovery, and that actually created all the damage.  Most RAID controllers put some metadata at block zero, and then everything shifts down relative to that.  so your partitioning and all the block numbers went from logical block numbers based on the size & location of metadata to physical block numbers.

If above happened, you did way too much damage by your actions.  You have no choice but to load a fresh copy on a replacement disk, and then mount one of the RAID1 disks and manually copy over what you can.  If you called in a pro, then we'd get out a binary editor and then start looking at partitioning, and run some forensic recovery software.  This is way too much to walk somebody through, and even if I could, you wouldn't have the necessary software.  Plus lots of hexdumps would have to go back and forth.

Sorry.  You just have to load a fresh O/S on a replacement drive, and then work with a clone of the munged up drives.  otherwise, you are just making things worse.
0
 
broadsoftAuthor Commented:
Thanks for that. Not really what I wanted to hear but you may be on the money. The BIOS was corrupted and I couldn't even get the BIOS screen after this happened (that in itself is a concern) so my only option was to do a BIOS reset and that did reset the RAID config. However, after I set the RAID BIOS back, the drive is still recognised as an active RAID 1 disc and the partitions are all in place. I have taken a look with DISKPART and it all looks OK. So,, I am not doubting your advice by any means but I do need to be completely certain that there is no way back before I go for plan B.
After the incident, I had no loadable OS and the system advised me to do a recovery - was there an alternative action that would have produced better results perhaps? I can enter the recovery consloe and browes to all of the system files and it all looks like it should be a working system. I ran a chkdsk /r and it "fixed" some errors *again because the recovery process advised me to do so". chkdsk reported that it had repaired the errors. Is it still possible that the damage as you suggest might be there even thiough I can still see the partitions and browes the file system as though it is a healthy system?

Thanks once again.
0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
DavidPresidentCommented:
Well, then it was exactly as I wrote.  Sorry.  Understand that every block number that every directory entry and file points to is wrong when you went from RAID to non-RAID mode.   So if it is in non-RAID mode still then that is the worst thing it could be at.  It assures you won't be able to get anything.

To make it easy, let's say that the controller uses 1000 blocks of metadata.   Your partition table is on physical block 1000.  If the partition table says NTLDR.SYS is located at block #2500 when you loaded the O/S, then it is really at block #3500 in the non-RAID mode.

So  when you did emergency recovery to restore NTLDR.SYS, instead of going to physical block #3500, it went to physical block #2500.  Whatever was at physical block #2500 (block 1500 when RAID turned on), got blown away.

Chkdsk has no idea about any of this, it finds a chunk of a file and is going to be off 1000 blocks when it tries to get the next piece.  This is why it got worse & worse over time. Every action you did destroyed more.

EVERYTHING YOU DO WHEN RAID DISABLED CORRUPTS EVEN MORE DATA.

Had you turned on the RAID controller, you would have lost nothing.  That was the only correct action you could have taken.  Another one would have been to just disconnect one disk.

BUT ... you have a chance.  If the RAID was off, and you haven't turned it on, then you have 2 disks.  The other disk has a copy of the data before the disaster.  If one drive died, as a result of the power loss, then you probably can get 99.9% of your data back if you take that bad drive to a data recovery firm with $500-$1000.

I'm not going to sugar coat it. You need somebody who knows what they are doing.  Binary editors, forensic recovery, diagnostics, a few TB worth of scratch disks are what it takes, and there is no way anybody can tell you what to type to get anything back.  The only sure thing, every moment you have either disk turned on risks further loss.

0
 
broadsoftAuthor Commented:
Hi again, the raid is turned on and it isin this condition that I am able to run chkdsk and browse the files etc. when this first happened it did try to boot without raid enabled but everything that has been done has been with raid on and the system aware of the raid drive. Thanks again for your valued input.
0
 
broadsoftAuthor Commented:
My iPhone touch typing is not that flash - last post. What I was tr young to say is that the raid has been turned on for the action mentioned in my earlier posts - apart from the one time after the disaster when it tried boot with the controller still in non-raid mode. So in theory the files I can see may well be in tact and the cheeks was done with the system in full raid mode as well. I have a backup of all of the data so a rebuild might be the easier option considering time spent already. Again, thank you for your input. It seems like in some cases, raid may be a little troublesome but I have had several systems that have been able to be recovered because there was a raid 1 drive. Thanks for your xplanation on the file block offset - I have had years of experience working on main frames and the concept is not new to me. It would seem to be a better practice to keep these aligned wether in raid or non-raid but who ever designed the system this way would have had their reasons I guess.
0
 
broadsoftAuthor Commented:
Hi again, I appreciate the information and suggestions you have put forward. Unfortunately, in a world where time is money, I think my most logical fix is o opt for a rebuild. I've already devoted way too much time on this and I've concluded that it will be a quicker fix to just start again. I rather lik the idea of the challenge of getting this sorted out but my left brain is telling me to go for the reload.

Thanks again.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.