Bootable recovery disks don't boot
I've used true image and disk director for many years. The bootable recovery disks have often been a life saver. I now have a situation where the bootable recovery disks won't boot,and my question is why?
Some background.
I've always understood the bootable recovery disks have their own OS and when booted allow the related application run regardless of the status of the main PC. The C drive on the affected machine is an SSD and that drive has only the windows C image on it. There a number of other separate HDD drives holding apps data etc.
Recently I have experienced a rash of BSOD events. The circumstances suggested a software failure because: a) the normal post runs and the BIOS is accessible, b) it booted and would run an application until BSOD, and c) microsoft community identified the cause as an exe file (Ntkrnlmp.exe) that was identified in several minidump files created by the BSOD event. Solution offered was to use a restore point, which worked (the restore ran, and the system booted after that). But that didn't stop the BSOD events, which recurred and now happen at boot time with a message "bad system config info" and the win10 auto repair does not work. Essentially, the machine is unusable because it won't boot.
So, out with the bootable recovery disks to recover the C drive from a recent backup image. Both TI and DD12 disks were made from the related iso files, and tested to work after being burned. The TI disk presents the message: starting loader, and then boot failed. Repeatedly. Next, tried the DD12 disk - aim was to delete the old C drive volume, re-create a new C drive volume and then recover the image using TI. The DD12 disk boot failed in the same way as the TI disk did.
I have re-tested both bootable disks on my spare machine, and they both worked as normal.(loader ran, started the app, and the app could process related imagery).
So, the question. What can cause a working bootable disk that is supposed to be independent of the main machine (other then of course using the cpu and memory) to not even run the loader???
I
David, given your description of the issues and the fact that your rescue media works fine on a different PC, then all suggests a hardware issue with the problem PC.
Given that you mention that this PC has multiple drives installed, then it suggests you have a desktop or tower system which makes diagnosing the issue a little easier!
The focus areas are going to be on memory, drives and the power supply, so I would suggest taking an approach to reduce the PC configuration down to a bare minimum then testing the rescue media from that point to see if it will boot?
In this case, you could disconnect or remove all disk drives and reduce memory to a single module. Doing so will reduce the power drain on the PSU and eliminate any additional memory modules. If that boots the media successfully, then shutdown and put back all the memory and test again.
Power supply issues can give some of the strangest faults because of any under-voltage lines that may be provided to the system.
Ditto to Steve's response here.
All,
Thanks for the responses. And yes, it turned out to be a disk hardware issue, which I will explain, lengthy but worth reading because there is a reason, a recommendation and an outstanding query from it. The query is that the fix doesn't explain why, in the failed condition, the bootable recovery disks (2 of them, 1 for DD12 and 1 for TI 2021) did not boot, but simply detected the disk, gave an acronis loader message, and then (next line on a b/w screen) boot failed. It was my understanding that the recovery disks made no reference to any attached disks: the boot cycle, OS and app came from the CD/DVD disk. Certainly that's what It's looked like the times I've used it to recover from a disk failure. And in those cases, each one was an HDD unit.
The bootable disks were both made from download iso files (I mentioned that?) and tested to boot and run the related app as soon as the burn was finished, then labelled cased and stored with the off-line drives holding the backup files, and a printed copy of the recovery pages of the manual. I do this every time there is a new version of the disk tools and/or TI released.
The motherboard is a gigabyte unit with an Intel core i3 cpu, and the BIOS is set for both legacy and UEFI.
A desktop it is, and the C (and boot) drive is an SSD, installed Jan 2018 and now 4.5 years old, with daily usage since then under win7 and, from mid-2020, win10. It certainly speeded up things like AV scans, backups and other time lengthy and compute intensive activities. And at the time, there was extensive articles on SSD usage, since price was becoming very competitive, and tech advisors were strongly recommending using them. Those articles explained the memory structure and how it worked: in essence, the nand cells destroy data on read, and that has to be written back to save it: much like the old style wired magnetic core memories (that I can remember that far back dates me a bit). And nand cells have a write life. So the advice was, when using an SSD, disable regular memory intensive functions like de-fragmenting, since with a random access memory like SSD it contributed nothing to performance and very likely had a negative effect on the write life of the memory cells in the SSD. So, I did that: turned off scheduling for defrag for the whole system. The failure pattern for an SSD was theorised to be random, as compared to an HDD (which as a serial device would usually fail catastrophically).
And last week what I was seeing seemed to be random failures (BSOD's) every 15-20 minutes, but the machine after creating a minidump file was rebootable. Over 2 days I had about 20 of these events, and every time the app in use was different and the error message was also different. MS community examined the dump files, and explicated a cause (Ntkrnlmp.exe) and fix - a restore. So did a restore to the last one before the events began, and it completed Ok and re-booted. But failed again BSOD 20 mins later, and this time it would not re-boot, many tries, and the recovery disk issue as above was apparent. Several frustrating days.
Reflecting on the SSD advisories from years ago, I recalled that I had a spare brand new Samsung SSD. If it did not work, I had lost nothing. So I installed that, and behold! the bootable disks work again. And I was able to initialise, format and create the active partition for the OS (the DD12 disk), and then boot and start TI2021 (the TI2021 disk) and recover the 1 Aug backup, a copy of which was deliberately on one of the other HDD in the tower, for just this sort of eventuality. More time getting the boot priorities in the BIOS correct, and the desktop is live again. And after 3 days of use, no BSOD's.
So, clearly a desperate hypothesis re the original SSD was correct: bits of it were experiencing cell death, and I wondered why? It was a well known Kingston brand and at 4.5 years old it should not have done that. In fact, most ssd's from years ago would still not be into the cell death zone; one user I know of who was an early adopter (well before me) still had not experienced this phenomenon.Thinking about that I realised that since win10, for 2 years I'd been using Defender to do a whole of system AV scan once a week - and that by Defenders count that went to 2.75 million files read and tested over 2 hours. Quite probably a worse task for the SSD than a monthly de-fragment. And the BSOD's began the morning after the last weekly AV scan.
That's the story. So,
1. Recommendation; when using an SSD, don't do whole of PC AV scans unless there is an infection reason to do it. this would apply to windows defender and any 3rd party AV application - a concentrated read pattern from each type of program is the same.
2. Outstanding query: why would the recovery disks not boot when the failed SSD drive was installed? I suspect that this goes to the heart of how the Acronis recovery system is designed and that somehow it references the C drive even when booting linux from the CD. If so, it should not, reason above.
David, first it is good that you have identified the root issue here to your ageing SSD.
I would suspect that the Linux media attempts to perform some equivalent to CHKDSK during boot when it finds existing drives installed and that this is where it was failing. I have certainly tested my own boot media on systems with no installed drives and they were capable to doing so without throwing any errors other than the obvious that there were no drives present to allow any Acronis actions!
David,
I concur with Steve here. I do not recall you mentioning if your PC boots using UEFI or Legacy BIOS method which if booting using UEFI could impact the boot process of the created recovery media whether that be Linux or WinPE based simply because of how UEFI itself works.
Hi,
Apologies for the long response, with re-current BSOD issues even with a new SSD, I bit the bullet and replaced the system: new m/b, new RAM, new SSD, new cpu. And despite the time to get it up and running with the old apps and data that's working well.
To the issues around the old system, the gigabyte m/b BIOS was set for both legacy and UEFI. I've recovered and even updated systems (replace an old HDD with an SSD, boot DD12, configure the disk, boot TI and recover the C drive image) using the recovery disks without any issues in the past - until this event. Cause common to both apps. Just replacing the SSD with a new one fixed the boot problem, but the BSOD's kept happening. Thus the hardware upgrade.
Having the recovery disks fail to boot was pretty upsetting - for something had been so reliable in the past to break like that without any knowledge (the user guides haven't any info on it at all) speaks to something that really isn't in the app description. If it's going to fail, the fail message should at least be descriptive enough to indicate a cause, and the doco should include any expanded description about what and why. Can you pass this on the the devs please?
Dear David Hains,
In order to help you with this problem it is necessary to know the text of error during booting and logs after the restore. Thank you in advance.
David,
Sounds like you have a new system now that is performing without the BSOD problems, that's good even though required the replacement of most of the system.
Not sure of the age of the old Gigabyte MB but boards that are both Legacy and UEFI capable present challenges to users when booting external media at times. The older boards that were introduced along with UEFI are especially so. In my experience with this I found that setting such boards boot to either Legacy or UEFI depending on how the OS was installed solved most of the boot issues. My advice is choose one method, setup the bios for that method, and stick with it. It would be next to impossible to document boot and or BSOD errors with any granularityin my opinion.
If your new system still supports both Legacy and UEFI boot I suggest that however the OS was installed to boot should also be the only boot method setup in the bios to avoid boot (BSOD) problems going forward.