Jump to content
Piriform Community Forums
orcinus

Boot Time Defrag + Windows 8 = Catastrophe

Recommended Posts

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).

Share this post


Link to post
Share on other sites

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.

But hopefully, I have given you a few ideas.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

what it sounds like is that when post gets to the defrag command UEFI says "hey I see this progam running outside of my list of secure OS's"

is anyone else out there running UEFI?

I'll see if I can get the development staff to look into this, or comment.

 

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Do you have a way to check the scheduled tasks folder & delete any new scheduled tasks that are not supposed to be there?

 

I had the thought that because Windows 8 utilizes secure boot, perhaps Defraggler is attempting to run but never finishes.

Perhaps secure boot process interferes with it, & causes it not to post?

 

It may be something else, but I wonder if you still have a defraggler task, & if you do, that if you delete it if it would then boot?

Normally, the task would be cleared after a successful run, but it may not be ever successfully finishing if secure boot is interfering.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I don't suppose having a Mac OS partition on the same drive either caused UEFI/Windows/Defraggler to be confused?

 

Didn't know about the Mac partition initially.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Do you have any kind of security/boot managers/encrypted drives/boot or windows lockers that would interfere & cause problems?

 

Edit: Have you tried Windows chkdsk utility to test the restored disk partition for fixable problems?

Share this post


Link to post
Share on other sites

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?

:blink: um poster can't get to windows.

Edited by Nergal

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Have you reset your CMOS RAM settings ?

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.

Edited by Alan_B

Share this post


Link to post
Share on other sites

I think hazelnut's link explains it well, boottime is indeed a low level rootkit-like process

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I like your guess - it has a ring of truth :)

 

I remember that Paragon also claim the ability to fix the problem

Misalignment of logical partition sectors and actual physical sectors leads to redundant read/write operations.

http://www.paragon-s...tion-alignment/

 

Is there any possibility that Paragon might have done that to your disc ?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×