6

I've read through some of the posts related to corrupt or not working NTFS partitions, but without a proper solution for my case. Here it is: my system is

  • SSD on mini PCI express (PCIe), with Windows 7 installed on it. Two partitions: one with Dell utilities (40 MB), the rest the windows installation itself (119 GB).
  • HDD with 450 GB of NTFS files, and 30 GB of all the partitions that make a Ubuntu installation work (swap, system, etc.)

The boot device is Internal HDD (IRRT), the only possible one; this enables IRRT, and starts GRUB, which by pointing to some sector on the HDD can start Windows 7 on the SSD.

Now what happened:

I put my computer to sleep, and then it went to hibernation after some hours. The wireless card was physically disabled (Dell M4600). Then I started up the laptop, and before GRUB was complete, I switched on the wireless card again. Then pressed "windows" on GRUB. Then BSOD, reboot, and windows cannot find the booting partition: "needed device missing".

I have tried the Windows 7 recovery disc: can only repair the tiny bit of the Windows installation that is on the HDD, cannot see the SSD. The "repair" does nothing. Removing the hard drive to get around GRUB by force did not make the Windows DVD see the boot sector of the SSD. It was not enough of a "Windows installation".

Now, if I start to act as if I would install Windows again, Windows sees the two partitions on drive C, they are still here, in NTFS.

Then I went to Linux and tried fdisk: the partitions are still here, again. But they don't show up in Nautilus, and I cannot mount them. However, dd can recover data: if I try reading data at some random big offset (like offset 20 GB, and read 10 blocks), the blocks are indeed "data", no problem to access the drive physically, it doesn't seem to have failed completely at least. I will do a backup tomorrow then.

I tried TestDisk: boot sectors are identical and seem OK, but both MFT show as "bad", nothing more. Cannot access the files inside the file system.

On that site, I saw something about a wrong write in NTFS journaling, Need to recover corrupt NTFS partition .

Almost last post. Nothing about it on the Internet, as far as I searched.

And I suspect something about the hibernate process is not reversed, as I remember that the hibernate process changes the boot sequence a lot (or else you could move hiberfil.sys without a problem, but you can't. It needs to be in the root directory, because there is no place in the boot loader to accommodate for a folder location, or even another drive!).

So maybe both boot sectors were affected by the hibernation, and when it could not complete the process of reverting to normal boot, it stayed like this, Windows looks where the boot pointer points and does not recognize a normal Windows installation and refuses to repair it, and as Linux cannot find the MFT it cannot mount it...or maybe something different, affecting the MFT itself. I don't know... I will try CHKDSK and, after backup, fixmbr, from the Windows 7 DVD.

UPDATE: fixmbr and fixboot seem to only work from the recovery console, and I couldn't access it. From the Windows 7 DVD, I could do CHKDSK : it only said the volume was NTFS before crashing because "MFT corrupted. Will try repair. MFT Could not be repaired. Exit chkdsk".

When trying diskpart, it saw my partition on the SSD as...Raw. So, this does not correspond to what CHKDSK has seen.

Something is weird in all this: all this time, Windows did not see the first 40 MB of my SSD, which contained Dell utilities. On Windows 7 Explorer the main partition of the SSD was always C:\, and the partition of the HDD was D:\: this 40 MB partition on the SSD never appeared anywhere. But now, Windows sees this 40 MB partition, and gives it the C:\ letter. While the D:\ letter corresponds to the 119 GB partition, "Raw" format, unable to be read. I don't understand anything...

Improve this question
2
  • What happens when you remove the drive(s) and put it/them into another Windows machine as external disk(s)?
    – user3463
    May 28, 2012 at 23:29
  • Still haven't done it as the faulty drive is an internal drive, and mini-pci-express in addition. Would have to find some external case with that interface!
    – MrBrody
    May 28, 2012 at 23:36

2 Answers 2

Reset to default
1

The boot device is Internal HDD (IRRT), the only possible one; this enables IRRT, and starts GRUB, which by pointing to some sector on the HDD can start Windows 7 on the SSD. I think you need the pointer to be the same is this.^

I am guessing { Then pressed "windows" on GRUB. Then BSOD, reboot, and windows cannot find the booting partition: "needed device missing". }

is not using the same pointer, especially if it goes into hibernation. the grub boot would have to point to your windows boot sector or hiberfil.sys had a similar issue when I tried to edit winresume.exe to try to point to D: when windows is on C: it would not bring up windows from hibernation, when I used the copy of original is fixed it.

hope this helps

Improve this answer
2
  • Hi, thanks for the suggestion, in the end I just reinstalled everything and it never happened since. I'll try to dig your fix if it happens again!
    – MrBrody
    Apr 27, 2013 at 22:05
  • @MrBrody You may want to add an answer yourself simply stating that and accept it, so both the community and the software knows that the issue has been resolved in some manner.
    – user
    Jul 7, 2013 at 13:17
0

Finally, I reinstalled windows on the C drive (the SSD), and when it was complete, the system did work again, but the boot sequence short-circuited GRUB. So now, the Linux installation is off reach.

It is still on my D disk, and I know I would just have to insert a live CD and repair GRUB to make it work, but I haven't done it yet, for other reasons.

It's been a year now, and from time to time there where other BSODs when exiting hibernation, but never again did it cause any permanent damage to the file system.

I guess studying all about booting's answer is right somehow. the whole process "boot on HDD (IRRT) ->GRUB ->Correct pointer to windows bootloader->location of "out of hibernation" initialization sequence" must have failed somewhere, in a manner that no conventional repair tool could fix.

In the end, I could not understand the problem, and now my system is re-installed so I will probably never have additional clues about what happened. If one day I happen to have enough knowledge about the booting process, IRRT, Windows, GRUB, and the special disk configuration I have, I may end up guessing a better explanation.

But for now, I will say this: apparently, on this precise configuration (Dell M4600), having GRUB on IRRT with Linux on the "real" hard disk, and windows on a mini-PCI-express SSD, with hibernation activated, seems unsafe, because the BSODs still happen even with GRUB disabled (which means the whole booting process is controlled by windows now, and even with that, it may have problems exiting hibernation - maybe the size of the 12 GB RAM, and thus 9 GB hyberfil.sys file, play a role here), and as one of these BSODs could kill my NTFS partition in my previous configuration, without any hardware fault (because my SSD still works very well - I haven't checked its health in deep details, though), I don't see why it could not happen again.

So, the solution exists, and it is not very pleasant, but the whereabouts of this precise issue are not clear yet. If anyone has any more insight here, I would be very glad to hear it.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .