Monitoring crash dump progress

NTDEV
1

I am writing a driver that is called back when the system crashes. I
need to update the progress of the crash dump and am having troubles
trying to mimic the stock percentage calculation. I cannot find a
reliable way to calculate the total memory to be dumped, therefore, my
percentage is always off.

How do I determine the expected amount of memory to be written to the
dump file?

I am working with Windows 2003 Server.

Thanks,
Steve

2

Wow…no one knows how to get the amount of physical memory??? or is not
willing to share?

3

What exactly do you want to know ? If you call your callback is a simple,
primary form of bugcheck callback, then anyway
type of callback is anyway called before ANY memory is written to disk, so
you cannot update the info sequencially.
If you use the advanced form introduced in SP1 fo XP, the so called
BugCheckDumpIoCallback, this provided all info you need.
If you build your own dump stack, then you already know how many memory you
want to write to … whatever device, providing you
observe the draconic rules.

And knowing the ammount of physical memory in system is not enough, there
are various type of crash dumps, which can contain
less then the ammount present in the system. Think minidumps, kernel dumps,
etc

Ciao, Dan

From: “Steve Meisner”
To: “Windows System Software Devs Interest List”
Sent: Friday, December 12, 2003 9:46 PM
Subject: [ntdev] Re: Monitoring crash dump progress

> Wow…no one knows how to get the amount of physical memory??? or is not
> willing to share?
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

4

Yes, as I pointed out in my first posting, I was looking for the total to
be written. This would take into account different dump types.

When you say, “If you build your own dump stack,” pardon my ignorance, but
what do you mean? What dump stack?

What I need to know is simple (the answer may not be): how much memory is
to be written to the dump file so I can calculate the correct percentage
completed each time I am called at my BugCheckDumpIoCallback routine.

Thanks for the reply, Dan!!

What exactly do you want to know ? If you call your callback is a simple,
primary form of bugcheck callback, then anyway
type of callback is anyway called before ANY memory is written to disk, so
you cannot update the info sequencially.
If you use the advanced form introduced in SP1 fo XP, the so called
BugCheckDumpIoCallback, this provided all info you need.
If you build your own dump stack, then you already know how many memory you
want to write to … whatever device, providing you
observe the draconic rules.

And knowing the ammount of physical memory in system is not enough, there
are various type of crash dumps, which can contain
less then the ammount present in the system. Think minidumps, kernel dumps,
etc

Ciao, Dan

From: “Steve Meisner”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, December 12, 2003 9:46 PM
> Subject: [ntdev] Re: Monitoring crash dump progress
>
>
> > Wow…no one knows how to get the amount of physical memory??? or is not
> > willing to share?
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >

5

MmGetPhysicalMemoryRanges() can be used to this purpose. Is exported, but
undocumented. And I cant recall in
what kernel incarnation was first introduced. I think Windows 2000, since it
was the first OS to support adding / removing on
the fly physicall memory.

Dan

----- Original Message -----
From: “Steve Meisner”
To: “Windows System Software Devs Interest List”
Sent: Friday, December 12, 2003 10:20 PM
Subject: [ntdev] Re: Monitoring crash dump progress

> Yes, as I pointed out in my first posting, I was looking for the total to
> be written. This would take into account different dump types.
>
> When you say, “If you build your own dump stack,” pardon my ignorance, but
> what do you mean? What dump stack?
>
> What I need to know is simple (the answer may not be): how much memory is
> to be written to the dump file so I can calculate the correct percentage
> completed each time I am called at my BugCheckDumpIoCallback routine.
>
> Thanks for the reply, Dan!!
>
> > What exactly do you want to know ? If you call your callback is a
simple,
> > primary form of bugcheck callback, then anyway
> > type of callback is anyway called before ANY memory is written to disk,
so
> > you cannot update the info sequencially.
> > If you use the advanced form introduced in SP1 fo XP, the so called
> > BugCheckDumpIoCallback, this provided all info you need.
> > If you build your own dump stack, then you already know how many memory
you
> > want to write to … whatever device, providing you
> > observe the draconic rules.
> >
> > And knowing the ammount of physical memory in system is not enough,
there
> > are various type of crash dumps, which can contain
> > less then the ammount present in the system. Think minidumps, kernel
dumps,
> > etc
> >
> > Ciao, Dan
> >
> >
> >
> > From: “Steve Meisner”
> > To: “Windows System Software Devs Interest List”
> > Sent: Friday, December 12, 2003 9:46 PM
> > Subject: [ntdev] Re: Monitoring crash dump progress
> >
> >
> > > Wow…no one knows how to get the amount of physical memory??? or is
not
> > > willing to share?
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

6

“Steve Meisner” wrote in message news:xxxxx@ntdev…
>
> Yes, as I pointed out in my first posting, I was looking for the total to
> be written. This would take into account different dump types.
>

I think the problem is that we’re not sure precisely what you’re asking: If
you’re writing a crash dump driver that works with the standard Windows
process, then Windows does this already (so what else is it that you need to
know). If, otoh, you’re trying to write your own crash dump (somehow,
somewhere) without using the O/S crash dump facility then… (good luck and)
you’ll need to first determine the type of dump being taken (look in the
registry’s restart settings) and then you’ll need to determine the size of
physical memory.

Thus, if you’re asking “how do I find out the amount of physical memory on a
given machine” the answer is you look in:

\REGISTRY\MACHINE\HARDWARE\RESOURCEMAP\System Resources\Physical Memory

or, at least, that’s where I look. This will also give you the starting
physical addresses and lengths of each memory segment.

Rolling your own crashdump (without using the normal Windows O/S mechanisms)
isn’t trivial. I’d think being able to get the percentage markers correct
would be the least of your problems :slight_smile:

Peter
OSR

7

Thanks for the replies…OK this is what I am doing; we have a headless
system that uses the Special Administration Console to display when a
crash is occuring (as well as other functions). When a crash happens, I
merely want to count from 0 to 99 percent so that when the dump is
complete, I am at 99%.

The SAC console is displayed on a management system and is driven by the
driver I am working on. So it is the responsibilty of this driver to mimic
the standard crash update display.

I am not writing a new crash dump mechanism…just trying to simulate the
standard Windows 2K3 one.

To accomplish this update, I only need to know how much data is going to
be written. The actual amount dumped to disk IS NOT the same as the amount
indicated by the registry, and not the amount specified in the
SharedUserData field. I believe the MmGetPhysicalMemoryRanges function
returns the same data held in the registry.

I think the problem is that we’re not sure precisely what you’re asking: If
you’re writing a crash dump driver that works with the standard Windows
process, then Windows does this already (so what else is it that you need to
know). If, otoh, you’re trying to write your own crash dump (somehow,
somewhere) without using the O/S crash dump facility then… (good luck and)
you’ll need to first determine the type of dump being taken (look in the
registry’s restart settings) and then you’ll need to determine the size of
physical memory.

Thus, if you’re asking “how do I find out the amount of physical memory on a
given machine” the answer is you look in:

\REGISTRY\MACHINE\HARDWARE\RESOURCEMAP\System Resources\Physical Memory

or, at least, that’s where *I* look. This will also give you the starting
physical addresses and lengths of each memory segment.

Rolling your own crashdump (without using the normal Windows O/S mechanisms)
isn’t trivial. I’d think being able to get the percentage markers correct
would be the least of your problems :slight_smile:

Peter
OSR

8

There is an undocumeted ke interface, KeGetBugCheckMessageText, that will
produce pointers to the bugcheck state strings (start, progress, complete),
that would do exactly what you want. Unfortunately the interface may not be
exported. You might want to redirect this question to Microsoft, as your
needs appear to be legitimate for a headless system.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Meisner
Sent: Friday, December 12, 2003 8:49 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Monitoring crash dump progress

Thanks for the replies…OK this is what I am doing; we have
a headless system that uses the Special Administration
Console to display when a crash is occuring (as well as other
functions). When a crash happens, I merely want to count from
0 to 99 percent so that when the dump is complete, I am at 99%.

The SAC console is displayed on a management system and is
driven by the driver I am working on. So it is the
responsibilty of this driver to mimic the standard crash
update display.

I am not writing a new crash dump mechanism…just trying to
simulate the standard Windows 2K3 one.

To accomplish this update, I only need to know how much data
is going to be written. The actual amount dumped to disk IS
NOT the same as the amount indicated by the registry, and not
the amount specified in the SharedUserData field. I believe
the MmGetPhysicalMemoryRanges function returns the same data
held in the registry.

> I think the problem is that we’re not sure precisely what you’re
> asking: If you’re writing a crash dump driver that works with the
> standard Windows process, then Windows does this already
(so what else
> is it that you need to know). If, otoh, you’re trying to
write your
> own crash dump (somehow,
> somewhere) without using the O/S crash dump facility then… (good
> luck and) you’ll need to first determine the type of dump
being taken
> (look in the registry’s restart settings) and then you’ll need to
> determine the size of physical memory.
>
> Thus, if you’re asking “how do I find out the amount of physical
> memory on a given machine” the answer is you look in:
>
> \REGISTRY\MACHINE\HARDWARE\RESOURCEMAP\System Resources\Physical
> Memory
>
> or, at least, that’s where *I* look. This will also give you the
> starting physical addresses and lengths of each memory segment.
>
> Rolling your own crashdump (without using the normal Windows O/S
> mechanisms) isn’t trivial. I’d think being able to get the
percentage
> markers correct would be the least of your problems :slight_smile:
>
> Peter
> OSR

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com