The problem wasn't the battery nor a broken wire in the power cord, since the battery was a new one I had inserted in the system after experiencing the same problem with the orginal one. And I had checked the voltage at the tip of the power cable that plugs into the laptop and found it to be as expected. And a power cable I borrowed from someone else with the same model of laptop also didn't help. I got another laptop while mine was being fixed. It was the same model. I inserted the hard drive from my laptop in the replacement laptop and tried booting. Unfortunately, I got the message below.
The last attempt to restart the system from its previous location
failed. Attempt to restart again?
Delete restoration data and proceed to sytem boot menu
Continue with system restart
I chose "Continue with system restart" and saw "Resuming Windows...", but then the system rebooted and I saw the same menu options again.
Thinking that perhaps there was some hardware difference between the replacement laptop and the one I had, even though they were the same model, I waited until the motherboard was fixed on my original one and then inserted the hard drive back into it. But I still got the same results with a message that "the last attempt to restart the system from its previous location failed." 1
Before doing anything else, I removed the SATA hard drive again, inserted it into another system and backed it up with Norton Ghost 2003. Ghost complained about the logfile on the system not being flushed, which I would expect, if the system had not been put through the normal shutdown routine.
| Error |
| Encountered an NTFS volume with a Logfile that has not been flushed (536)
|
I clicked on OK and then saw another Ghost warning.
| NTFS Problem Detected (1969) |
| Ghost has detecte problems with an NTFS volume. We recommend that you quit Ghost and correct the problem by rebooting NT and running CHKDSK. Alternatively, you may also continue normally.
|
I chose to continue and the backup proceeded without any problems. Afterwards
I booted the system the drive was in with an ERD Commander 2002 disc and ran
chkdsk /f on the drive. Chkdsk reported the following.
CHKDSK discovered free space marked as allocated in the master file table (MFT) bitmap. CHDKSK discovered free space makred as allocated in the volume bitmap. Windows has made corrections to the file system. ... 16186425 allocation units available on disk An unspeicifed error occurred.
I ran chkdsk a second time and the second time it reported "Windows has checked the file system and found no problems." I put the drive back in the laptop, but I still got the same message and menu instead of the system resuming from hibernation or booting into Windows. Since I was hoping to restore the system to its pre-hibernation state, I didn't choose to "continue with system restart."
I removed the drive from the laptop and put it back in the other system. I backed it up to DVDs again with Norton Ghost. This time Ghost didn't have any complaints about an NTFS logfile not being flushed and didn't give me any warnings.
Trying to figure out why I was getting the "the last attempt to restart the system from its previous location failed" message, I performed a Google search and at Hibernate once, resume many (HORM) in a nutshell 2, I found the following:
Ordinarily, NTLDR will check the header/signature of hiberfil.sys when the system begins the boot process in order to protect against a stale orphaned hiberfil.sys being booted. If a stale hiberfil.sys is detected, NTLDR will show a menu asking if you want to continue to resume or discard the hiberfil.sys and perform a full boot. You can create a file named resmany.dat (any size, any format) on the root of the boot partition (typically c:) to suppress this check and allow your device to resume without any user interaction.
The article also mentions that "EWF NTLDR is the only boot loader that has the logic to search for resmany.dat and skip the hiberfil.sys header check." More details on Ehanced Write Filter (EWF) is provided at New in-depth hibernate once resume many (HORM) white paper now available 3.
When a Windows system is put in hibernation
4
mode, Windows saves the contents
of memory to a hibernation file called hiberfil.sys in the root
directory on the system drive (C:\). The hiberfil.sys file
is large enough to hold the uncompressed contents of memory, so can be
fairly large depending on the amount of memory in the system.
Compression is used for the hiberfil.sys file to minimize disk
I/O and to improve hibernation and resume-from-hibernation performance.
When the system is turned back on, Ntldr will read the contents
of hiberfil.sys into memory and Windows should resume operations
from a point in memory that was recorded in the hiberfil.sys
hibernation file5.
The presence of hiberfil.sys in the root directory does not by
itself indicate the system has been placed into hibernation prior to being
shut down. The file may be found on the system because the system has been
configured to support hibernation so Windows has allocated space large enough
to hold the contents of memory by creating the hibernation file
hiberfil.sys. The determination must be made by checking the
first 4 KB of data in the file. If it begins with "hibr" and is followed
by four zeros (null characters) then Windows was
definitely hibernated. If it is full of zeroes Windows was definitely not
hibernated
6.
When I copied the file to a USB thumbdrive and examined it on a Linux
system with od, I saw "wake" in the first 4 bytes. You can't
open the hiberfil.sys file within Windows, at least the
hiberfil.sys file on the boot drive of that system, because
the operating system also keeps an open file handle for hiberfil.sys
, so no user, even an administrator can read the file while
Windows is running
7
ubuntu@ubuntu:~$ od -a -N 8 /media/TRAVELDRIVE/hiberfil.sys
0000000 w a k e nul nul nul nul
0000010
The file may also have "wake" in the first four bytes rather than "hibr" if the
system was put into hibernation mode and then there was an attempt to
resume from hibernation mode, which did not successfully complete. The
presence of "wake" at the beginning of the file tells ntldr
to prompt the user as to what should be done when the system is restarted
again8.
That was why I saw the message "The last attempt to restart the system
from its previous location failed. Attempt to restart again?", when I
restarted the system, though I don't know why it failed the first time.
It may have been because of the move of the drive to the replacement
laptop.
The hiberfil.sys file is loaded prior to
the registry being
loaded9,
so the problem I experienced couldn't be due to any registry change.
For a fuller explanation of the steps that occur prior to Windows loading
and where the NTLDR processing of hiberfil.sys resides in
the startup process see
How Windows Starts Up (Part the second)10
This is one of those problems where I would like to spend some more time figuring out exactly what is causing the problem and, hopefully, even getting to the point where I could reboot the system to where it was when I put it in hibernation. Perhaps I could do that with the EWF software, but I've already spent too much time on the issue already and need to move on to more pressing problems. I would like to be able to recover the unsaved information from open applications prior to the point I put the system in hibernation mode, but that information isn't critical. I have the backups and perhaps may try again some other day by backing up the drive again and then restoring it from a backup I've just made that presumably contains the hibernation file as it was when I put the system into hibernation mode. Of course, I have to presume Norton Ghost 2003 actually backs up that file. I don't have Ghost Explorer on a system that is handy at the moment to even verify that.
I know that realistically I'll probably never get back to it again, but I do have my notes here in case I should ever have free time to devote to researching the issue again as unlikely as that may be.
References:
Created: November 16, 2007