paging file, dump files location

> BIOS is just too primitive to do such things. It is nothing more than ACPI table + primitive int13h stuff

  • UI to tweak the settings of the same ACPI table. Nothing else.

Yes, but why do you think anything above “primitive int13h stuff” may be needed here, in the first place???

Also note that BIOS init code will with good chances dirty some memory contents.

If you think about it carefully you will realize that there is a logical fallacy here. If what you are saying could be true…well, then BIOS would be simply unusable for whatever purpose.

Anton Bassov

> Peter discussed this just last month on nttalk.

Thanks for the pointer, Ken - I am going to check NTTALK archives…

Anton Bassov

> the reality is that the dump stack does not use BIOS access methods, it uses a clone of the

boot device storage adapter driver to perform disk IO.

Well, we have already established that, right. What I am interested in is whether BIOS per se is unsuitable for the
task like that, or if this is just the question of a particular implementation choice…

In any case, I am on my way to NTTALK archives…

Anton Bassov

Among other things, yes. You have a program running in memory that has total control of the PC (the BIOS). You then take the hardware out from under it, move stuff around, reinitialize components, etc…

How does the OS know on a crash how to put everything back exactly as the BIOS left it? Either you save the state of everything and restore it, which would probably be very destructive to the state of the machine you were trying to capture, or you restart the program (e.g. re-POST) which is also very destructive to the state of the machine you’re trying to capture.

I guess it depends on whether you want something reliable, that will work on most every PC in the world with every hardware & BIOS combination, or whether you want something that works once in a while. If the latter then just restore the IDT and cross your fingers. If the former, good luck.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Tuesday, September 20, 2011 10:30 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] paging file, dump files location

Peter,

Windows cannot use the BIOS to dump as Anton suggests. The BIOS would
need to be reinitialized, which requires reposting the machine.

What do you mean by “BIOS would need to be reinitialized” in this context? Although there are some certain things that just cannot be restored without reposting (they normally involve modifying write-once bits in MSRs), but they seem to be unrelated to our issue - after all, the only thing that we need here is the ability to make INT 13h calls.Therefore, the only thing we seem to need to restore is the original boot-time IDT- we don’t care about PIC/APIC mode, interrupt routing/mapping and other things that the OS may have reprogrammed, right. Do you mean reinitializing the disk controller?

Anton Bassov


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

>> Also note that BIOS init code will with good chances dirty some memory contents.

If you think about it carefully you will realize that there is a logical fallacy here.

Not at all. Are you really sure that BIOS init code guarantees that it will not update any RAM?

For me, its only guarantee is to have a valid IDT+valid BDA at 0x400 when it will be done.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> I guess it depends on whether you want something reliable, that will work on most every PC in the

world with every hardware & BIOS combination, or whether you want something that works
once in a while.

LOL…

Although this argument is perfectly reasonable under the normal circumstances, we are speaking about
quite special situation (which, in the ideal world, should never occur, in the first place) here. We are speaking about the case that just cannot be reliable, by its very definition. Among the first things that get into my head on the spot is the scenario when you just have no chance to bugcheck because the failing instruction did something that resets the CPU right on the spot (like invalid write to a control register);
the one where the “dump stack” itself got compromized by a buggy driver; and so on and so forth…

Anton Bassov

> Are you really sure that BIOS init code guarantees that it will not update any RAM?

Oh, I see - you are speaking about POST, right. However, I don’t see any reason for reposting (which, indeed, will completely destroy the state of the machine that we are trying to dump)…

Anton Bassov

Anton,

Quite true, but having helped a client who did a software product
that used the BIOS in interesting ways on bootup, trying to rely on the
BIOS for anything other than a raw machine produces its own headaches.
Today’s BIOS’s can easily grab large blocks o9f memory, much of which
the OS is using and needs to record for the dump. Having worked through
the dump stack including putting together some dump filters (both before
and after Microsoft supported dump filtering) I have been impressed on
how small the number of items that can corrupt getting a dump really is.
This isn’t something most of us think about but the team who have put
this together have done an excellent job.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:

> > I guess it depends on whether you want something reliable, that will work on most every PC in the
> > world with every hardware & BIOS combination, or whether you want something that works
> > once in a while.
>
> LOL…
>
>
>
> Although this argument is perfectly reasonable under the normal circumstances, we are speaking about
> quite special situation (which, in the ideal world, should never occur, in the first place) here. We are speaking about the case that just cannot be reliable, by its very definition. Among the first things that get into my head on the spot is the scenario when you just have no chance to bugcheck because the failing instruction did something that resets the CPU right on the spot (like invalid write to a control register);
> the one where the “dump stack” itself got compromized by a buggy driver; and so on and so forth…
>
>
>
> Anton Bassov

> Oh, I see - you are speaking about POST, right.

Also note that such an idea will impose the major load on BIOS, and, given the number of buggy BIOSes the modern days (even reflashed the BIOS on your machine to get rid of issues? I did it with 50% of new motherboards I have), this is the bad idea.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Wedging the dump process is worse than losing the dump and rebooting. A rebooted machine can come back up and go back to work. A machine stuck in the dump stack is wasted until a human comes around and presses the button.

As nice as it might be to get a dump in all cases, that’s not going to happen and you need to err on the side of caution and get the machine back up.

In the end it’s a hypothetical argument. I’ve had experience with what can happen when you initialize a disk controller out from under the BIOS (we had a path in our boot loader which I fixed that was doing this). It doesn’t turn out well. Perhaps there are machines in the world where it would be fine but the risks outweigh the benefits.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, September 21, 2011 1:47 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] paging file, dump files location

I guess it depends on whether you want something reliable, that will
work on most every PC in the world with every hardware & BIOS
combination, or whether you want something that works once in a while.

LOL…

Although this argument is perfectly reasonable under the normal circumstances, we are speaking about quite special situation (which, in the ideal world, should never occur, in the first place) here. We are speaking about the case that just cannot be reliable, by its very definition. Among the first things that get into my head on the spot is the scenario when you just have no chance to bugcheck because the failing instruction did something that resets the CPU right on the spot (like invalid write to a control register); the one where the “dump stack” itself got compromized by a buggy driver; and so on and so forth…

Anton Bassov


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

On 21-Sep-2011 22:39, Maxim S. Shatskih wrote:

>> Also note that BIOS init code will with good chances dirty some memory contents.
>
> If you think about it carefully you will realize that there is a logical fallacy here.

Not at all. Are you really sure that BIOS init code guarantees that it will not update any RAM?

For me, its only guarantee is to have a valid IDT+valid BDA at 0x400 when it will be done.

How about handling protected -> real mode transition via reset in the
old DOS extender days? IIRC there are some special POST modes that avoid
touching memory.

– pa

> How about handling protected -> real mode transition via reset

old DOS extender days? IIRC there are some special POST modes that avoid
touching memory.

All of this was used on 286 only, 386 allowed to quit protected mode without the CPU reset.

Nevertheless, real mode is only a part of the picture, with interrupts and hardware to be reinitialized too.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>EFI is by far more powerful, but it is not used on anything except Apple’s stuff (probably

since kernel->EFI interface is simpler then kernel->ACPI and thus this leads to smaller kernel) and some
Intel’s servers. The reason is that the world is fine with ACPI, and there is no major demand for EFI.

Read this link…

http://www.zdnet.com/blog/microsoft/will-windows-8-block-users-from-dual-booting-linux-microsoft-wont-say/10772

Anton Bassov

> Read this link…

http://www.zdnet.com/blog/microsoft/will-windows-8-block-users-from-dual-booting-linux-microsoft-wont-
say/10772

Yet another alarmist conspiracy theory.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> Yet another alarmist conspiracy theory.

Could be the case, but this is not the point. The point is that Win8-compliant systems would have to replace
legacy BIOS with UEFI which, as you claim, is not in demand.

Concerning the claim itself… well, I think it may be not as unfounded as it seems to be (although such a discussion seems to be so incredibly NTTALKish). The primary reason here may be not a fight with Linux
but an attempt to push earlier Windows out of existence as fast as they can…

Anton Bassov

> legacy BIOS with UEFI which, as you claim, is not in demand.

And this is also a gossip for now.

but an attempt to push earlier Windows out of existence as fast as they can…

How many people will replace Win7/8 with XP on netbooks, given that Win7 is fine on Atom+1GB RAM?


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> And this is also a gossip for now

I dunno…

The thing is, if such plan ever comes true…well, the key phrase here is “death of Type1 hypervisor”.
Let’s face it - if you disallow anyone other than a particular OS boot the machine the very concept of
implementing bare-metal hypervisor becomes “'rather problematic”, so to say (in fact, simply infeasible
unless this hypervisor comes from OEM, MSFT or someone who cooperates with them )…

Taking into consideration that Type1 hypervisors just starting to make their way to the lower-end desktops and laptops, as well as a general trend of government offices in various countries ( EU ones, Japan,Russia,etc) to migrate to Linux or at least to increase its presence, I can imagine what the resulting antitrust cases will be like and what amounts in penalties MSFT will have to pay if it ever attempts something like that…

Anton Bassov

On Thu, Sep 22, 2011 at 5:47 AM, wrote:
> unless this hypervisor comes from OEM,

Which it very well might.

Mark Roddy

> Which it very well might.

Is it some kind of insider knowledge, Mark?

Anton Bassov

Insider? No, I believe it is public knowledge that several of the big
platform vendors have been poking around in the hv space.

I’m sure that this all motivated by the best of intentions, however it
does appear to raise the bar quite a bit higher with respect to OS
deployment on standard platforms.

Mark Roddy

On Thu, Sep 22, 2011 at 9:49 AM, wrote:
>> Which it very well might.
>
> Is it some kind of insider knowledge, Mark?
>
> Anton Bassov
>
> —
> 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
>