Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Hibernation Mode

62 views
Skip to first unread message

Slobodan Brcin (eMVP)

unread,
Apr 6, 2004, 11:16:28 AM4/6/04
to
You will need 128 MB of space for hibernation file. So this could be
possible cause.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Sean B" <anon...@discussions.microsoft.com> wrote in message
news:DEB1290B-68A0-4408...@microsoft.com...
> Hi All,
>
> I have created a version of XP(100mb-ish) that resides on a 256 Mb CF
card, due top requirement issues i need to boot quicker than a standard
boot, so i am attempting to boot via hibernation/ Venturcom ReadyOn. The
problem that the system has 128Mb of RAM and currently hibernation mode and
ReadyOn will not work. i think the problem is that my CF card isn't big
enough to have to OS &hibernation image file on? Can anybody confirm my
assumption?
>
> Thanks In Advance
>
> Sean B


Sean B

unread,
Apr 7, 2004, 2:56:05 AM4/7/04
to
I was aware that when using XP's hibernation i would need 128 Mb but this ReadyOn facility from Venturcom also requires a memory cache, wasn't sure whether this was on top of Hibernation or instead.

If you aren't aware ReadyOn appears to be hibernation plus, works along a similar line as EWF but ensure quick (hibernaton style boot)

----- Slobodan Brcin (eMVP) wrote: -----

Slobodan Brcin (eMVP)

unread,
Apr 7, 2004, 6:21:44 AM4/7/04
to
I have no idea how ReadyOn is implemented.

But if you are using RAM EWF and hibernation with little app for stateless
operation you wont need extra space on disk I mean no more than memory you
have.

For test purposes I have created application that allow me to hibernate and
to do same boot over and over again.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Sean B" <anon...@discussions.microsoft.com> wrote in message

news:33E7C30C-E684-4452...@microsoft.com...

Leonid

unread,
Apr 16, 2004, 8:00:21 PM4/16/04
to
"Slobodan Brcin \(eMVP\)" <sbr...@ptt.yu> wrote in message news:<#gt9jmIH...@TK2MSFTNGP10.phx.gbl>...


Hi, Slobodan
If I undestood correctly, using your application you can wake up from
hiber mode to the same state (using hiber file as master boot). Would
you like to provide me with this application and if it's posible with
source code? What did you mean as "stateless operation"?

\Leonid

KM

unread,
Apr 17, 2004, 4:03:54 AM4/17/04
to
Slobodan,

Since you are familiar with the hibernation process, could you help me
understanding the following questions please?

WinDDK doc says: "The kernel does disk I/O by direct calls to the disk dump
driver, diskdump.sys, bypassing filesystems, and the normal I/O stack. The
disk dump driver, in turn, calls the boot device's miniport driver to handle
all I/O operations, and the disk dump driver intercepts all of the miniports
calls to the port driver.".
Is this true for crash dumps only? Or hibernation also conforms to the
statement? My understanding was that the disk dump driver is used for both
without exceptions. If it is true for hibernation, then hiberfile.sys file
is not accessed through file system driver.

What driver level EWF is implemented (not file system driver for sure)? How
[RAM] EWF works along with disk dump driver? Would it be right to assume
that they are not interfering and changes in the hiberfil.sys are not
increasing EWF cache?

Sorry if it doesn't make sense to you. I'll rephase the questions then.
Konstantin

> In attachment you will find doc and application without the sources (I
> rarely give them away).
> I hope that this is last working version. Also do not use it in multi boot
> scenario machines.
>
> I made this application for Brad so he can test his image.
> This is not a full featured product and have many limitations.
>
> 1. Is must be used on FAT partition (OS Must be on fat partition).
> 2. OS partition should not have more that 32 files in root directory.
> 3. You must use RAM EWF (Disk EWF is out of question).
> 4. Before using my app to hibernate you must dismount all volumes that are
> not protected by EWF.
> 5. Before activating EWF for the first time you must make sure that
> hiberfile is placed in root of OS partition and that it is initialized to
> full size of your RAM.
> 6. After activating EWF reboot your device so EWF become enabled.
> 7. There is an issue with one brief moment during the resume if power is
cut
> off next time you boot user will be asked if he wants to resume or do
normal
> clean boot.
> 7a. I have solved this by creating special program placed in MBR for my
> device only testing purposes only.
>
>
> > If I understood correctly, using your application you can wake up from


> hiber mode to the same state (using hiber file as master boot).
>

> Yes, each boot will bring your device to exact same state.


>
> Regards,
> Slobodan
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Have an opinion on the effectiveness of Microsoft Embedded newsgroups?
Tell
> Microsoft!
> https://www.windowsembeddedeval.com/community/newsgroups
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

> "Leonid" <leonid.o...@med.ge.com> wrote in message
> news:6b4e508c.04041...@posting.google.com...

Slobodan Brcin (eMVP)

unread,
Apr 17, 2004, 5:45:46 AM4/17/04
to
Hi Konstantin,


Your questions make complete sense, also your understanding how dumpdirver
process works is 100% accurate (as per doc). But documentation is
incomplete.

1. Hibernation (saving data process during the shutdown) really bypass EWF
protection.
2. Creation of hiber file goes before that and it goes though filesystem so
it is imperative for EWF to be disabled first time file is created.
3. During resume.
3a. ntldr modifies first four bytes of hiber file from HIBR to WAKE. (to
mark that boot potentially gone wrong)
3b. Windows when resumed tries to invalidate first 512 bytes oh file to zero
trough FS, but RAM EWF stop it from doing it so.

So if you want that everything go smoothly you can make int 13 write call
filter that will prevent ntldr from changing HIBR to WAKE.
You could modify BIOS if you have custom BIOS (Just remove write calls and
return success).

Or in this instance with application, write application that bypasses EWF
and change WAKE to HIBR. Really simple.

Does this have any sense to you?

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"KM" <konstmor@nospam_yahoo.com> wrote in message
news:OOH7ARFJ...@TK2MSFTNGP10.phx.gbl...

KM

unread,
Apr 17, 2004, 3:08:06 PM4/17/04
to
Yup, it is much clearer now. Thanks a lot Slobodan, you are fount of
knowledge :-)

Just a few more additional questions:

1. Is diskdump.sys and atapi.sys driver dumping the hiberfil.sys? Do you
know any doc source where I can look for diskdump.sys interfaces? In DDK I
couldn't find much about it.

2. Yup, this is clear. I am not sure who creates the hibernation file, but
seems the call like "CallNtPowerInformation(SystemReserveHiberFile,..)" does
it:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/power/base/callntpowerinformation.asp.
Although it is not really important becuase it is always easy to disable EWF
and create the file.

3b. You're saying "Windows". Do you know which component does the zero'ing
first 512 bytes of the file?

Does your test app change WAKE to HIBR flag? Then do you open raw partition
data in user mode like CreateFile(\\\\.\\C:,..) or disk like
CreateFile(\\\\.\\PHYSICALDRIVE0,..) and seek for hiberfil.sys file? Then
you have probably implemented a small version of FS in the code? Is it the
reason for FAT[32] dependency only now? I guess NTFS is just more
complicated than FS in implementation.

Thanks,
Konstantin

Slobodan Brcin (eMVP)

unread,
Apr 17, 2004, 4:04:21 PM4/17/04
to
Hi Konstantin,

1. I have no idea if there is any documentation that describe this. I would
like to find it also just to read it nothing more.
2. According to doc it looks like this is the API call to reserve
hibernation file. Although I never tried this, but my guess is that it
should work.
You don't need to disable EWF you just need to hibernate once before
enabling it for first time.
3a. I never actually though about this since it is irrelevant because you
MUST USE RAM EWF to protect all open filesystems.
And EWF will prevent zero write from what ever driver or service that try to
do that. (This is the reason why I have never wanted to know which component
does this).

> CreateFile(\\\\.\\PHYSICALDRIVE0,..) and seek for hiberfil.sys file? Then
> you have probably implemented a small version of FS in the code? Is it the
> reason for FAT[32] dependency only now? I guess NTFS is just more
> complicated than FS in implementation.

Exactly as you described it. This is why I mentioned restrictions of current
implementation (I have done it fast just to test if this can be done, not
for commercial use).

Also all restrictions could be removed if there was a way to open
hibernation file while OS keeps it open.
I do not need neither read or write flags just need handle to send one IOCTL
code to obtain position of file relative to beginning of partition.

I have tried even with backup flags but without any luck. (Who knows maybe I
did not tried it hard enough).
Writing simple FAT FS parser was easier at the moment since hibernation file
is always in the root directory.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"KM" <konstmor@nospam_yahoo.com> wrote in message

news:ek9pc9KJ...@tk2msftngp13.phx.gbl...

KM

unread,
Apr 18, 2004, 4:16:56 AM4/18/04
to
Slobodan,

I understood what you said. I was asking previous questions mostly to bate
my curiosity :-)

Btw, have you tried "text based" hiberfil.sys on system partition?
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prmc_str_vzeb.asp
An ARC path linkmulti(W)disk(X)rdisk(Y)partition(Z) could link to another
partition with the actual memory image (hiberfil.sys). I haven't tried it
here (don't have a proper test enviroment here) but it is probably not hard
to test. The binary based hiberfil.sys could be moved to the second
partition offline (with the HDD pluged in another machine) and simple text
based hiberfil.sys may be created.

It is theoretical but this may help moving the hibernation dump to an EWF
unprotected partition and to use hibernation as in XP Pro (but still have
EWF protected system partition).

The only thing I tested here. When there is text based hiberfil.sys file on
system partition (OS1) but no binary hiberfil.sys on another partition
(OS2), the ntldr hangs after I choose to boot OS1. Strange that ntldr choice
screen appears what tells me that the text base hiberfil.sys may not work.
However, OS1 (not OS2) boot hangs and that showed something works.
Monday I may be able to perform more appropriate tests.

Thanks,
Konstantin

Slobodan Brcin (eMVP)

unread,
Apr 18, 2004, 5:30:54 AM4/18/04
to
Konstantin,

Been there done that. This file is automatically created when you hibernate,
but real hiber file must stay on OS partition and you can not move it.
EWF and hiber file play well together since dumpdriver bypasses EWF overlay
you don't have extra memory consumption.

Be cautious with changing file system from CD of some other non HDD OS. This
can have catastrophic consequences to your FS if you modify it offline and
then resume from hibernation.

Regards,
Slobodan


"KM" <konstmor@nospam_yahoo.com> wrote in message

news:#gSfQ2RJ...@TK2MSFTNGP09.phx.gbl...

KM

unread,
Apr 18, 2004, 3:16:44 PM4/18/04
to
Slobodan,

I already know about the dumpdriver and EWF working fine together as we
discussed this eailier.

The test I do now is just about moving hibernation dump to non-boot
partition (nothing EWF related). I don't see potential problems with such
implementation. Ntldr is aware of all the partitions, and could easy read
linkmulti ARC paths from text hiberfil.sys file and load binary hiberfil.sys
from another partition.

However, you must be right about the hiberfil.sys. Ntldr doesn't seem to
handle linkmulti's (I searched in ntldr binary) which means the MS link I
sent you previously did not say truth. The "\hiberfil.sys" path seems to be
hardcoded in ntldr.

I've gone furthur in my testing (all I could do without taking out the HDD)
and had the actual hiberfil.sys on another partition (although with first
512 bytes = 0, OS couldn't resume from it). But instead of using it
(updating it), OS replaced the text hiberfil.sys on the boot partition.

Anyway.. the final test I mentoned in my previous post I will be able to
perform only later this week. Actually, I am not going to change FS but just
move hiberfil.sys to another partition and have text based one on the boot
partition.

If I find anything interesting (which I doubt) I'll post it here.

Thanks,
Konstantin

Slobodan Brcin (eMVP)

unread,
Apr 18, 2004, 4:06:14 PM4/18/04
to
Like I said and as far as I can remember.

It is not important where ntldr will search for hiber file (he is stupid and
will follow ARC path in dummy hiberfil.sys located on boot partition).
But you need to persuade XPe to save and create hiber file on partition that
is different from OS partition.

Be cautious what ever you do it must be done while XPe is online and before
actual hibernation.

Regards,
Slobodan

"KM" <konstmor@nospam_yahoo.com> wrote in message

news:eKAxymXJ...@TK2MSFTNGP10.phx.gbl...

KM

unread,
Apr 21, 2004, 4:46:44 PM4/21/04
to
Hi Slobodan,

Just wanted to post the reply for the record. You were absolutely right about how the hibernation feature works on XP/XPe.
Playing with it for a few hours I can finally confirm that.

The bottom line is that ntldr is smart enough to read the text based hiberfil.sys to redirect read/write (hibr-->wake) requests to
another partition. But ntoskrnl.exe is stupid and exactly the component that creates/updates (set zeros for the first 512 bytes of
the file) the binary hiberfil.sys ALWAYS on boot partition (the partition with currently loaded OS, where the OS's Windows dir is
located).

So the real problem was how to generate the hiberfil.sys and move it to another partition while EWF is running and enabled. My
conclusion was that it is currently possible with only direct access to raw partition to pass EWF. This, however, requires parsing
the boot partitoin's FS. FAT parser is pretty straightforward but NTFS would be harder (is it documented enough to implemented the
NTFS parser?).

Here is more details on my results (you may not read it as you know all that already):

I played with the hibernation feature today on an XPe image with EWF running.
First of all, I was not clear in my understanding where hiberfil.sys is created. I thought it is always created on system partition
(where ntldr is). Especially the hardcoded "\hiberfil.sys" path in ntldr made me think this way. Now I finally know that the file is
created on boot (OS) partition (where the Windows directory is located). I should have probably read the docs more carefully (the
fact is stated in there).

One more observation. Yesterday I was playing with my laptop. Whenever I hibernated the system (XP Pro from first partition or XPe
from second partition) on the laptop and then turn on the machine again, ntldr menu did not appear (even though, I had the timeout
value <> 0). I thought it is a feature of ntldr (to disable boot menu if the machine has been hibernated). I was wrong. I could not
even boot off a CD-ROM. This means it is a BIOS feature.

Today I was playing with a Desktop ACPI machine and behavior was different (BIOS different). I could see the ntldr timeout menu if I
have hibernated the OS. This finally allowed me to easy switch between OSs and see the hiberfil.sys in "pure" form. I confirm now
there is "hibr"/"wake" flag at the beginning of the file that gets set by ntldr to mark the hiberfil.sys file (to be not used
again).

Now coming to EWF and hibernation.
First, when EWF is enabled on the OS partition, the hiberfil.sys is created in EWF cache. I can confirm that by the fact that when I
hibernate XPe image and reboot to XP Pro (another partition) I do not see the hiberfil.sys (or I see the old one, not changed). This
conflicts with all we discussed previously (or most likely I misunderstood your points) and means that the hiberfil.sys is created
through file system and EWF is catching all the writes.

Now the linkmulti path. It works as expected. The steps I made (the Hibernation is enabled in my image and the MS dump driver is in
place):
- boot to XPe
- disable EWF on XPe partition
- reboot to XPe again, make sure the hiberfil.sys is created.
- reboot to XP Pro, move the XPe's hiberfil.sys to another partition
- create a text based hiberfil.sys that has a "linkmulti" ARC path to that partition
- reboot to XPe ---> image resumes perfectly!
- here I see the binary (!) hiberfil.sys on the XPe partition.
- enable EWF on XPe partition, reboot to XPe for EWF to take in effect
- hibernate XPe image
- turn on machine and boot to XP Pro ---> I see binary hiberfil.sys on XPe partition.

Another experiment I have unsuccessfully tried was (EWF volume was present):
- setting up "good" hiberfil.sys ("hibr" flag in place) for XPe image with EWF disabled
- reboot to XP Pro and change the bytes in EWF volume to enable it (this works perfect without gaming with hibernation)
- reboot to XPe
- a black hanging screen after ntdr menu
This, of course, could be explain that the RAM EWF state from hiberfil.sys is not the same as from EWF volume. Anyway, it was a hack
and it did not work.

By the way, just for another recond, I was able to enable/disable EWF state of XPe protected partition from another OS by hacking
the binary flags in EWF configuration partition ONLY when EWF QFE (IRQL_NOT_LESS_OR_EQUAL) was applied to my image. Without the QFE
I have seen too many times IRQL_NOT_LESS_OR_EQUAL and 0x8E BSODs.

I have also tried to capture the complete system memory dump (CrashControl and i8042prt/CrashonCtrlScroll registry setting).
However, the memory dump and hiberfil.sys files are very different. Not knowing the hiberfil.sys format I couldn't reformat the
memory dump to be used for hibernate resume. Also, the hiberfil.sys memory pages are compressed (again, don't know details).

The bottom line here - need a way to somehow capture hiberfil.sys with EWF enabled protecting boot partition. Only way - access to
raw partition data and parsing FS. This is, if I understood correctly, what you have done in your test app.

This was a long post. Sorry about that.
--
Konstantin

Slobodan Brcin (eMVP)

unread,
Apr 21, 2004, 5:35:11 PM4/21/04
to
Hi Konstantin,

> The bottom line is that ntldr is smart enough to read the text based
hiberfil.sys to redirect read/write (hibr-->wake) requests to
> another partition. But ntoskrnl.exe is stupid and exactly the component
that creates/updates (set zeros for the first 512 bytes of
> the file) the binary hiberfil.sys ALWAYS on boot partition (the partition
with currently loaded OS, where the OS's Windows dir is
> located).

Correct!

> So the real problem was how to generate the hiberfil.sys and move it to
another partition while EWF is running and enabled. My
> conclusion was that it is currently possible with only direct access to
raw partition to pass EWF. This, however, requires parsing
> the boot partitoin's FS. FAT parser is pretty straightforward but NTFS
would be harder (is it documented enough to implemented the
> NTFS parser?).

More or less. Even if you could move file from one to other partition this
would not work. Since hiber file will contain traces of open files, file
system etc, and you can't change that fact so moving hiber file would not be
smart thing.

> One more observation. Yesterday I was playing with my laptop. Whenever I
hibernated the system (XP Pro from first partition or XPe
> from second partition) on the laptop and then turn on the machine again,
ntldr menu did not appear (even though, I had the timeout
> value <> 0). I thought it is a feature of ntldr (to disable boot menu if
the machine has been hibernated). I was wrong. I could not
> even boot off a CD-ROM. This means it is a BIOS feature.

Nop it is not a BIOS feature.
If hiberfil.sys is found on boot partition (ntldr partition) it always takes
precedence over the boot.ini

> Today I was playing with a Desktop ACPI machine and behavior was different
(BIOS different). I could see the ntldr timeout menu if I
> have hibernated the OS. This finally allowed me to easy switch between OSs
and see the hiberfil.sys in "pure" form. I confirm now
> there is "hibr"/"wake" flag at the beginning of the file that gets set by
ntldr to mark the hiberfil.sys file (to be not used
> again).

WAKE - Means that XPe resume failed in previous attempts, and that ntldr
should ask user what to do.
Zeroes means that it should not be used again.

Same behavior, but boot partition was probably protected by EWF (probably
mistake in configuring ARC path) so small hibrfil.sys was not saved on boot
partition.

> Now coming to EWF and hibernation.
> First, when EWF is enabled on the OS partition, the hiberfil.sys is
created in EWF cache. I can confirm that by the fact that when I
> hibernate XPe image and reboot to XP Pro (another partition) I do not see
the hiberfil.sys (or I see the old one, not changed). This
> conflicts with all we discussed previously (or most likely I misunderstood
your points) and means that the hiberfil.sys is created
> through file system and EWF is catching all the writes.

I though that I have stated that fact very clearly in the beginning of the
thread. Please reread it carefully. EWF must be disabled at first time we
create hibrfil.sys since it goes trough FS.

> Now the linkmulti path. It works as expected. The steps I made (the
Hibernation is enabled in my image and the MS dump driver is in
> place):
> - boot to XPe
> - disable EWF on XPe partition
> - reboot to XPe again, make sure the hiberfil.sys is created.
> - reboot to XP Pro, move the XPe's hiberfil.sys to another partition
> - create a text based hiberfil.sys that has a "linkmulti" ARC path to
that partition
> - reboot to XPe ---> image resumes perfectly!
> - here I see the binary (!) hiberfil.sys on the XPe partition.
> - enable EWF on XPe partition, reboot to XPe for EWF to take in effect
> - hibernate XPe image
> - turn on machine and boot to XP Pro ---> I see binary hiberfil.sys
on XPe partition.

I don't understand this attempt with moving hiberfil.sys to other partition.
But I guess that it is has no effect, right?

> Another experiment I have unsuccessfully tried was (EWF volume was
present):
> - setting up "good" hiberfil.sys ("hibr" flag in place) for XPe image
with EWF disabled
> - reboot to XP Pro and change the bytes in EWF volume to enable it
(this works perfect without gaming with hibernation)
> - reboot to XPe
> - a black hanging screen after ntdr menu
> This, of course, could be explain that the RAM EWF state from hiberfil.sys
is not the same as from EWF volume. Anyway, it was a hack
> and it did not work.

This one attempt I can even understand. I don't understand what did you
expect to gain from this one.

> By the way, just for another recond, I was able to enable/disable EWF
state of XPe protected partition from another OS by hacking
> the binary flags in EWF configuration partition ONLY when EWF QFE
(IRQL_NOT_LESS_OR_EQUAL) was applied to my image. Without the QFE
> I have seen too many times IRQL_NOT_LESS_OR_EQUAL and 0x8E BSODs.

Fist you should use registry only solution for EWF.
Second why do you disable / enable EWF is should be enabled.

> I have also tried to capture the complete system memory dump (CrashControl
and i8042prt/CrashonCtrlScroll registry setting).
> However, the memory dump and hiberfil.sys files are very different. Not
knowing the hiberfil.sys format I couldn't reformat the
> memory dump to be used for hibernate resume. Also, the hiberfil.sys memory
pages are compressed (again, don't know details).
>
> The bottom line here - need a way to somehow capture hiberfil.sys with EWF
enabled protecting boot partition. Only way - access to
> raw partition data and parsing FS. This is, if I understood correctly,
what you have done in your test app.

I fail to see what are you trying to do.

If you want to just simply hibernate once and resume many times then follow
my instructions to the letter.
If not I have no idea what you want to do with hiberfil.sys even if you copy
it somewhere it would change nothing, it would be meaningless on non OS
partition.

Parsing of FS can be skipped if you can find a way to get any handle of
hibrfil.sys with CreateFile function I have failed in that.

BTW:

Why are you trying to move hiberfil.sys?
It is not in conflict with EWF.

Regards,
Slobodan

KM

unread,
Apr 21, 2004, 7:39:48 PM4/21/04
to
Slobodan,

> More or less. Even if you could move file from one to other partition this
> would not work. Since hiber file will contain traces of open files, file
> system etc, and you can't change that fact so moving hiber file would not
be smart thing.

Yup, I know that.
I also thought about hooking up the system dump procedure. E.g. using new
XP/SP1 kernel APIs to register dump callback BugCheckDumpIoCallback to
redirect crash dump data to a device (a device could a second HDD). Then we
may get the real crash dump data on a different storage. However, it
requires writing a new disk driver, right? I am not very good at that.

> I thought it is a feature of ntldr (to disable boot menu if
> the machine has been hibernated). I was wrong. I could not
> > even boot off a CD-ROM. This means it is a BIOS feature.
>
> Nop it is not a BIOS feature.
> If hiberfil.sys is found on boot partition (ntldr partition) it always
takes precedence over the boot.ini

I don't think this is true. On my second machine (ACPI desktop) I have got
first system partition (where ntldr) with XP Pro installed on it
(hibernation is ON). There is a hiberfil.sys file that I can't access from
XP Pro but can access from XPe booting from a second partiton.
On other hand, on the XPe second partion I also see another hiberfil.sys
file that I can't access from XPe but I can from XP Pro (that is how I
explored the file).
And there is no precedence procedure taken by the ntldr on the machine. I.e.
I can resume to any of the hiberfil.sys files depending on what I select in
the ntldr boot menu. Again, this is the BIG difference I discovered between
my laptop and Desktop machine.
Can you explain that?


> > there is "hibr"/"wake" flag at the beginning of the file that gets set
by
> ntldr to mark the hiberfil.sys file (to be not used again).
>
> WAKE - Means that XPe resume failed in previous attempts, and that ntldr
should ask user what to do.
> Zeroes means that it should not be used again.

Yup, agree. I thought I have stated the fact above. Sorry if I wasn't clear.

> Same behavior, but boot partition was probably protected by EWF (probably
> mistake in configuring ARC path) so small hibrfil.sys was not saved on
boot partition.

Sorry, I can't understand what you just said. Could you explain me what you
meant here?
Assume there is no mistakes in configuring ARC paths (otherwise I wouldn't
be able to play with all this).

> > Now coming to EWF and hibernation.
> > First, when EWF is enabled on the OS partition, the hiberfil.sys is
> created in EWF cache. I can confirm that by the fact that when I
> > hibernate XPe image and reboot to XP Pro (another partition) I do not
see
> the hiberfil.sys (or I see the old one, not changed). This
> > conflicts with all we discussed previously (or most likely I
misunderstood
> your points) and means that the hiberfil.sys is created
> > through file system and EWF is catching all the writes.
>
> I though that I have stated that fact very clearly in the beginning of the
> thread. Please reread it carefully. EWF must be disabled at first time we
> create hibrfil.sys since it goes trough FS.

Talking about steps #5 and #6? Actually, I have created the hiberfil.sys
file when EWF was disabled. No problem with that.
By creation do you mean the FIRST creation or a creation at every boot?
Consider this scenerio I tested:
- EWF is disabled:
- boot to XPe, hibernate
- reboot to XP Pro. I see hiberfil.sys on the XPe partition (checked the
"hibr" flag is set).
- reboot to XPe (resume to XPe)
- enable EWF/reboot to take it in effect. Check EWF is enabled,
hiberfil.sys is on the XPe partition
- reboot to XP Pro, check hiberfil.sys on XPe partition has 512 bytes
set to "0"
- reboot to XPe, hibernate
- reboot to XP Pro. I see the same hiberfil.sys with 512 bytes set to
"0" (the same date/time stamp).
- I can't resume XPe and see "Delete restore ...." ntldr's message.

Doesn't that mean EWF is preventing from updating the hiberfil.sys?
Ok. I'll retest the scenerio again just to make sure I did not screw it up
at any step.

> I don't understand this attempt with moving hiberfil.sys to other
partition.

The attempt has been made just to understand how it works :-)

> But I guess that it is has no effect, right?

Right.

> > Another experiment I have unsuccessfully tried was (EWF volume was
> present):
> > - setting up "good" hiberfil.sys ("hibr" flag in place) for XPe
image
> with EWF disabled
> > - reboot to XP Pro and change the bytes in EWF volume to enable it
> (this works perfect without gaming with hibernation)
> > - reboot to XPe
> > - a black hanging screen after ntdr menu
> > This, of course, could be explain that the RAM EWF state from
hiberfil.sys
> is not the same as from EWF volume. Anyway, it was a hack
> > and it did not work.
>
> This one attempt I can even understand. I don't understand what did you
> expect to gain from this one.

According to documentation the hibernation works as standby + RAM dump to
disk. When the machine resumes from hiberfil.sys it then re-initilizes all
the drivers. I thought EWF would also be "re-initialized". Since I have got
EWF configuration volume which I hacked to enable EWF (from XP Pro while XPe
have been hibernated), EWF might read its state from the config volume on
XPe resume.
But it did not work anyway.

> > By the way, just for another recond, I was able to enable/disable EWF
> state of XPe protected partition from another OS by hacking
> > the binary flags in EWF configuration partition ONLY when EWF QFE
> (IRQL_NOT_LESS_OR_EQUAL) was applied to my image. Without the QFE
> > I have seen too many times IRQL_NOT_LESS_OR_EQUAL and 0x8E BSODs.
>
> Fist you should use registry only solution for EWF.

This is not related to the IRQL_NOT_LESS_OR_EQUAL problem, isn't it?

> Second why do you disable / enable EWF is should be enabled.

Forget about my point here. I was just discribing one of the observation I
made. Not related to hibernation.

> I fail to see what are you trying to do.
>
> If you want to just simply hibernate once and resume many times then
follow my instructions to the letter.
> If not I have no idea what you want to do with hiberfil.sys even if you
copy
> it somewhere it would change nothing, it would be meaningless on non OS
partition.

I was just trying to find a way to avoid FS parsing. As I stated ealier, I
was just experimenting with the hibernation (no coding yet).

> Parsing of FS can be skipped if you can find a way to get any handle of
> hibrfil.sys with CreateFile function I have failed in that.

I have failed in that either. From my understanding ntoskrnl.exe (doesn't
matter who) locks the file with no share read access.

> BTW:
>
> Why are you trying to move hiberfil.sys? It is not in conflict with EWF.

In my case it is... And that is what I can't understand. I must have been
doing something wrong but enabled EWF is preventing XPe from updating
hiberfil.sys file on the XPe partition.

Konstantin


Slobodan Brcin (eMVP)

unread,
Apr 21, 2004, 8:36:11 PM4/21/04
to
Konstantin,

Ok I see that we have different behaviour. At my device hibernation goes
around the EWF.
Since Brad was able to use my application for testing then I guess that it
is something in a way how you configured your XPe image.

To be more compatible with me you should:
0. Disable hibernation support in Windows XP Prof so it does not pollute
first partition with hibernation file.
1. Use Reg RAM EWF with disabled as default. (Use latest EWF)
2. Hibernate your XPe.
3. Resume XPe.
4. Enable EWF. (Make sure that it is protecting XPe partition)
5. Reboot.
6. Hibernate.
7. Resume as many times as you want. (On prompt made by ntldr because of
WAKE flag just tell him to resume instead of normal boot).

This should work, I don't know why you have behaviour that you describe.
Also ntldr will use boot.ini only in case that something is wrong with
hibernation file in same folder with ntldr.
If this file is link or contain valid hibernation data it should resume.

Also you may damage data by switching between XP, XPe.
You should use bootable CD since it is neutral, to access files if you want
to watch them.


> > More or less. Even if you could move file from one to other partition
this
> > would not work. Since hiber file will contain traces of open files, file
> > system etc, and you can't change that fact so moving hiber file would
not
> be smart thing.
>
> Yup, I know that.
> I also thought about hooking up the system dump procedure. E.g. using new
> XP/SP1 kernel APIs to register dump callback BugCheckDumpIoCallback to
> redirect crash dump data to a device (a device could a second HDD). Then
we
> may get the real crash dump data on a different storage. However, it
> requires writing a new disk driver, right? I am not very good at that.

I have a great deal of experience with various drivers, but I don't know if
BugCheckDumpIoCallback would triger on hibernation, but nevertheless even if
we could do that, why would we want to move hibernation file, I fail to see
the reason. (Assuming that you can make EWF to coexsist with hibernation
file)

> > I thought it is a feature of ntldr (to disable boot menu if
> > the machine has been hibernated). I was wrong. I could not
> > > even boot off a CD-ROM. This means it is a BIOS feature.
> >
> > Nop it is not a BIOS feature.
> > If hiberfil.sys is found on boot partition (ntldr partition) it always
> takes precedence over the boot.ini
>
> I don't think this is true. On my second machine (ACPI desktop) I have got
> first system partition (where ntldr) with XP Pro installed on it
> (hibernation is ON). There is a hiberfil.sys file that I can't access from
> XP Pro but can access from XPe booting from a second partiton.
> On other hand, on the XPe second partion I also see another hiberfil.sys
> file that I can't access from XPe but I can from XP Pro (that is how I
> explored the file).
> And there is no precedence procedure taken by the ntldr on the machine.
I.e.
> I can resume to any of the hiberfil.sys files depending on what I select
in
> the ntldr boot menu. Again, this is the BIG difference I discovered
between
> my laptop and Desktop machine.
> Can you explain that?
>

Try to hibernate from Windows XP Pro. And see if resume will ask you
anything.

> > Same behavior, but boot partition was probably protected by EWF
(probably
> > mistake in configuring ARC path) so small hibrfil.sys was not saved on
> boot partition.
>
> Sorry, I can't understand what you just said. Could you explain me what
you
> meant here?

I meant that your EWF has been protecting partition with ntldr, but now I
don't think that it was your case.

Don't do that. EWF should be enabled already.

Slobodan


KM

unread,
Apr 21, 2004, 8:53:00 PM4/21/04
to
Slobodan,

Please disregard my comments about the hibernation while EWF enabled. It works (as we discussed previously) and hiberfil.sys file is
definitely getting updated bypassing EWF. Sorry, my fault - I wasn't accurate in the testing (scandisk on XP Pro was reverting the
changes in hiberfil.sys back).

--
KM,
BSquare Corporation

Slobodan Brcin (eMVP)

unread,
Apr 21, 2004, 8:56:13 PM4/21/04
to
Konstantin,

I'm glad that we have sorted this out :-)

Regards,
Slobodan

PS:
I will be going early to bed so see you tomorrow ;)


"KM" <kons...@nospam.yahoo.com> wrote in message
news:O2RQqQAK...@TK2MSFTNGP11.phx.gbl...

KM

unread,
Apr 21, 2004, 9:06:18 PM4/21/04
to
Slobodan,

Sorry for keeping you awake for so long :-)

To be honest, the bug in EWF (the one which has been fixed by the QFE) was screwing things down on my machine confusing OSs and
always forcing chkdsk at the XP Pro boot which changed the hiberfil.sys (I am using NTFS). Until I figured this out I was thinking
EWF interferes with hibernation.
Good that it does not :-)

--
KM,
BSquare Corporation

Slobodan Brcin (eMVP)

unread,
Apr 21, 2004, 9:31:48 PM4/21/04
to
Konstantin,

You are not responsible for my "just this one thing to do" and then I'm
gone, who knows maybe when we switch to metric time day will last longer :D

Be sure how you use hibernation in multi boot scenarios, it can seriously
damage unprotected and open filesystems that were hibernated and then used
by some other OS.

Regards,
Slobodan

"KM" <kons...@nospam.yahoo.com> wrote in message

news:u3UeFYA...@TK2MSFTNGP11.phx.gbl...

KM

unread,
Apr 22, 2004, 3:49:59 AM4/22/04
to
> This should work, I don't know why you have behavior that you describe.

> Also ntldr will use boot.ini only in case that something is wrong with
> hibernation file in same folder with ntldr.
> If this file is link or contain valid hibernation data it should resume.

Yup.. I finally can confirm that.

> Also you may damage data by switching between XP, XPe.

You were very close in your guess! :-)

> I have a great deal of experience with various drivers, but I don't know if
> BugCheckDumpIoCallback would triger on hibernation, but nevertheless even if
> we could do that, why would we want to move hibernation file, I fail to see
> the reason. (Assuming that you can make EWF to coexsist with hibernation file)

Forget it since now EWF lives in harmony with hibernation even on my machine. And therefore there is no reason to move hiberfil.sys
file to another partition.

But let me explain why I needed to move the file to another (not boot) partition. I needed a way to change the hiberfil.sys file
from OS level (therefore having access to OS FS features).
If you have a text based hiberfil.sys file on boot partition and binary hiberfil.sys on another, when the OS resumes it updates and
locks only the first file (that is why I think ntoskrnl.exe is more stupid about the location of hiberfil.sys than ntldr). The
ntoskrl looks and updates the file through FS and therefore all the changes could be lost with EWF enabled. This is what I need!
Here is steps:
(I use NTFS on all the partitions)
- I hibernate XPe image (2nd partition) with EWF enabled
- boot to XP Pro from first partition
- move the hiberfil.sys file to a 3rd partition (even a second disk, but this is not important)
- create text based hiberfil.sys in place of the old binary hiberfil.sys on the XPe partition
- reboot to XPe - XPe resumes just fine
- reboot (or suddenly shutdown and power on the machine) to XP Pro again. The text hiberfil.sys is still there on the XPe
partition (see explanation above). But binary hiberfil.sys on the 3rd partition is changed (ntldr replaced "hibr" flag by "wake"). I
change the flag back.
- reboot - resume to XPe again!

This scenario works perfectly. However it includes booting to another OS.

I really wanted to boot to XPe only and change "wake" flag to "hibr" in the binary hiberfil.sys file on the 3rd (unprotected!)
partition. If I change it during boot time (a service), then if the machine suddenly reboots it will resume to XPe with always the
same master image.
This does not work, however. And the reason is in FS. When I hibernate XPe, boot to XP Pro, change the hiberfil.sys and then resume
XPe again, the FS (NTFS in my case) knows only the old hiberfil.sys file (or at least its old time stamp) and I cannot open the file
as it says the file is corrupted. It is not, though. It has just been changed in another OS.
Initially I thought NTFS is smart enough to pick up the dynamic changes in a file, even if the file has not been changed through the
FS. But probably there is some FS cache in RAM (or whatever) that gets saved during hibernation dump.

Does it all make sense to you?

And still BugCheckDumpIoCallback. If it gets triggered during hibernation dump, then I could PROPERLY save the hiberfil.sys dump
file on the 3rd partition. Then boot to XP Pro (or boot off a CD), replace the hiberfil.sys file on the XPe partition by the text
link file and I get the "always resume" image.

> > > BIOS on laptop....


> > Again, this is the BIG difference I discovered between my laptop and Desktop machine.
> > Can you explain that?
> >
> Try to hibernate from Windows XP Pro. And see if resume will ask you anything.

I hibernate it from XP Pro. The ntldr never ask for anything (no timeout menu). This is on my laptop only (I can give your more info
on the BIOS, etc.).

Thank a lot for your help.
Konstantin

Slobodan Brcin (eMVP)

unread,
Apr 22, 2004, 2:39:33 PM4/22/04
to
Konstantin,

I fail to see big picture about what you are trying to do because if you
successfully move hibernation file to some other partition, and then try to
resume you will have to provide your OS with exact state in all file systems
that have been opened during the initial hibernation. (You can always
dismount filesystem before hibernation all except the FS with XPe).

So you will gain nothing if you move hiber image data. (You will still need
exact XPe partition image to be present during all later boots).
Also why do you use second OS. It makes you only troubles in your testing,
you can always access hibernation file trough parsing of filesystem and
using the physical disk only? For FAT this is a few hour of work and for
NTFS it would require some little hacking of NTFS file structure (It can't
be that hard).

We are not talking about writing full FS support only support to access root
directory to find out about position of hibrfil.sys from there. And then we
need only first 4 bytes to change, which is simple.

Or as a alternative you can always prevent ntldr. in the first place from
writing any data to disk. So no matter which FS you use this will work.

Best regards,
Slobodan

"KM" <kons...@nospam.yahoo.com> wrote in message

news:ukPuq5DK...@TK2MSFTNGP09.phx.gbl...

KM

unread,
Apr 22, 2004, 4:43:51 PM4/22/04
to
Slobodan,

Haven't I bothered you enough with my experiments? Feel free to stop the thread.

> I fail to see big picture about what you are trying to do because if you
> successfully move hibernation file to some other partition, and then try to
> resume you will have to provide your OS with exact state in all file systems
> that have been opened during the initial hibernation.

My thought was that this is not exactly true. I am not changing anything in FS beside the hiberfil.sys file.
However now I see that you are right (played enough with NTFS and FAT FS after hibernation).

> So you will gain nothing if you move hiber image data. (You will still need
> exact XPe partition image to be present during all later boots).
> Also why do you use second OS. It makes you only troubles in your testing,
> you can always access hibernation file trough parsing of filesystem and
> using the physical disk only? For FAT this is a few hour of work and for

Yup, you have done it already.

> NTFS it would require some little hacking of NTFS file structure (It can't be that hard).

This is what I do not want to do. I wanted somehow to avoid writing any FS specific code and use Windows to change the files.
Sounds crazy but that is what I wanted.

> We are not talking about writing full FS support only support to access root

> directory to find out about position of hiberfil.sys from there. And then we need only first 4 bytes to change, which is simple.

Absolutely agree. That is what it makes it easy for FAT access.

> Or as a alternative you can always prevent ntldr. in the first place from
> writing any data to disk. So no matter which FS you use this will work.

Thank again for the discussion!
The thread may be helpful for someone else who is going to try these routes and for future references.
Konstantin


Slobodan Brcin (eMVP)

unread,
Apr 22, 2004, 5:37:12 PM4/22/04
to
Konstantin,

> Haven't I bothered you enough with my experiments? Feel free to stop the
thread.

Nop :) I always like to discuss about some new approach that I have not
thought of. (It is always possible with myriads of Win32 and Native API
functions).

Goal for us would be to gain handle (any access type of handle) to
hiberfil.sys.

Maybe key for this is to determining who exactly and at which point in boot
time lock down this file.
If some service is doing this then we could write some ultra light service
to start before that for determining sectors on disk occupied by hibernation
file.
I have done that for any file that I can obtain handle to.

For all time I wanted to avoid considering writing simple filter driver.
If you make FS filter driver that would monitor all file opens then you
would not have problems, since you could always obtain info you need from
this driver for any locked file.
I hate making unnecessary backdoors, there is enough of them already you
just need to find them ;)

And now one more thing:, I have done this approach just because it was easy
for concept testing purposes, this is not intended for commercial use
because of boot process.

1. ntldr load image.
2. ntldr writes WAKE instead of HIBR.
3. Windows (what ever driver or service, or ntoskrnl itself) tries to zero
512 bytes.
Disk<-Partition<-EWF<-FS<-hiberfil.sys<- Something write 512 zeroes. EWF
will prevent this. One part of problem is solved by EWF so we don't have to
worry.
4. We change WAKE to HIBR.
5. Everything is ok.

But if power is cut off or hardware fail to initialize between steps 3 and 4
(very short period of time). We would end up with WAKE in hiberfil.sys and
this is not how real solution should look like.

Another good approach that I have made just to work on my test device was:

1. I have copied MBR code to next 512 bytes of disk.
2. Then I place my MBR with my code (of course) to first 512 bytes.
3. MBR only task is to hook to int 13 commands and simulate write requests
as successful. And to load and execute MS MBR structure.
4. ntldr load image.
5. ntldr try to write WAKE instead of HIBR and think that write was ok.
6. Windows (what ever driver or service, or ntoskrnl itself) tries to zero
512 bytes.
Disk<-Partition<-EWF<-FS<-hiberfil.sys<- Something write 512 zeroes. EWF
will prevent this. Remaining part of problem is solved by EWF so we don't
have to worry.
7. Everything is ok.

If you have sources for custom BIOS you could just simply leave out write
support functions from your BIOS and that would do the trick.

Few months ago I have suggested to MS to make special support for this:
During special hibernation once resume many request they should write
something like HIBM instead of HIBR.
And ntldr when sees code HIBM it should resume image without modifying HIBM
signature. Simple as that few lines of code for them in ntldr.
But they should add additional API support for hibernating in this way and
to optionally allow us to disable this mode. (This would require them to
bypass EWF as I did).


Any comments on all of this?
Slobodan

"KM" <kons...@nospam.yahoo.com> wrote in message

news:OmE9FqKK...@TK2MSFTNGP11.phx.gbl...

KM

unread,
Apr 23, 2004, 1:00:56 PM4/23/04
to
Slobodan,

> Goal for us would be to gain handle (any access type of handle) to hiberfil.sys.

Yes, that would be nice to get a handle of the hiberfil.sys with write access.

> Maybe key for this is to determining who exactly and at which point in boot time lock down this file.

A quick look showed that the system (power control applet) reserves the file via a call to CallNtPowerInformation (exported by
powrprof.dll).
The CallNtPowerInformation is just a wrapper to NtPowerInformation function of NTDLL. NtPowerInformation most like ends up
somewhere in kernel (int 2e?). If you do a binary search in \system32 for "hiberfil.sys" you will only hit ntoskrnl.exe.

> If some service is doing this then we could write some ultra light service

Could be the "Windows Power Profile Handler" of w2k/xp kernel. Just a guess, nothing more.

> to start before that for determining sectors on disk occupied by hibernation file.
> I have done that for any file that I can obtain handle to.
>

> And now one more thing:, I have done this approach just because it was easy
> for concept testing purposes, this is not intended for commercial use because of boot process.
>
> 1. ntldr load image.
> 2. ntldr writes WAKE instead of HIBR.
> 3. Windows (what ever driver or service, or ntoskrnl itself) tries to zero
> 512 bytes.
> Disk<-Partition<-EWF<-FS<-hiberfil.sys<- Something write 512 zeroes. EWF
> will prevent this. One part of problem is solved by EWF so we don't have to worry.
> 4. We change WAKE to HIBR.
> 5. Everything is ok.
> But if power is cut off or hardware fail to initialize between steps 3 and 4
> (very short period of time). We would end up with WAKE in hiberfil.sys and
> this is not how real solution should look like.

Exactly :-( This was the reason why I was trying to "capture" (redisrect) the hiberfil.sys file *before* (or during) the system
goes to hibernate state. As you already know it did not work well.

I got another idea - what if we replace the "wake" flag hardcoded in ntldr by "hibr". The ntldr does not seem to do a CRC check
(boot
sector just jumps to the ntldr code). The only problem left in the scenerio you described above is that ntldr changes "hibr" to
"wake". We'll force the loader to always use
"hibr" sequence. I have just made a successfull test on my machine - works like a charm. Regardless of how I restart once hibernated
machine (sudden power off, restart, hibernate again, etc.) the machine alsways resumes!

Unfortunately, it is a hack in MS binaries and would not be legal for comersial distribution. But for sake of having technical
solution - that works just fine.

Btw, I wanted to test it yesterday but did not have a way to do that on my laptop - the "BIOS" problem is still there. Kinda weird
problem.

> Another good approach that I have made just to work on my test device was:
>
> 1. I have copied MBR code to next 512 bytes of disk.
> 2. Then I place my MBR with my code (of course) to first 512 bytes.
> 3. MBR only task is to hook to int 13 commands and simulate write requests
> as successful. And to load and execute MS MBR structure.
> 4. ntldr load image.
> 5. ntldr try to write WAKE instead of HIBR and think that write was ok.
> 6. Windows (what ever driver or service, or ntoskrnl itself) tries to zero
> 512 bytes.
> Disk<-Partition<-EWF<-FS<-hiberfil.sys<- Something write 512 zeroes. EWF
> will prevent this. Remaining part of problem is solved by EWF so we don't
> have to worry.
> 7. Everything is ok.

Great! I was thinking yesterday of something similar but I wanted to change system boot sector (not MBR).
However, changes in MBR must be easier. If we change the boot sector, we again have "problems" with different boot sector
implementations on different FSs.

> If you have sources for custom BIOS you could just simply leave out write
> support functions from your BIOS and that would do the trick.
>
> Few months ago I have suggested to MS to make special support for this:
> During special hibernation once resume many request they should write
> something like HIBM instead of HIBR.
> And ntldr when sees code HIBM it should resume image without modifying HIBM
> signature. Simple as that few lines of code for them in ntldr.
> But they should add additional API support for hibernating in this way and
> to optionally allow us to disable this mode. (This would require them to
> bypass EWF as I did).
> Any comments on all of this?

This idea is very deliberate. However, only MS can do that in ntldr source as we can't change it in binaries mostly because of legal
issues (not mentioning technical
problems) and therefore we may not expect it in near future (Longhorn time frames?!). Or.. XPe Team might provide the changes in EWF
ntldr (new QFE) to handle this hibernate scenerio.
The changes could be implemented in a few lines of code. Shoudn't be a problem. Even with testing the feature.

Konstantin


Slobodan Brcin (eMVP)

unread,
Apr 23, 2004, 2:05:14 PM4/23/04
to
Konstantin,

> > Goal for us would be to gain handle (any access type of handle) to
hiberfil.sys.
> Yes, that would be nice to get a handle of the hiberfil.sys with write
access.

There is no need for write access, any access would be good. Since EWF is
protecting volume you can't use this handle to write anyway. But you can use
IOCTL codes to obtain file position relative to the partition beginning,
which is more than enough.

> I got another idea - what if we replace the "wake" flag hardcoded in ntldr
by "hibr". The ntldr does not seem to do a CRC check
> (boot
> sector just jumps to the ntldr code). The only problem left in the

scenario you described above is that ntldr changes "hibr" to


> "wake". We'll force the loader to always use
> "hibr" sequence. I have just made a successfull test on my machine - works
like a charm. Regardless of how I restart once hibernated
> machine (sudden power off, restart, hibernate again, etc.) the machine
alsways resumes!
>
> Unfortunately, it is a hack in MS binaries and would not be legal for
comersial distribution. But for sake of having technical
> solution - that works just fine.

Yup.

> Great! I was thinking yesterday of something similar but I wanted to
change system boot sector (not MBR).
> However, changes in MBR must be easier. If we change the boot sector, we
again have "problems" with different boot sector
> implementations on different FSs.

MBR is much easier to handle since it is very simple and before partition
table it is only code that can be reallocated.

> The changes could be implemented in a few lines of code. Shouldn't be a


problem. Even with testing the feature.

My thoughts exactly, and it would mean allot to XPe.

Regards,
Slobodan


KM

unread,
Apr 23, 2004, 3:29:46 PM4/23/04
to
Slobodan,

> There is no need for write access, any access would be good. Since EWF is
> protecting volume you can't use this handle to write anyway. But you can use
> IOCTL codes to obtain file position relative to the partition beginning, which is more than enough.

I meant "write" access to change the file bypassing EWF. Sorry, it wasn't a clear in the statement I made.
Agree about the IOCTL codes. You're basically leaving the searching for the file (the hardest part) - getting a handle - for FS
driver, right?
Changing the bytes would be a couple of lines of code then.

> > Unfortunately, it is a hack in MS binaries and would not be legal for
> comersial distribution. But for sake of having technical
> > solution - that works just fine.
>
> Yup.

Have you tried the solution? I you haven't but would like, make sure you change second "wake" entry (from the beginingin of the
file).

> MBR is much easier to handle since it is very simple and before partition
> table it is only code that can be reallocated.

No doubt.


Slobodan Brcin (eMVP)

unread,
Apr 23, 2004, 3:47:12 PM4/23/04
to
Konstantin,

> Agree about the IOCTL codes. You're basically leaving the searching for
the file (the hardest part) - getting a handle - for FS
> driver, right?

Absolutely.

> Changing the bytes would be a couple of lines of code then.

Yup this was a very first thing I did, but since it only worked on files I
could get a handle on it was useless for this purpose.

> > > Unfortunately, it is a hack in MS binaries and would not be legal for
> > comersial distribution. But for sake of having technical
> > > solution - that works just fine.
> >
> > Yup.
>
> Have you tried the solution? I you haven't but would like, make sure you

change second "wake" entry (from the beginning of the
> file).

No need I have also made a MBR solution, but since I did this only to test
if it can be done I have no actual use for this at the moment.
Or we could have usage for this but only thing is that I would need to
rewrite my storage driver, and revisit all other drivers I made to integrate
support for this type of hibernation/resume scenario.

And this would require too much time that I don't have right now.

You must be aware that this solution is trivial to make (at lest for me),
but that second part that you have not considered yet is very hard to do.

As long as all your partitions are protected by RAM EWF only this will work
perfectly, but if you need to use some unprotected FS then before
hibernation you must unmout all open file systems.
Depending on usage scenario this can be impossible or would require huge
changes to applications you use on XPe. But is some cases it would be
trivial if all files from unprotected FS are closed. Then just before
hibernation you can use FSCTL_DISMOUNT_VOLUME on all open FS.


Best regards,
Slobodan


KM

unread,
Apr 23, 2004, 4:49:33 PM4/23/04
to
Slobodan,

> You must be aware that this solution is trivial to make (at lest for me),

However, changing the ntldr seems a bit easier for me. Just my 2 cents :-)

> but that second part that you have not considered yet is very hard to do.

I have because I had problems with NTFS unprotected volume after hibernation.

> As long as all your partitions are protected by RAM EWF only this will work
> perfectly, but if you need to use some unprotected FS then before
> hibernation you must unmout all open file systems.
> Depending on usage scenario this can be impossible or would require huge
> changes to applications you use on XPe. But is some cases it would be
> trivial if all files from unprotected FS are closed. Then just before
> hibernation you can use FSCTL_DISMOUNT_VOLUME on all open FS.

Yup.. this is still a problem within any approach we take (changes in MBR, or in ntldr).
What I don't understand is how the drives will be mounted back after resume? Automatically? Does the PnP manager do that?
If so, we could also "remove" unprotected disks (only for unprotected partition on a separate devices from protected ones) by
sending an appropriate IRP request (e.g., IRP_MN_REMOVE_DEVICE). Would that work?

Btw, there is more problems: if you happened to have system locked files (e.g. active paging file) on the volume - the system won't
allow you to dismount it.

Konstantin


Slobodan Brcin (eMVP)

unread,
Apr 23, 2004, 4:58:43 PM4/23/04
to
Konstantin,

> > As long as all your partitions are protected by RAM EWF only this will
work
> > perfectly, but if you need to use some unprotected FS then before
> > hibernation you must unmout all open file systems.
> > Depending on usage scenario this can be impossible or would require huge
> > changes to applications you use on XPe. But is some cases it would be
> > trivial if all files from unprotected FS are closed. Then just before
> > hibernation you can use FSCTL_DISMOUNT_VOLUME on all open FS.
>
> Yup.. this is still a problem within any approach we take (changes in MBR,
or in ntldr).
> What I don't understand is how the drives will be mounted back after
resume? Automatically? Does the PnP manager do that?

After you unlock the volume. And first time that any application try to
access it FS will load back I don't think that is has anything with PnP this
is FS driver related.

> If so, we could also "remove" unprotected disks (only for unprotected
partition on a separate devices from protected ones) by
> sending an appropriate IRP request (e.g., IRP_MN_REMOVE_DEVICE). Would
that work?

It is unacceptable slow to use PnP to rescan devices and bring them back,
but it would work.

> Btw, there is more problems: if you happened to have system locked files
(e.g. active paging file) on the volume - the system won't
> allow you to dismount it.

This is not a problem since you can't have paging file with this solution.
(If it is a problem then you can't use this solution).

Regards,
Slobodan


KM

unread,
Apr 23, 2004, 5:45:26 PM4/23/04
to
Slobodan,

> > > trivial if all files from unprotected FS are closed. Then just before
> > > hibernation you can use FSCTL_DISMOUNT_VOLUME on all open FS.
> >

> > What I don't understand is how the drives will be mounted back after resume? Automatically? Does the PnP manager do that?
>
> After you unlock the volume. And first time that any application try to
> access it FS will load back I don't think that is has anything with PnP this is FS driver related.

What I meant is that to use FSCTL_DISMOUNT_VOLUME you better lock the volume, right? Then who unlocks the volumes after resume?
Do I understand it right?
- to hibernate you use your own app (not system hibernate "button")
- the app first locks all unprotected volumes
- the app dismounts all the volumes
- you call to switch to S4 state (your app ramains running)
- you resume XPe
- the app (that is still running) unlocks the volumes
- first FS call to any of the unlocked volume will mount it back

> > If so, we could also "remove" unprotected disks (only for unprotected
> partition on a separate devices from protected ones) by
> > sending an appropriate IRP request (e.g., IRP_MN_REMOVE_DEVICE). Would that work?
>
> It is unacceptable slow to use PnP to rescan devices and bring them back, but it would work.

Hmm.. When I add a new partition to a disk in my system the same machanism seems to be involved. that does not seem to be very slow.

> > Btw, there is more problems: if you happened to have system locked files
> (e.g. active paging file) on the volume - the system won't allow you to dismount it.
>
> This is not a problem since you can't have paging file with this solution.
> (If it is a problem then you can't use this solution).

This is easy answer :-)
However, I do have a page file on an unprotected partition now. Don't know how it works with hibernation and my changes in ntldr but
I'll give it a try.
So far I haven't seen much problem with it but as we have already discussed the volume should be dismount before the hibernation.
Otherwise could be some problems with FS access to the volume data.
Anyway.. please disregard my comments on it now.

Konstantin


Slobodan Brcin (eMVP)

unread,
Apr 23, 2004, 6:09:03 PM4/23/04
to
Konstantin,

> What I meant is that to use FSCTL_DISMOUNT_VOLUME you better lock the
volume, right? Then who unlocks the volumes after resume?
> Do I understand it right?
> - to hibernate you use your own app (not system hibernate "button")
> - the app first locks all unprotected volumes
> - the app dismounts all the volumes
> - you call to switch to S4 state (your app ramains running)
> - you resume XPe

<----------------------------------------- At this point I change wake to
hibr


> - the app (that is still running) unlocks the volumes
> - first FS call to any of the unlocked volume will mount it back

That's it. You have mentioned all required steps and how they will work.

> > > If so, we could also "remove" unprotected disks (only for unprotected
> > partition on a separate devices from protected ones) by
> > > sending an appropriate IRP request (e.g., IRP_MN_REMOVE_DEVICE). Would
that work?
> >
> > It is unacceptable slow to use PnP to rescan devices and bring them
back, but it would work.
>
> Hmm.. When I add a new partition to a disk in my system the same machanism
seems to be involved. that does not seem to be very slow.

Don't know about that. But in this case i think that OS will open all new
file systems found on that parititons and that can take some time.

> > > Btw, there is more problems: if you happened to have system locked
files
> > (e.g. active paging file) on the volume - the system won't allow you to
dismount it.
> >
> > This is not a problem since you can't have paging file with this
solution.
> > (If it is a problem then you can't use this solution).
>
> This is easy answer :-)
> However, I do have a page file on an unprotected partition now. Don't know
how it works with hibernation and my changes in ntldr but
> I'll give it a try.
> So far I haven't seen much problem with it but as we have already
discussed the volume should be dismount before the hibernation.

Consider that you have 256 MB of RAM and 2 GB of pagefile.

You hibernate for the first time. Physical memory goes to hiber file and
page file remain unchanged. Right?
You resume for the first time hibef file populate ram and with page file
data it will work. Right.
You work and pagefile get changed.

You reboot and resume for second time. Hiber file goes to ram unchanged and
page file is not the pagefile we used in initial hibernation, so virtual
memory data is corrupted and system may/will crash.

Slobodan

KM

unread,
Apr 24, 2004, 5:07:16 AM4/24/04
to
> That's it. You have mentioned all required steps and how they will work.

Yup, my test app that does all this works just fine on the target.

> > > > If so, we could also "remove" unprotected disks (only for unprotected
> > > partition on a separate devices from protected ones) by
> > > > sending an appropriate IRP request (e.g., IRP_MN_REMOVE_DEVICE). Would that work?
> > >
> > > It is unacceptable slow to use PnP to rescan devices and bring them
> back, but it would work.
> >
> > Hmm.. When I add a new partition to a disk in my system the same machanism
> seems to be involved. that does not seem to be very slow.
>
> Don't know about that. But in this case i think that OS will open all new
> file systems found on that parititons and that can take some time.

It always depends on target hardware perfomance but I still think it is not dramatically slow. Just good to test.
I'll post the results later here if it will be interesting.

> You work and pagefile get changed.

> ...

Yes, I got that and absolutely agree. The pagefile would be useful only if you hibernate machine each time which is not about this
thread.
Thanks a lot, Slobodan. I now got much more clear picture and pretty stable solution.

Konstantin


Slobodan Brcin (eMVP)

unread,
Apr 24, 2004, 6:14:43 AM4/24/04
to
Konstantin,

> > That's it. You have mentioned all required steps and how they will work.
> Yup, my test app that does all this works just fine on the target.

I made a confirmation statement not a question, although now when I read my
sentence I have no idea if it sounded like one.

Maybe I should put exclamation mark?

Regards,
Slobodan


KM

unread,
Apr 24, 2004, 3:51:52 PM4/24/04
to
Slobodan,

No need for the exclamation mark :-)
That was probably my too short sentence. I was trying to say that I got the app that implements all that.

Thanks again for the help!
Konstantin

Leonid

unread,
Apr 25, 2004, 5:36:02 PM4/25/04
to
"Slobodan Brcin \(eMVP\)" <sbr...@ptt.yu> wrote in message news:<uCk9jILK...@TK2MSFTNGP10.phx.gbl>...
> Slobodan and Konstantin
It is really interesting that thread I started on 12/30/2003 "Subject:
Win Xp Embedded hibernation"
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=6b4e508c.0312300325.1cfc9d26%40posting.google.com&rnum=5&prev=/groups%3Fq%3Dauthor:leonid.olshansky%2540med.ge.com%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D6b4e508c.0312300325.1cfc9d26%2540posting.google.com%26rnum%3D5
has continuation now. The main goal (for me) is: how to use hiber file
as gold image in case EWF is enabled? It's very important for my
project to perform immediate shutting down (of course with dismounting
the rest of unprotected partitions) and always wake up to factory
state. I'm seriously trying to learn your discussions and I think you
are closely to final stage.
If I understood correctly there are several ways of realization. I
would like to ask you, Slobodan and you, Konstantin to summarize all
you wrote above. I would also ask you to confirm the statements below:
- To avoid ntldr message on wake up need to find workaround to
overwrite 4 bytes in binary hiber file. (What should I write here and
how to access this hiber file for editing and in what point of time?).
- It's possible to prevent ntldr to write any data to disk. In this
case there is no matter what FS to be used. (What kind of data ntldr
writes on disk and How to prevent this?)
- It's possible to copy MBR to next 512k and put the custom MBR that
only simulates the write operation. Then change WAKE to HIBR. (What
are WAKE code and HIBR code?)
- With BIOS source code it's possible to leave out write support
functions from BIOS. (Do you mean to prevent all write attempts via
int 13? Doe's BIOS know something about power state?)
- Something else that I forgot???

Thanks
\Leonid

Slobodan Brcin (eMVP)

unread,
Apr 25, 2004, 6:14:37 PM4/25/04
to
Hello Leonid,

Thanks for providing the link on this subject, I just read it (Although I
could not remember that I had any previous conversation on this topic it is
documented on google :-) )
In that post my assumption was wrong since I never used hibernation with XPe
before that. I actually thought that ntldr will somehow make FS integrity
check between FS stored on disk and pieces of FS stored in hibernation file.

> has continuation now. The main goal (for me) is: how to use hiber file
> as gold image in case EWF is enabled? It's very important for my
> project to perform immediate shutting down (of course with dismounting
> the rest of unprotected partitions) and always wake up to factory
> state. I'm seriously trying to learn your discussions and I think you
> are closely to final stage.

I believe that both Konstanin and I have competed all stages required for
final product.
You will probably have to reread this whole thread from beginning to catch
up with us. Also there is an attachment somewhere in this thread from me
that you can use for testing.

> If I understood correctly there are several ways of realization. I
> would like to ask you, Slobodan and you, Konstantin to summarize all
> you wrote above. I would also ask you to confirm the statements below:
> - To avoid ntldr message on wake up need to find workaround to
> overwrite 4 bytes in binary hiber file. (What should I write here and
> how to access this hiber file for editing and in what point of time?).

We mention this 4 bytes just for a sake of argument.
You should prevent ntldr from changing them in the first place.

> - It's possible to prevent ntldr to write any data to disk. In this
> case there is no matter what FS to be used. (What kind of data ntldr
> writes on disk and How to prevent this?)

ntldr will change first 4 bytes in hiberfil.sys from HIBR to WAKE before it
gives control to ntoskrnl.

You can use something from bellow:
1. Use hack to ntldr that Konstantin described,
2. Remove int 13 disk write support from BIOS.
3. Create int 13 write filter program and place it in MBR.

> - It's possible to copy MBR to next 512k and put the custom MBR that
> only simulates the write operation. Then change WAKE to HIBR. (What
> are WAKE code and HIBR code?)

4 Byte flag on the beginning of hibrfil.sys that tell antler what to do with
hibernation file.

HIBR - If found ntldr will resume XPe from hibrfil.sys.
WAKE - If found will ask user what to do. (Resume or boot normally)
Something else - Not valid hibernation file.

> - With BIOS source code it's possible to leave out write support
> functions from BIOS. (Do you mean to prevent all write attempts via
> int 13?

Yes. Since XPe will use drivers not BIOS to write data to disk.

(Doe's BIOS know something about power state?)
This is not relevant for this solution. If you are referring to Konstantin
mention it in this thread it was a wrong assumption based on some other
problem he had.

> - Something else that I forgot???

Read few more times this thread.
Use my app for testing or make some solution based on this tread.
Ask if you have troubles on the way.

Happy hunting,
Slobodan


KM

unread,
Apr 26, 2004, 12:58:34 AM4/26/04
to
Just a couple of adds to Slobodan's reply:

Leonid, your questions (statements) showed that you have already read the thread and understood pretty much everything about our
solutions (mine is basically is a repeat of Slobodan's + a hack in ntldr). There may be some other routes to accomplish what you
need to that we have not checked yet. Although, our apps work and this is a good indication :-)

> You can use something from bellow:
> 1. Use hack to ntldr that Konstantin described,
> 2. Remove int 13 disk write support from BIOS.

Keep in mind that under Windows the int13/write access will not be available either. Although it may not be important as Windows has
it own disk access implementation (SCSI drivers), there might be some custom (3rd party) drivers/apps that use INT 13 calls
(especially if they switch to real mode). Slobodan may correct me if I am wrong here.

> 3. Create int 13 write filter program and place it in MBR.

I haven't done that myself (Slobodan did). But I believe the asm code that replaces default BIOS interrupt vector for INT 13 (AH =
03). Most likely, just changing an entry in interrupt vector table (in real mode always at address 00000h). It should be similar to
DOS INT 21h, 25h function implementation (you can explore/copy the function code).

> > - It's possible to copy MBR to next 512k and put the custom MBR that
> > only simulates the write operation. Then change WAKE to HIBR. (What are WAKE code and HIBR code?)
>
> 4 Byte flag on the beginning of hibrfil.sys that tell antler what to do with hibernation file.

Get offline access to your target boot partition and explore the hiberfil.sys. You'll see the flag values.

> > - With BIOS source code it's possible to leave out write support
> > functions from BIOS. (Do you mean to prevent all write attempts via int 13?
>
> Yes. Since XPe will use drivers not BIOS to write data to disk.
>
> (Doe's BIOS know something about power state?)
> This is not relevant for this solution. If you are referring to Konstantin
> mention it in this thread it was a wrong assumption based on some other problem he had.

My guess is still that some BIOS implementations may "know" the state. I couldn't find anything about that in APM specifications but
who knows.
My current experiments on my laptop show that if I hibernate the machine it is always resumes on "Power On" regardless of the BIOS
boot options (if I have bootable CD in place, e.g.). I can't get to NT loader menu on "Power On" after I hibernate my XP Pro OS
(this is not just XPe problem). The POST, however, is always there.
Anyway.. this is only my laptop problem. You will unlikely hit that on your target.

Konstantin


KM

unread,
Apr 26, 2004, 2:20:31 AM4/26/04
to
Hi Slobodan,

I'd appreciate if you could answer one my question.

I was wondering when you stop all INT 13h write calls (new MBR) do you filter out only AH=03h function? I don't know what ntldr uses
(I don't think the ntldr uses 0Bh, though). However, in LBA mode I think the ntldr gets to switch to extended write (43h), does it?
Then, do you filter this out too?
In your tests, your system disk is less or more than 8G?

Thank you,
Konstantin

Slobodan Brcin (eMVP)

unread,
Apr 26, 2004, 6:43:22 AM4/26/04
to
Hi Konstantin,

Basically code is simple.
1. It reallocate itself.
2. It hook at vector 13h
3. If ah=03h or ah=43 it returns true, if not it passes the call to BIOS.
4. it load real MBR and resume boot.

Only problem with all this why it won't work on other devices is because I
have searched for empty space of memory that my XPe does not use. Like I
said it was not meant to be used by anyone expect me for testing purposes
only so I forged it to work, nothing more.

My HDD is 120 GB.

> Keep in mind that under Windows the int13/write access will not be
available either. Although it may not be important as Windows has
> it own disk access implementation (SCSI drivers), there might be some
custom (3rd party) drivers/apps that use INT 13 calls
> (especially if they switch to real mode). Slobodan may correct me if I am
wrong here.

I would like to see that driver. I mean I would like to know how to use int
13 calls from my driver. Few months ago I asked the same question in kernel
NG but answer was that it was not possible as I know it was not. Or better
to say it is possible, guy was enthusiast and he said:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=uEU8LXa6DHA
.1968%40TK2MSFTNGP11.phx.gbl

Regards,
Slobodan


"KM" <kons...@nospam.yahoo.com> wrote in message

news:e#2MUa1KE...@TK2MSFTNGP10.phx.gbl...

Leonid

unread,
Apr 26, 2004, 7:19:47 AM4/26/04
to
"Slobodan Brcin \(eMVP\)" <sbr...@ptt.yu> wrote in message news:<uQuetnAK...@TK2MSFTNGP11.phx.gbl>...
Hi, Slobodan and Konstantin
Thank you for clarification

Slobodan wrote:
In attachment you will find doc and application without the sources (I
&#1064; > > > rarely give them away).
I hope that this is last working version. Also do not use it in multi
boot
> > > > scenario machines.
> > > >
> > > > I made this application for Brad so he can test his image.
&#1064; > > > > This is not a full featured product and have many
limitations
But I failed to find an attachment in this thread. Please, send me the
link or send directly to my e-mail (zip files are blocked by our
firewall, so rename it to .zzz)
To Konstantin:
1. About the difference between your laptop and desktop
a. I think you have exactly the situation Slobodan mentioned above:
int13 write is disabled in your BIOS by default or it was not
implemented at all)
b. Is it possible to ask your real e-mail (not faked)? If Yes, please
forward it to my e-mail.
2. To Slobodan and Konstantin:
a. Using EWF enabled and Hibernation together (without hacking) causes
to loose all EWF protection features. For example:
i. Efw and Hibernation are enabled
ii. Delete any shortcut from desktop
iii. Hibernate
iv. Wake up
v. The computer will wake up with deleted shortcut – no protection.

b. To use EWF+Hibernation + Protection we need :
i. to hack hiberfile (ntldr)
ii. Delete any shortcut from desktop
iii. Dismount the rest of unprotected partitions
iv. Perform immediate shut down (power cut)
v. Wake up from hacked hiberfile as from gold image. I suppose that
Shortcut will be on its place.

c. Is there something wrong in my statements?
d. Is there EWF (RAM) command to undo (return deleted shortcut to its
location) without reboot?
Regards
\Leonid

Slobodan Brcin (eMVP)

unread,
Apr 26, 2004, 8:19:06 AM4/26/04
to
Hi Leonid,

You can access attachment from outlook express if you use it for reading NG.
It was included in my first answer to your old request.

> 1. About the difference between your laptop and desktop
> a. I think you have exactly the situation Slobodan mentioned above:
> int13 write is disabled in your BIOS by default or it was not
> implemented at all)

I don't think that you will find any computer on the market with int 13
write disabled or unsupported.

> 2. To Slobodan and Konstantin:
> a. Using EWF enabled and Hibernation together (without hacking) causes
> to loose all EWF protection features. For example:
> i. Efw and Hibernation are enabled
> ii. Delete any shortcut from desktop
> iii. Hibernate
> iv. Wake up

> v. The computer will wake up with deleted shortcut - no protection.

With hacking it would be the same behavior as you described it. I fail to
see what is not obvious in your question.

Reread what you have said.
First you delete shortcut then you hibernate then you resume and you ask why
you have lost shortcut.


Test should look like.
1. EWF and hibernation enabled.
2. hibernate.
3. resume.
4. delete shortcut.
5. reset device.
6. resume.

Shortcut is still at the desktop.

b. You don't need to hack hiberfil.sys. You should hack ntldr. or BIOS. For
rest look at my previous answer.

c. Yes there is.

d. No there is not. But it is not required if you follow above instructions.
Also you will need to reread this thread few more times, also read how EWF
works few more times.

Regards,
Slobodan

> v. The computer will wake up with deleted shortcut - no protection.

Kesavan

unread,
Apr 26, 2004, 8:39:02 AM4/26/04
to
KM/Slobodan .. Hehe,I hope you aren't checking the efficiency of
google pages or heading for a half century (no of postings) :)

"Slobodan Brcin \(eMVP\)" <sbr...@ptt.yu> wrote in message news:<uQuetnAK...@TK2MSFTNGP11.phx.gbl>...

Slobodan Brcin (eMVP)

unread,
Apr 26, 2004, 9:12:00 AM4/26/04
to
Google beware :-)

"Kesavan" <kesava...@hotmail.com> wrote in message
news:340a938c.04042...@posting.google.com...

KM

unread,
Apr 26, 2004, 12:41:00 PM4/26/04
to
It is getting hard to read new posts in this thread even using OE :-)

KM

unread,
Apr 26, 2004, 1:03:56 PM4/26/04
to
Slobodan,

> Basically code is simple.
> 1. It reallocate itself.
> 2. It hook at vector 13h
> 3. If ah=03h or ah=43 it returns true, if not it passes the call to BIOS.
> 4. it load real MBR and resume boot.

This scenerio is very clear to me.

> Only problem with all this why it won't work on other devices is because I
> have searched for empty space of memory that my XPe does not use. Like I
> said it was not meant to be used by anyone expect me for testing purposes
> only so I forged it to work, nothing more.

I don't understand why your code searches for empty space of memory. But you had probably your own testing reasons.

> My HDD is 120 GB.

So, LBA is on. Then I don't get it. Even NTFS boot sector code switches to AH=42h to read sectors of ntldr.
I supposed that ntldr has to switch to 43h in order to support LBA mode to update the hiberfil.sys.
Since you filter the 03h function and don't filter the 43h function but it still works, only explanation I see is that 43h uses 03h
internally using the interput verctor set procedure (your funciton, basically) either directly getting the pointer or calling to INT
13h again.

> > Keep in mind that under Windows the int13/write access will not be
> available either. Although it may not be important as Windows has
> > it own disk access implementation (SCSI drivers), there might be some
> custom (3rd party) drivers/apps that use INT 13 calls
> > (especially if they switch to real mode). Slobodan may correct me if I am wrong here.
>
> I would like to see that driver. I mean I would like to know how to use int
> 13 calls from my driver. Few months ago I asked the same question in kernel
> NG but answer was that it was not possible as I know it was not. Or better
> to say it is possible, guy was enthusiast and he said:
>
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=uEU8LXa6DHA
> .1968%40TK2MSFTNGP11.phx.gbl

I've seen some code in Internet that does that (switches between real/protected modes back and forth and having access to various
INTs (13h)). Although that was not a driver code, I assumed there may be possible some "hacks" in drivers (who knows what x86 3rd
party driver can do!).

Thanks!
Konstantin


Slobodan Brcin (eMVP)

unread,
Apr 26, 2004, 1:15:32 PM4/26/04
to
Konstantin,

> > Only problem with all this why it won't work on other devices is because
I
> > have searched for empty space of memory that my XPe does not use. Like I
> > said it was not meant to be used by anyone expect me for testing
purposes
> > only so I forged it to work, nothing more.
>
> I don't understand why your code searches for empty space of memory. But
you had probably your own testing reasons.

Actually I hardoded memory area not used by ntldr ntdetect, and other files
loaded by int 13. If any of drivers loaded over my 512 bytes of code then
int 13 resident filter code would be damaged and int 13 call would become
corrupted also.

> > My HDD is 120 GB.
>
> So, LBA is on. Then I don't get it. Even NTFS boot sector code switches to
AH=42h to read sectors of ntldr.
> I supposed that ntldr has to switch to 43h in order to support LBA mode to
update the hiberfil.sys.
> Since you filter the 03h function and don't filter the 43h function but it
still works, only explanation I see is that 43h uses 03h
> internally using the interput verctor set procedure (your funciton,
basically) either directly getting the pointer or calling to INT
> 13h again.

Let me state it more clearly: I'm filtering both 03h and 43h functions.

> > > Keep in mind that under Windows the int13/write access will not be
> > available either. Although it may not be important as Windows has
> > > it own disk access implementation (SCSI drivers), there might be some
> > custom (3rd party) drivers/apps that use INT 13 calls
> > > (especially if they switch to real mode). Slobodan may correct me if I
am wrong here.
> >
> > I would like to see that driver. I mean I would like to know how to use
int
> > 13 calls from my driver. Few months ago I asked the same question in
kernel
> > NG but answer was that it was not possible as I know it was not. Or
better
> > to say it is possible, guy was enthusiast and he said:
> >
> >
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=uEU8LXa6DHA
> > .1968%40TK2MSFTNGP11.phx.gbl
>
> I've seen some code in Internet that does that (switches between
real/protected modes back and forth and having access to various
> INTs (13h)). Although that was not a driver code, I assumed there may be
possible some "hacks" in drivers (who knows what x86 3rd
> party driver can do!).

I can switch also between protected and real mode and back. But all BIOS
related stuff are just not available or usable.

Regards,
Slobodan


KM

unread,
Apr 26, 2004, 1:21:50 PM4/26/04
to
Leonid,

You don't seem to use OE, do you? I'd suggest you to use it (most likely it is already installed on your computer). It will save you
much time dealing with NG posting.

--
KM,
BSquare Corporation

> To Konstantin:
> 1. About the difference between your laptop and desktop
> a. I think you have exactly the situation Slobodan mentioned above:
> int13 write is disabled in your BIOS by default or it was not implemented at all)

I don't think it is the case here. Otherwise ntldr would be able to work properly to write in hiberfil.sys and to read the file and
boot drivers on my laptop.
My laptop case simply shows that the laptop BIOS somehow knows about three things - ntldr/boot.ini/hiberfil.sys. I don't understand
such "highly XP integration" with the BIOS (or vise verse) but I failed to explain my test results any other way.
APM 1.2 specification (comparaed to 1.0/1.1 versions) does use hibrnation as a term (meaning it support hibernation more closely).
But it does not say anything about hiberfil.sys and etc. I am still confused about it. Since it is a minor problem now (my laptop
only), I'll investigate it in backgroud to my major tasks.

> b. Is it possible to ask your real e-mail (not faked)? If Yes, please forward it to my e-mail.

I've mentioned my "real" email in this NG. It is konstmor At no_spam_hotmail.com. Use it if you need it (btw, why do you need it?).

> 2. To Slobodan and Konstantin:
> a. Using EWF enabled and Hibernation together (without hacking) causes
> to loose all EWF protection features. For example:
> i. Efw and Hibernation are enabled
> ii. Delete any shortcut from desktop
> iii. Hibernate
> iv. Wake up

> v. The computer will wake up with deleted shortcut - no protection.


>
> b. To use EWF+Hibernation + Protection we need :
> i. to hack hiberfile (ntldr)
> ii. Delete any shortcut from desktop
> iii. Dismount the rest of unprotected partitions
> iv. Perform immediate shut down (power cut)
> v. Wake up from hacked hiberfile as from gold image. I suppose that
> Shortcut will be on its place.
>
> c. Is there something wrong in my statements?
> d. Is there EWF (RAM) command to undo (return deleted shortcut to its location) without reboot?

Agree with Slobodan's reply on this sections. You should play with EWF for a day or so. You'll get familiar with what it can do and
what it can not.
Another thing to always keep in mind that hibernation happens bypassing EWF protection. Unless you mistakenly do what I did -
modifying file systems while the XPe image is hibernated.

Konstantin


KM

unread,
Apr 26, 2004, 1:28:10 PM4/26/04
to
Slobodan,

Sorry, seems like something happened to my eyes and I completely missed the 43h in your previous post :-)
I see it now. Please disregard the 43h questions from me.

--
KM,
BSquare Corporation

Leonid

unread,
Apr 26, 2004, 4:06:16 PM4/26/04
to
"Slobodan Brcin \(eMVP\)" <sbr...@ptt.yu> wrote in message news:<#0SWUj4K...@TK2MSFTNGP09.phx.gbl>...


Slobodan
1.You are right. Possible my first example was not so good.
I only tried to explain that usage of hiber file as gold image is
possible, but in case of reset (power off) and not with usual
hibernation (change power state to S4)
2. Trust me that I learned how EWF must work, possible not so good as
you know.
3. I'm not using OE6 as newsgroup reader. I can't receive attachments
due to new policy restriction. Would you like to resend an attachment
to my private address el...@mail.ru. Sorry for problems.
Regards
\Leonid

Leonid

unread,
Apr 26, 2004, 6:48:38 PM4/26/04
to
"KM" <kons...@nospam.yahoo.com> wrote in message news:<#nw0D16K...@tk2msftngp13.phx.gbl>...

Konstantin
Thaks for your reply
- Would you like to explain how to configure OE6 for NG access.
- Some weeks ago I tried to send you e-mail, but it was rejected by
e--mail delivering system as not accessible. Sometimes (not often) I
have specific questions, that may be not so interesting for NG
publication.
\Leonid

KM

unread,
Apr 26, 2004, 7:07:25 PM4/26/04
to
Leonid,

> Thaks for your reply
> - Would you like to explain how to configure OE6 for NG access.

Open OE6 and set up a new News account (Tools-->Accounts...-->Add News). You may need to use "msnews.microsoft.com" as the server
name.

> - Some weeks ago I tried to send you e-mail, but it was rejected by
> e--mail delivering system as not accessible. Sometimes (not often) I
> have specific questions, that may be not so interesting for NG publication.

Hope that you have removed "no_spam" words from the email address you used.

> \Leonid

Konstantin


0 new messages