Jump to content

orcinus

Experienced Members
  • Posts

    13
  • Joined

  • Last visited

Reputation

0 Neutral
  1. LOL, thanks. I just have this little nagging worry in the back of my head that says: "What if it happens again? And again?" I don't like the idea of: a) filesystems getting "subtly" corrupt randomly like that, and b ) BIOS being nosy and paranoid about the aforementioned filesystems.
  2. It's possible. Funny thing. Along the way, i've also converted everything to GPT, moved it to another disk, recreated the boot environment as pure EFI and cleaned out some garbage. So at least it wasn't all for nothing, i guess. Also funny - after fixing it, it actually ran Defraggler at boot Successfully as well. Not that funny - i have an extra hard drive now. The moment the problems started, i bought another Velociraptor to be on the safe side. Not sure what to do with the old one now, i guess i'll turn it into a scratch/temp disk or something.
  3. Another update. And a success! I had an old copy of Paragon Disk Tools lying somewhere and i half-remembered it had some kind of a defragment option for NTFS. So i've dug it up, booted it and ran the NTFS defrag, which turned out to also involve a rather thorough filesystem check and $MFT rebuild. After running through all of that, UEFI suddenly stopped crashing. I've got no clue what went wrong in the first place, but if i had to bet, my money would be on Defraggler somehow corrupted the MFT mirror, while leaving the original MFT fine (perhaps they didn't get synced?) and UEFI being overly paranoid over not finding them identical. All this is just a wild guess and i might be completely off.
  4. UEFI has NVRAM it can store bootloader information to. But only for pure EFI Windows environments, as far as i know. Mine wasn't. You can check for information stored in NVRAM using bcdedit. I did and it was confirmed empty. Apart from that, it has a CMOS clear like any other BIOS, which i've tried multiple times, to no avail. The link you've posted concerns secure boot, which i've covered somewhere near the beginning of the thread. That was my first guess, but unfortunately, it's not the culprit (i've disabled it, and Windows doesn't use it unless in pure EFI mode). I also thought it might be the fast boot (or quick start or whatever Microsoft calls it), but that's been long disabled too, to no effect.
  5. Actually, i did try chkdsk from a Windows PE off a Win8 USB stick. It didn't find any problems with the filesystem (tried it multiple times). The part i'm puzzled with is this - as soon as i restore the old partition, things go south. If i delete everything from the filesystem, the problem persists. If i rebuild the boot sector and its copies (as well as MBR) or, heck, even trash it on purpose, UEFI still hangs. However, the moment i reformat that "somehow broken" partition, all is well.
  6. Okay, another update. (sorry about the flood of posts, i'm hoping - perhaps a tad too optimistically - that someone might find the chronology useful) I've restored the block-level copy of the partition, as described before, then proceeded to systematically delete folder by folder while rebooting in between. When i've finally deleted *everything*, the partition was still causing UEFI to hang. After reformatting the (previously empty) partition, it started working again. So it seems it's filesystem corruption on some level that's to blame. Either UEFI is more paranoid than the usual FS checks or it has some kind of a bug that causes it to crash in certain (random) conditions. I'm more inclined to believe that there's a filesystem corruption of some sort going on and that UEFI is trying to look for the EFI folder on the partition, encountering the corruption, and hanging as a result.
  7. The plot thickens! I've nuked the whole disk, recreated an NTFS partition and restored the Windows image i did previously. And UEFI hangs yet again! Meaning there's something on the actual filesystem that's confusing and/or killing it.
  8. Doubt it had anything to do, at least as far as Win8 and UEFI are concerned. Since everything was working for months (and years before that). As far as Windows are concerned, it's a foreign partition they won't touch or can touch. UEFI doesn't give a damn as long as it's not marked as bootable and hasn't got an EFI folder on it. Plus, i've tried deleting it - it didn't change anything. The only thing that does have influence is deleting the Windows partition (which i've done half an hour ago as a test).
  9. Nope, no way of checking apart from looking into \Windows\Tasks. And there's nothing Defraggler's there (just a Google updater). The secure boot theory was my first thought too. However, disabling it results in the same behaviour. As well as trashing the keys or any combination of both. At first i thought it was something simple, but the farther i go, the more weirded out i get. The situation right now is - if the Windows partition is readable, UEFI hangs. If it gets unreadable (by munging up the partition table), UEFI boots. If i then revert it to its previous state (i.e. Windows partition readable), it hangs again. The weird part here is that it's the system partition we're talking about here, not the boot partition, so i can't comprehend why UEFI (or anything else) would even touch it before the actual boot time. I've trashed all the other partitions, made a few block-level images of the Windows partition and am moving it to the front of the drive with GParted. If that doesn't work, i think i'll give up, do a low-level format of the drive and restore from image. And if *that* doesn't work, i guess i'll have to wait till i have some free time, buy a replacement drive and go through reinstalling everything once again. I've already wasted enough time as it is, plus lost some data from a Mac OS partition i had on that same drive (my own fault - while trying to fix the Windows partition with TestDisk, i've managed to screw up the HFS+ superblock). Sigh. Edit: Just to clarify, the machine is not a Mac, the Mac OS partition is a leftover from its Hackintosh days. I should've backed the data up from it long ago, but somehow never did.
  10. This is getting weird... It turns out the reason TestDisk helped was that it actually botched the partition table (it's using the old CHS method and can sometimes "round up" the last partition 1 cylinder over the boundary of the physical disk). As soon as i've manually fixed the partition table entries via fdisk, the problem returned. So now i'm back on square one.
  11. Okay, a tiny update... After wasting a lot of time with various partition tools (all of them claiming everything is just fine), SMART tools and self-tests etc. i finally tried TestDisk from the SystemRescueCd (http://www.sysresccd.org/). As it turns out, the boot sectors were completely botched on the drive. One was wonky, the two copies were reported as faulty. I've let TestDisk rewrite the partition table and after that, UEFI stopped crashing on that disk. I still can't boot Windows off it and there's another new symptom now - if i try to start the recovery environment from the Windows 8 USB stick, it just hangs (on the dark-blue screen).
  12. Thanks for the effort. I've more or less tried all of that. Here's what i've found out after a sleepless night of trying to fix this... Whatever happened is causing the disk that was defragmented to somehow become "not liked" by the UEFI BIOS. As in - whenever that disk is present, UEFI hangs during POST. The disk itself is fine, i can mount it after POST and all the data is still visible. It passes chkdsk with no errors. Whatever Defraggler did was more subtler than simply corrupting the volume - perhaps something in UEFI is expecting something to be at a certain block and Defraggler moved it?
  13. I've installed a fresh Win8 x64 installation on my UEFI based system a few days ago. After installing all the drivers, apps and utilities (including Defraggler), i've decided to do a boot-time defrag. Lo and behold, when the machine rebooted, it... never rebooted. I am not sure what it did, but the net result is that the drive is now not bootable. Furthermore, if my system drive is connected to any of the SATA ports (Intel or Marvell), the machine will never get past POST, meaning i will never be able to hit del and enter UEFI BIOS. My initial hunch was that this had something to do with Secure Boot, but disabling it (and deleting the keys) does not do anything. I've managed to boot from a USB Stick with a Windows 8 installer - i've disconnected the system drive, entered BIOS, reconnected the drive then hit boot from USB Stick. I've tried the auto-repair, to no avail. Next, i've tried rebuilding the BCD from the command prompt - also to no avail, although i might've done something quite wrong, because after that attempt, the USB stick wasn't bootable anymore (i think i've accidentally botched the BCD on the stick). Key debugging information - my BCD is *not* on the same drive as the system (i.e. C:\Windows).
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.