Hi all,
is the win 7 (sp1) s4 RESUME process is done with disk.sys? is there a
different ATA stack for that particular process? maybe the crashdump READ
method been used here?
thansk!
During resume, the hiberfile is read by INT13 means (or UEFI). disk.sys is NOT in the game at that time. The drivers can only get back to work after the whole hiberfile is brought back to memory.
Crashdump driver is invoked by HAL to write hyberfil to boot block device
which could be a local disk, or a LUN back by SAN.
Let’s forget about efi for now… In bad old BIOS mode, a resume is much
like a bootstrap.
- BIOS finished POST, reads 512B MBR to 00:7c00, some BIOS may load it to
7c0:0. To unifiy the behavior, the first instruction the MBR would do is
“jmp 7c0:real_start”. - The MBR code loads bootmgr. bootmgr’s real mode code switches the CPU to
native protected mode and prepares for next boot stage. - Bootmgr detects if this is a resume or fresh boot. It will load
winresume if it’s a resume and winload if a normal boot. or other bootapp
i.e. memory tester etc. - Winresume reads hyberfil through platform firmware, validates its
integrity. If something is wrong (but not very wrong), it may popup a menu
to ask user to delete the hiberfile and start a normal boot(which will
invoke winload). Continue to step 5) if all is well. - Winresume invokes HAL to starts from what was left over at the last
hibernate. - System power state transitioning occurs (Pop/Po code to switch from
S4->S0). Your driver gets D0 IRP.
The actual boot/resume is much more complex than mentioned above. It’s
reasonable to assume there must be a small group of very bright
developers at MSFT owning this part of magic in Windows which is completely
different from other kernel mode components in principle. It’s an os of its
own.
Calvin
On Sat, Nov 5, 2011 at 12:47 PM, jonatan perry wrote:
> Hi all,
> is the win 7 (sp1) s4 RESUME process is done with disk.sys? is there a
> different ATA stack for that particular process? maybe the crashdump READ
> method been used here?
>
> thansk!
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
so you claim that the hole resuming process handled by int13. AFAIK BIOS
interrupts are disabled after jumping into protected mode(*) as they been
rewritten by the exception mechanism.
and definitely the resuming cannot be done in real mode since 32bit
addressing is required.
are you sure the disk.sys is not responsible for the resuming process as
well?
also - for what the READ method is used in crashdump drivers (or it is not
been used in WIN7/SP1 at all?)
thanks!
*
http://stackoverflow.com/questions/2123639/int-13h-in-windows-protected-mode
On Sun, Nov 6, 2011 at 9:01 AM, Calvin Guan (news) > wrote:
> Crashdump driver is invoked by HAL to write hyberfil to boot block device
> which could be a local disk, or a LUN back by SAN.
>
> Let’s forget about efi for now… In bad old BIOS mode, a resume is much
> like a bootstrap.
>
> 1) BIOS finished POST, reads 512B MBR to 00:7c00, some BIOS may load it to
> 7c0:0. To unifiy the behavior, the first instruction the MBR would do is
> “jmp 7c0:real_start”.
> 2) The MBR code loads bootmgr. bootmgr’s real mode code switches the CPU
> to native protected mode and prepares for next boot stage.
> 3) Bootmgr detects if this is a resume or fresh boot. It will load
> winresume if it’s a resume and winload if a normal boot. or other bootapp
> i.e. memory tester etc.
> 4) Winresume reads hyberfil through platform firmware, validates its
> integrity. If something is wrong (but not very wrong), it may popup a menu
> to ask user to delete the hiberfile and start a normal boot(which will
> invoke winload). Continue to step 5) if all is well.
> 5) Winresume invokes HAL to starts from what was left over at the last
> hibernate.
> 6) System power state transitioning occurs (Pop/Po code to switch from
> S4->S0). Your driver gets D0 IRP.
>
> The actual boot/resume is much more complex than mentioned above. It’s
> reasonable to assume there must be a small group of very bright
> developers at MSFT owning this part of magic in Windows which is completely
> different from other kernel mode components in principle. It’s an os of its
> own.
>
>
> Calvin
>
>
> On Sat, Nov 5, 2011 at 12:47 PM, jonatan perry wrote:
>
>> Hi all,
>> is the win 7 (sp1) s4 RESUME process is done with disk.sys? is there a
>> different ATA stack for that particular process? maybe the crashdump READ
>> method been used here?
>>
>> thansk!
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Since the past few months, I made a living of debugging the interactions
between Winload/winresume and MY INT13 handler IN MY BOOTROM. I think I
know what I’m talking about:)
On Sun, Nov 6, 2011 at 10:01 AM, jonatan perry wrote:
> so you claim that the hole resuming process handled by int13. AFAIK BIOS
> interrupts are disabled after jumping into protected mode(*) as they been
> rewritten by the exception mechanism.
> and definitely the resuming cannot be done in real mode since 32bit
> addressing is required.
>
> are you sure the disk.sys is not responsible for the resuming process as
> well?
> also - for what the READ method is used in crashdump drivers (or it is not
> been used in WIN7/SP1 at all?)
>
> thanks!
>
> *
> http://stackoverflow.com/questions/2123639/int-13h-in-windows-protected-mode
>
>
> On Sun, Nov 6, 2011 at 9:01 AM, Calvin Guan (news) <
> xxxxx@gradovec.com> wrote:
>
>> Crashdump driver is invoked by HAL to write hyberfil to boot block device
>> which could be a local disk, or a LUN back by SAN.
>>
>> Let’s forget about efi for now… In bad old BIOS mode, a resume is much
>> like a bootstrap.
>>
>> 1) BIOS finished POST, reads 512B MBR to 00:7c00, some BIOS may load it
>> to 7c0:0. To unifiy the behavior, the first instruction the MBR would do is
>> “jmp 7c0:real_start”.
>> 2) The MBR code loads bootmgr. bootmgr’s real mode code switches the CPU
>> to native protected mode and prepares for next boot stage.
>> 3) Bootmgr detects if this is a resume or fresh boot. It will load
>> winresume if it’s a resume and winload if a normal boot. or other bootapp
>> i.e. memory tester etc.
>> 4) Winresume reads hyberfil through platform firmware, validates its
>> integrity. If something is wrong (but not very wrong), it may popup a menu
>> to ask user to delete the hiberfile and start a normal boot(which will
>> invoke winload). Continue to step 5) if all is well.
>> 5) Winresume invokes HAL to starts from what was left over at the last
>> hibernate.
>> 6) System power state transitioning occurs (Pop/Po code to switch from
>> S4->S0). Your driver gets D0 IRP.
>>
>> The actual boot/resume is much more complex than mentioned above. It’s
>> reasonable to assume there must be a small group of very bright
>> developers at MSFT owning this part of magic in Windows which is completely
>> different from other kernel mode components in principle. It’s an os of its
>> own.
>>
>>
>> Calvin
>>
>>
>> On Sat, Nov 5, 2011 at 12:47 PM, jonatan perry wrote:
>>
>>> Hi all,
>>> is the win 7 (sp1) s4 RESUME process is done with disk.sys? is there a
>>> different ATA stack for that particular process? maybe the crashdump READ
>>> method been used here?
>>>
>>> thansk!
>>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>>> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
>>> visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
I listed 6 major steps taking place in the resume process. It involves
multiple agents. I was wondering how it was derived that I claimed the
“hole” resume process is handled by int13?? what is the “hole” resume
process in your mind?
Calvin
On Sun, Nov 6, 2011 at 11:04 AM, Calvin Guan (news) <
xxxxx@gradovec.com> wrote:
Since the past few months, I made a living of debugging the interactions
between Winload/winresume and MY INT13 handler IN MY BOOTROM. I think I
know what I’m talking about:)On Sun, Nov 6, 2011 at 10:01 AM, jonatan perry wrote:
>
>> so you claim that the hole resuming process handled by int13. AFAIK BIOS
>> interrupts are disabled after jumping into protected mode(*) as they been
>> rewritten by the exception mechanism.
>> and definitely the resuming cannot be done in real mode since 32bit
>> addressing is required.
>>
>> are you sure the disk.sys is not responsible for the resuming process as
>> well?
>> also - for what the READ method is used in crashdump drivers (or it is
>> not been used in WIN7/SP1 at all?)
>>
>> thanks!
>>
>> *
>> http://stackoverflow.com/questions/2123639/int-13h-in-windows-protected-mode
>>
>>
>> On Sun, Nov 6, 2011 at 9:01 AM, Calvin Guan (news) <
>> xxxxx@gradovec.com> wrote:
>>
>>> Crashdump driver is invoked by HAL to write hyberfil to boot block
>>> device which could be a local disk, or a LUN back by SAN.
>>>
>>> Let’s forget about efi for now… In bad old BIOS mode, a resume is much
>>> like a bootstrap.
>>>
>>> 1) BIOS finished POST, reads 512B MBR to 00:7c00, some BIOS may load it
>>> to 7c0:0. To unifiy the behavior, the first instruction the MBR would do is
>>> “jmp 7c0:real_start”.
>>> 2) The MBR code loads bootmgr. bootmgr’s real mode code switches the CPU
>>> to native protected mode and prepares for next boot stage.
>>> 3) Bootmgr detects if this is a resume or fresh boot. It will load
>>> winresume if it’s a resume and winload if a normal boot. or other bootapp
>>> i.e. memory tester etc.
>>> 4) Winresume reads hyberfil through platform firmware, validates its
>>> integrity. If something is wrong (but not very wrong), it may popup a menu
>>> to ask user to delete the hiberfile and start a normal boot(which will
>>> invoke winload). Continue to step 5) if all is well.
>>> 5) Winresume invokes HAL to starts from what was left over at the last
>>> hibernate.
>>> 6) System power state transitioning occurs (Pop/Po code to switch from
>>> S4->S0). Your driver gets D0 IRP.
>>>
>>> The actual boot/resume is much more complex than mentioned above. It’s
>>> reasonable to assume there must be a small group of very bright
>>> developers at MSFT owning this part of magic in Windows which is completely
>>> different from other kernel mode components in principle. It’s an os of its
>>> own.
>>>
>>>
>>> Calvin
>>>
>>>
>>> On Sat, Nov 5, 2011 at 12:47 PM, jonatan perry wrote:
>>>
>>>> Hi all,
>>>> is the win 7 (sp1) s4 RESUME process is done with disk.sys? is there a
>>>> different ATA stack for that particular process? maybe the crashdump READ
>>>> method been used here?
>>>>
>>>> thansk!
>>>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>>>> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
>>>> visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>>
>>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>>> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
>>> visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
You need to define the boundary of “resuming process” more rigorously
before further discussion. What I can tell you fer sure is that DISK.sys
has nothing to do with fetching hyberfil. I’m as sure as my name is Calvin,
period.
Hi Calvin,
first of - thank you for your help.
second - by “resuming process” I meant the part were windows fetch the
memory pages that stored in the hiberfil and write them into memory, is
that particular part done only by using INT 13? is there a different disk
drivers stack for that purpose? is that part changed from windows xp (same
hiberfil access method)?
thanks.
On Sun, Nov 6, 2011 at 9:20 PM, Calvin Guan (news) > wrote:
>
>
>
> You need to define the boundary of “resuming process” more rigorously
> before further discussion. What I can tell you fer sure is that DISK.sys
> has nothing to do with fetching hyberfil. I’m as sure as my name is Calvin,
> period.
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
No, resume is done using BIOS and BIOS phase of boot.
There is no disk.sys during resume.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“jonatan perry” wrote in message news:xxxxx@ntdev…
Hi all,
is the win 7 (sp1) s4 RESUME process is done with disk.sys? is there a different ATA stack for that particular process? maybe the crashdump READ method been used here?
thansk!
>AFAIK BIOS interrupts are disabled after jumping into protected mode(*) as they been rewritten by
the exception mechanism.
Any DOS extender of early 1990ies could solve this issue, and NT boot loader uses the same techniques to solve it.
Also - are you sure resume data load phase runs in protected mode? 
and definitely the resuming cannot be done in real mode since 32bit addressing is required.
There are such things as int 15h and unreal mode
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>the hiberfil and write them into memory, is that particular part done only by using INT 13?
Pre-Vista, you could have multi() and scsi() devices in BOOT.INI.
For multi(), int 13h was used.
For scsi(), \ntbootdd.sys (a copy of the main controllers’ miniport driver from system32\drivers) was loaded (NTLDR emulated SCSIPORT so that the ScsiPortXxx imports from the miniport worked), and all disk IO was done using it.
I don’t know whether scsi() is supported in Vista+, probably it was dropped.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Max,
I don’t know much about Windows XP nor w2k3.
For nt6.0+, Bootmgr switches to protected mode very early. Bootmgr is
mainly a PE image with a small 16 realmode stub to get the CPU ready to
execute the PE portion which required flat ds,ss,cs,es in protected mode.
winresume is purely a PE exeuted at pmode with paging off. it usually
starts at 0x400000 in my observable configurations. When Winresume runs,
it’s the one and only one module in the entire execution environment. OP,
so there is no other driver in the picture. Any driver will need a
functioning NT executive and HAL to run. It’s too early at that time. There
is no Ke/Io/Mm/Halxxx, no IRP at that phase. They are not born yet.
Accessing real mode BIOS from PMODE for a loader type of program is easy
and necessary. It can be done by entering V86 mode (more complicated) or
switching to real mode and then switch back to protected mode. I have done
the latter for production purpose. As long as the CPU is 80386 or better it
will be alright. Of course, it needs to be very carefully arranged and
coded, i.e. setting up a transient GDT entry due to the fact one can’t
directly switch to 16-bit seg:off RM from 32-bit PM.
Calvin Guan
Broadcom Corp.
Optional BootROM and EFI Engineer for NetXtreme 1G/10G Converged NIC
On Sun, Nov 6, 2011 at 3:40 PM, Maxim S. Shatskih wrote:
> >AFAIK BIOS interrupts are disabled after jumping into protected mode(*)
> as they been rewritten by
> >the exception mechanism.
>
> Any DOS extender of early 1990ies could solve this issue, and NT boot
> loader uses the same techniques to solve it.
>
> Also - are you sure resume data load phase runs in protected mode?
>
> >and definitely the resuming cannot be done in real mode since 32bit
> addressing is required.
>
> There are such things as int 15h and unreal mode
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Here is some explanation regarding ntbootdd.sys for Win2K
http://technet.microsoft.com/en-us/library/cc977184.aspx
I think its use is deprecated for OSs (Win2k3+) that support storport.
Hi Jon,
In a normal winresume configuration, the read of hiberfil is initiated by
winresume. The read is served by platform firmware.
I don’t know how the dump filter framework is integrated into the Win7
resume process. If I was the programmer of winresume, I would invoke your
filter after reading data from LUN.
Good luck!
Calvin
On Sun, Nov 6, 2011 at 11:34 AM, jonatan perry wrote:
> Hi Calvin,
> first of - thank you for your help.
>
> second - by “resuming process” I meant the part were windows fetch the
> memory pages that stored in the hiberfil and write them into memory, is
> that particular part done only by using INT 13? is there a different disk
> drivers stack for that purpose? is that part changed from windows xp (same
> hiberfil access method)?
>
> thanks.
>
>
> On Sun, Nov 6, 2011 at 9:20 PM, Calvin Guan (news) <
> xxxxx@gradovec.com> wrote:
>
>>
>>
>>
>> You need to define the boundary of “resuming process” more rigorously
>> before further discussion. What I can tell you fer sure is that DISK.sys
>> has nothing to do with fetching hyberfil. I’m as sure as my name is Calvin,
>> period.
>>
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>