Replies

Ah, but it’s not intermittent. It’s consistent and OS dependent. The Korora (Fedora spin) OS consistently boots up (and shows the hard drive as /dev/sda) and the Windows 10 PE installation drive boots up to the Advanced Recovery environment where I can use diskpart to view and edit the partitions and volumes. (I think I mentioned in one of the earlier comments that I even deleted the ESP partition, recreated it, formatted it and used bcdboot to create new version; still freezes).  Most other OS’s, including a number of system utilities that I’ve tried in the hopes of cloning the drive all freeze during bootup. Hiren’s Boot CD PE x64 freezes after displaying its splash screen with an “Initializing …” message; Linux OS’s, both SysVinit and systemd, consistently freeze during their bootups.

And by configuration, I’m not thinking of a system file somewhere. I’m thinking more like data on the drive in a configuration area like the MBR or ???

Thankfully I just recently realized, Paul, that I hadn’t yet tried the Aomei Backupper that you suggested earlier. My first glance showed that it was a Windows installer and not an ISO or bootable image, so I didn’t look closely. I’ve since discovered that once installed on my backup laptop, there’s a Tools option to create a bootable image with either a Linux or a Windows10 PE environment. I created a bootable Windows10 PE USB drive and discovered that the laptop successfully boots with that image. (Still not sure why Hiren’s bootable PE image freezes.) Since the bootable image includes the Aomei backupper utilities, I’m using that to make a backup image of the DELL laptop’s WD hard drive. Then I’ll get more aggressive with the more destructive options.

Thanks again for the Aomei link.

1 user thanked author for this post.

windbg

DELL_Inspiron_3793_BIOS_self-test_results_2023-10-18_psa

Finally ran the extended BIOS self-tests and the results for the hard drive (after some four hours) PASSED. I still think the freezing on bootup is some kind of configuration issue and not a hardware issue. I’m reluctant to attempt a reinstall if the configuration issue is going to cause the reinstall to fail as well. And by configuration, I don’t think it’s OS specific since the Linux bootups (except for Fedora/Korora 20) also freeze.

I’m still thinking partition or some disk (MBR? although this is a UEFI boot only BIOS) flag. The Korora 20 distro includes “dd” so if I knew which bits to edit I should be able to modify them. I just don’t have a clue as to where to look.

Hi Paul. I shrank the sda3 partition some time ago and created the unallocated portion between sda3 and sda4 in anticipation of installing some version of Linux on the hard drive. It was never a problem (as far as booting is concerned). I’m still uncertain how it might affect a reinstall, but I’m not there yet.

Given that I’m able to boot into Korora 20 (a Fedora spin)  I still don’t think it’s a hard drive hardware issue.  Also, I don’t think I mentioned yet, from the command prompt I ran “chkdsk /r” on both the C:\ drive and the ESP partition (after assigning it a drive letter; “N:\). No problems reported.

 

A few more unsuccessful attempts:

I mentioned in my 10/7 post that the bootrec /FixMBR option completed successfully but the /FixBoot got an “Access denied” response. One suggestion for resolving that issue was to assign a drive letter to the partition (in my case the 750MB Partition 1), reformat it then use bcdboot to recreate the boot environment. I tried that and the system still freezes on bootup. One other suggestion was to use diskpart to delete the ESP partition, create a new one, then use bcdboot to create the boot environment. That also did not work.

I’m still looking for other suggestions and haven’t given up!

I’m going to try and attach some screenshots of the problem laptop that I took with my cell phone. There’s some diskpart info for the disk, the partitions and the volumes; also some gparted, gnome-disk-utility and SMART data and self-test screenshots.

Thanks for the suggestion Paul. I checked out the Ultimate Boot CD web site and discovered that the bootable iso is MBR only, no UEFI support. Unfortunately the BIOS for the DELL Inspiron model I have doesn’t provide a CSM option so that utility isn’t available to me.

I’ve tried a number of other (mostly Linux) utility ISOs, including the Hiren’s Boot CD (HBCD_PE_x64.iso) and they all freeze during bootup.

I have discovered a couple of ISO images that don’t freeze and they are both Fedora based: Korora 20 and a Fedora 20 (with kernel 3.11.10 and MATE 1.6.1) so I was able to get a few screenshots of the harddrive stats. I’ll see if I can upload in a little bit. Those ISOs should provide a number of utilities, but I’m still trying to figure out which would be the most helpful.

(BTW I tried to reply to your post the day after, but I pasted in something that didn’t agree with the upload requirements and when I got an error message I wasn’t able to find a way to re-edit the response and it apparently disappeared into the void. I haven’t been able to spend as much time on this issue as I’d like, but I still haven’t given up. Every time I boot up to the command prompt and see the C:\ drive or boot into the Fedora OS, I just know there must be some way to modify something on that drive to once again enable booting.)

Finally tracked down a bit more info on the error code in the System Repair Trace Trail log file (SrtTrail.txt): 0x490  Partition Table repair failure.  One suggestion was to use the bootrec.exe utility with the /FixMbr and the /FixBoot options in the Recovery command prompt to repair the boot partition. I discovered that the /FixMbr option completed successfully but the /FixBoot option resulted in “Access denied” error message. Some additional research on that situation led to a website with a recommendation to essentially reformat the ESP partition by using diskpart to assign it a drive letter, then using bcdboot to rebuild it.

I’m still working on getting the few files I know are still on the C: drive that were created after my last backup, but I think I’ve figured out a way with xcopy to grab them without doing an entire backup, and if that’s successful, I’ll give the reformat of the ESP partition a try.

Thanks, Ascaris, for the dual boot/hibernate info. I think your experience confirms the suspicion I have that the problem I’m encountering isn’t due to the hibernate issue “per se” but with a system configuration/file corruption problem. I typically disable the “secure boot” and “fast boot” options, so that isn’t an issue in this case. The BIOS has been set to RAID (although I have only the one Western Digital drive, so I assume it’s RAID 0) and I don’t think that’s the issue.
As for the USB live Linux USB drives, I had no problem booting from them on this laptop when it was also successfully booting Windows. It only became an issue when the laptop began freezing during the Windows bootup. I suspect that if I were to puzzle out where the Linux bootups hang, that might provide some insight into the problem, but so far I haven’t tried to get that info.
I’ve seen some info on Ventoy, but hadn’t given it much attention. I do like the idea of being able to select from a menu of boot up options, so I will be checking that out!

Thanks, bbearen. I’ll check out the link to the information.

I ‘m still thinking that the issue started with a hibernation session gone wrong, but I’m still unsure how to repair the situation. I stumbled across the hibernation flag issue some time back. I rarely attempt to hibernate, but once after having done so, then booting up in Linux (I think it was a version of Ubuntu) I discovered that the main partition on the hard drive would not mount. Some investigation led me to realize it was because a hibernation flag had been set (somewhere).  I believe this was back when I was working on a system with and MBR drive and no UEFI so there wasn’t that complication to deal with.  I was able to reboot to Windows, shut down without hibernating, and once again was able to mount the Windows partition.

The DELL laptop has a 1TB GPT formatted Western Digital hard drive and I’ve been hoping that if the hibernation flag is a physical bit somewhere in the beginning of the drive, I might be able to use a Windows CLI program like dd to edit and clear it. I’ve copied and restored MBRs on non-UEFI systems, but haven’t had much experience with GPT drives.

One suggestion that I’d seen was to simply delete the hiberfile.sys file. When I was able to access the Windows command prompt in the Advanced Recovery session, I examined the root directory of the Windows partition and discovered that there was no hiberfile.sys.  I suspect that the various attempts at recovery (inlcuding the attempt to reinstall but retain user files) deleted any hiberfile.sys, pagefile.sys and swapfile.sys files. Oh well.

I still haven’t had any luck finding out about the System Restore Trace Trail error message I posted above. Failing a partition table repair sounds serious, but I still haven’t found info on the error code for more detail.

Whew! Slow progress but I haven’t yet given up.

I downloaded and installed Rufus on a Toshiba laptop that I have as a “spare” system. (Rufus is great. It’s what I’ve used to create the live Linux USBs that I test drive.) I then used the steps you provided to use Rufus to download and create a bootable Windows 10 USB drive.  When I went to test the Windows boot USB on the laptop I couldn’t get the laptop to see the drive as a bootable device. I initially assumed the issue was with the USB drive or the downloaded iso image and kept rerunning Rufus with different copies of the iso image and different USB sticks. After quite some time troubleshooting I eventually realized the issue was with the USB port: it was USB 3.0 and apparently on this laptop, there are issues. I moved the USB drive to one of the USB2.0 ports and it booted up.

When I took the drive to the DELL laptop, it did boot up. The first screen asked for confirmation of system configuration settings, then the second screen presented the option of installing Windows or (in tiny font in the lower left of the screen) Repairing Windows. I still have data on the C: drive that I hadn’t backed up yet, so I’m not ready to do an install yet. The repair option brought up a blue screen with the repair/troubleshooting options and I tried the Repair option. Once again, the result was that repair was not possible but other advanced options were presented. It was too late to spend more time investigating whether the results would just be a repetition of previous attempts, but seeing that the Windows install drive booted up, I’m thinking I might be able to find a different recovery image that I can boot up.

Still not sure why the Linux drives are freezing.

Well, the mystery deepens. I discovered that the BIOS does indeed provide an option to disable SATA devices and I disabled the SATA-0 port for the hard drive. Even with the hard drive disabled (if not disconnected) all Linux live USB drives still freeze. I have a number of live Linux USB drives that I have used to preview various distributions: Garuda, Kaisen, Kubuntu, ExTix, Solus, NixOS, …  They all freeze during bootup. Could this be something unrelated to the hard drive?

I also searched the Western Digital website for a standalone diagnostic command line program, but could not find one. The only diagnostic software options that I was able to find were Windows or macOS based, and since I’m only able to access a command prompt in Advanced Recovery, I can’t install and Windows GUI programs.

So, what kind of condition would cause live Linux USB drives to freeze during bootup, but still permit the hard drive to be accessed in an Advanced Recovery command prompt?!?

Yikes!

Hi Paul,

Thanks for y0ur suggestions. The drive is the laptop’s internal hard drive, so disconnecting it or changing the motherboard connector is not an option without disassembling the laptop. I’m hoping to avoid that at this point, although I’m beginning to believe it might eventually be necessary.

I believe there’s an option in the BIOS, though, to disable elements of the system and I’m going to see whether disabling the drive will permit a live Linux USB bootup.

Since the drive is still accessible from the Advanced Recovery command prompt, I suspect if it were removed and hooked up to another system it would be readable, but it may be a while before I’m ready to try that.

I discovered that the Advanced Recovery command prompt also recognizes USB ports and I was able to read and copy to a USB data drive. I’m going to see whether the WD diags can be run as a standalone program and if so, I will try running them from a USB drive in the Advanced Recovery command prompt.

Thanks again for the suggestions.