paging file, dump files location

NTDEV
1

hi guys,

can we change locations of paging files or dump files ? If not why its fixed (WIND_INSTALL_DIR:\windows) ?

2

You can change both from the “performance” tab of computer/properties.

Good luck,

Mm
On Sep 18, 2011 12:13 PM, wrote:
> hi guys,
>
> can we change locations of paging files or dump files ? If not why its
fixed (WIND_INSTALL_DIR:\windows) ?
>
> —
> 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

3

hi guys,

i have question regarding dump file, suppose there is problem in storage driver( which is needed to write dump file to disk, so that later we can debug it),means the os crashed because of storage driver, how OS manages to write data in dump file ?,

4

> how OS manages to write data in dump file ?,

I think the OS can do it after having returned to the firmware, i.e immediately before halting the CPU - at this point BIOS calls are already available…

Anton Bassov

5

I believe that there is a dedicated dump stack. No idea of what’s involved.

Mm
On Sep 19, 2011 12:40 AM, wrote:
>> how OS manages to write data in dump file ?,
>
> I think the OS can do it after having returned to the firmware, i.e
immediately before halting the CPU - at this point BIOS calls are already
available…
>
> 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

6

There is a dedicated dump stack, but it does involve a copy of the
storage driver so if there is a fundamental flaw in the storage driver
you are hosed and will not get the dump.

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

“Martin O’Brien” wrote in message
news:xxxxx@ntdev:

> I believe that there is a dedicated dump stack. No idea of what’s involved.
>
> Mm
> On Sep 19, 2011 12:40 AM, wrote:
> >> how OS manages to write data in dump file ?,
> >
> > I think the OS can do it after having returned to the firmware, i.e
> immediately before halting the CPU - at this point BIOS calls are already
> available…
> >
> > 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

7

> I think the OS can do it after having returned to the firmware, i.e immediately before halting the CPU - at this point

BIOS calls are already available…

It does not. It uses the second instance of the storage driver, which is called in some special mode, IIRC without interrupts being used.

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

8

Windows used to have a second copy of the storage controller driver for the boot disk loaded. If the boot controller’s driver was foo.sys, a second copy would be loaded called dump_foo.sys. In the event of a crash Windows would have this second copy reinitialize the controller and write data to the dump file.

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

-p

On Sep 18, 2011, at 11:11 PM, “Martin O’Brien” > wrote:

I believe that there is a dedicated dump stack. No idea of what’s involved.

Mm

On Sep 19, 2011 12:40 AM, <mailto:xxxxxxxxxx@hotmail.commailto:xxxxx> wrote:
>> how OS manages to write data in dump file ?,
>
> I think the OS can do it after having returned to the firmware, i.e immediately before halting the CPU - at this point BIOS calls are already available…
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http: http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http: 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: http://www.osronline.com/page.cfm?name=ListServer</http:></http:></http:></mailto:xxxxx></mailto:xxxxx>

9

oh that’s interesting, how windows handles storage driver crash scenario, i had seen mark’s video for crash analysis on youtube, in that he mentions something about page files/dump files written based on that files sectors only, i am not sure. may be i m wrong ?

as peter wrote: windows will load the second copy of storage driver in that case, then why windows doesn’t try the same thing with other drivers, and can avoid BSOD ?

10

Windows for the crash stack loads the storage mini-port with a special
port driver that does not use system services much. This is
specifically to allow the driver to operate in a corrupted environment,
this is not a general purpose solution. Note: it is more likely a
driver will corrupt something outside of its code than in, since the
size of most drivers is small compared to the kernel footprint, so the
idea of having a second copy of the driver around does not help with
resilience.

Yes, the writing of the dump file is by disk sector only, there is no
file system in the dump stack.

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

“xxxxx@yahoo.in” wrote in message
news:xxxxx@ntdev:

> oh that’s interesting, how windows handles storage driver crash scenario, i had seen mark’s video for crash analysis on youtube, in that he mentions something about page files/dump files written based on that files sectors only, i am not sure. may be i m wrong ?
>
>
> as peter wrote: windows will load the second copy of storage driver in that case, then why windows doesn’t try the same thing with other drivers, and can avoid BSOD ?

11

thanks don, peter for your desc,

suppose driver called kewaitforSingleObj() at dpc_level then windows knows that this function called at dispatch level and the caller is the faulty driver, so, for that case it can unload that faulty driver from memory and will allow to work other things, but windows cant unload that driver because may be requests are pending in driver which are submitted to lower stack. So, cant windows provide one callback function ( to handle bugchecks that are caused by that driver, in which that driver will cleanup all the resources and pending requests, etc ) which allow Os to remove that driver from memory, create necessary dump to debug problem caused by driver. May be this thing is not possible with all type of bugs, but at least with some of the stop codes ( as mentioned above ), may be its possible. Am i right ?

12

Basically what you are asking is, could Windows try to trust a driver
that just messed up badly to clean up after itself which can be a quite
complex problem and let the world go on its way? The problem is that
once the driver messes up, it should not be trusted and your solution
requires that the trust be extended to a complex task which is not a
good idea. This type of thinking shows up fairly often when people
first think about reliability and fault tolerance, but in the roughly 40
years the industry has worked in that area it almost never seems to pan
out.

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

“xxxxx@yahoo.in” wrote in message
news:xxxxx@ntdev:

> thanks don, peter for your desc,
>
> suppose driver called kewaitforSingleObj() at dpc_level then windows knows that this function called at dispatch level and the caller is the faulty driver, so, for that case it can unload that faulty driver from memory and will allow to work other things, but windows cant unload that driver because may be requests are pending in driver which are submitted to lower stack. So, cant windows provide one callback function ( to handle bugchecks that are caused by that driver, in which that driver will cleanup all the resources and pending requests, etc ) which allow Os to remove that driver from memory, create necessary dump to debug problem caused by driver. May be this thing is not possible with all type of bugs, but at least with some of the stop codes ( as mentioned above ), may be its possible. Am i right ?

13

>possible with all type of bugs

This is just plain not needed. Calling wait at DISPATCH is not a common bug, pointers/lists/memory blocks mismanagement are more common and cannot be cured by unloading the driver.

For this, you will need to run the driver in separate address space, and this is what UMDF does.

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

14

You are not right. There would be much more to recovering from this than simply unloading the driver code. You need to unwind the thread back to code that is safe. That requires skipping over all that nasty driver code. Which means you can’t undo anything that driver code was doing. What if it’s holding a lock, and that’s why it was at DPC level. Is it safe to release the lock? Is the data being protected by the lock in a valid or invalid state?

Look at what happens when a DLL loaded in an app does something invalid. The cleanup process there is to take down the entire application. Likewise in .NET, which has a garbage collector and could presumably do quite a bit of automated cleanup, the recovery is to terminate the current app domain. The equivalent in kernel-mode is to terminate the kernel, which we do with a system bugcheck. The recovery process is to restart the kernel, which requires rebooting the machine.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.in
Sent: Monday, September 19, 2011 9:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] paging file, dump files location

thanks don, peter for your desc,

suppose driver called kewaitforSingleObj() at dpc_level then windows knows that this function called at dispatch level and the caller is the faulty driver, so, for that case it can unload that faulty driver from memory and will allow to work other things, but windows cant unload that driver because may be requests are pending in driver which are submitted to lower stack. So, cant windows provide one callback function ( to handle bugchecks that are caused by that driver, in which that driver will cleanup all the resources and pending requests, etc ) which allow Os to remove that driver from memory, create necessary dump to debug problem caused by driver. May be this thing is not possible with all type of bugs, but at least with some of the stop codes ( as mentioned above ), may be its possible. Am i right ?

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

15

No - that does not happen at all. The dump path is a set of drivers
that includes a clone of the storage adapter driver for the boot disk.
Dumps are done using this driver, not using BIOS calls.

Mark Roddy

On Mon, Sep 19, 2011 at 12:42 AM, wrote:
>> how OS manages to write data in dump file ?,
>
> I think ?the OS can do it after having returned to the firmware, i.e immediately before halting the CPU - at this point BIOS calls are already available…
>
> 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
>

16

thanks mark, peter, max. everybody for your help.

17

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

18

>mean reinitializing the disk controller?

Yes, and this includes SATA Enhanced mode ones, and possibly AHCI ones, all of them are using PCI interrupts and so the interrupt stuff must be reinited too.

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

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.

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.

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

19

Well forget about what could theoretically happen in windows, 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.

Mark Roddy

On Wed, Sep 21, 2011 at 1:29 AM, wrote:
> 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
>

20

Peter discussed this just last month on nttalk.

  • S

-----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