Jump to content
CCleaner Community Forums


Experienced Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About orcinus

  • Rank
  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
  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
  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
  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 part
  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
  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 mov
  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 w
  • Create New...