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).
This may not be part of your problem, but here are a few things you might can check:
1) If BIOS settings have been changed, reset to default
2) If you have cleaned/blown any dust out lately, reseat your RAM/PCI/PCIE cards
If you install multiple things that require a boot, but wait to reboot before you install them all, that can cause problems during or after loading the OS.
In some situations, if Windows Updates is on & it downloads a Service Pack update, it may change enough settings to cause Windows to fail to boot past post.
If your wanting to backup any files on your HDD, I'd imagine you can boot to a live Ubuntu disk & save them to an empty flash.
Obviously, there are many things that can cause these kinds of issues.
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?
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).
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.
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.
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).
(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.
Do you have any kind of security/boot managers/encrypted drives/boot or windows lockers that would interfere & cause problems?
slightly redundant, We already know there is because he's using UEFI (btw for those who don't understand what this is https://en.wikipedia.org/wiki/Uefi)
the dev team is currently looking into this on a physical machine (I assume that means they have a UEFI machine). I really think it has to do with defraggler boot time trying to access bios level things and since UEFI replaces bios as the abstractor
Edit: Have you tried Windows chkdsk utility to test the restored disk partition for fixable problems?
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.
That used to mean removing all power and removing CMOS batteries and applying short circuits to reset CMOS RAM to cancel out non default chaos that may have developed.
That seems to be the current guidance from OCZ when an SSD does not boot,
though I fail to see the relevance of batteries if CMOS RAM is now superseded by EEPROM,
My non-UEFI BIOS made a bad mistake.
It decided that my SSD was not worthy of having Boot Priority and cancelled/corrupted its settings in CMOS RAM.
My SSD never booted again until I had revisited the BIOS settings and battled with obscure menus and settings to put things right.
Perhaps your UEFI has also cancelled/corrupted something in CMOS RAM (or whatever technology your latest system employs)
and the consequence is :-
LOCKUP when it sees an EMPTY partition (which possibly still has data that RECUVA and also the UEFI BIOS can read), but
NORMALITY AFTER you format the partition which removes data from certain sectors which cause the UEFI BIOS aggravation.
I think hazelnut's link explains it well, boottime is indeed a low level rootkit-like process
Are you saying that UEFI precludes anything like a CMOS configuration memory such as BIOS uses and is subject to the need for a manual over-ride/reset ?