Getting core dump after double fault?

Hello all,

I’ve been trying to debug my driver. It keeps generating double
faults and I think the cause is because of kernel stack overflow.
I’ve been trying to get a kernel dump by setting the dump settings in
the Windows control panel under System->Advanced settings. However,
when the machine blue screens, a kernel dump is not generated. Is
this on expected? Is it possible to get a dump after a double fault
(kernel stack overflow)?

Thanks,
J

How about attaching a kernel debugger while the machine is running so that you do not have to rely on a dump file?

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Jonathon
Sent: Monday, March 01, 2010 7:12 PM
To: Kernel Debugging Interest List
Subject: [windbg] Getting core dump after double fault?

Hello all,

I’ve been trying to debug my driver. It keeps generating double
faults and I think the cause is because of kernel stack overflow.
I’ve been trying to get a kernel dump by setting the dump settings in
the Windows control panel under System->Advanced settings. However,
when the machine blue screens, a kernel dump is not generated. Is
this on expected? Is it possible to get a dump after a double fault
(kernel stack overflow)?

Thanks,
J


WINDBG 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

It is possible to get a dump after a double fault. However, Dorons
recommendation is a good one.
If you can get a dump or break at the fault you can roughly calculate your
stack usage by subtracting the values in the stack dump. Even if you can’t
reproduce the crash you can set break points in your code and see how much
you are using. I also suggest you look through your code and eliminate any
local variables that are much more that a pointer and instead allocate them
from the heap.
Jim

On Mon, Mar 1, 2010 at 10:10 PM, Jonathon wrote:

> Hello all,
>
> I’ve been trying to debug my driver. It keeps generating double
> faults and I think the cause is because of kernel stack overflow.
> I’ve been trying to get a kernel dump by setting the dump settings in
> the Windows control panel under System->Advanced settings. However,
> when the machine blue screens, a kernel dump is not generated. Is
> this on expected? Is it possible to get a dump after a double fault
> (kernel stack overflow)?
>
> Thanks,
> J
>
> —
> WINDBG 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 also suggest you look through your code and eliminate any local variables

that are much more that a pointer and instead >allocate them from the heap.

The StackHogThreshold switch to Prefast is good at weeding out local
variable heavy routines.

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Jim Donelson” wrote in message news:xxxxx@windbg…
It is possible to get a dump after a double fault. However, Dorons
recommendation is a good one.
If you can get a dump or break at the fault you can roughly calculate your
stack usage by subtracting the values in the stack dump. Even if you can’t
reproduce the crash you can set break points in your code and see how much
you are using. I also suggest you look through your code and eliminate any
local variables that are much more that a pointer and instead allocate them
from the heap.
Jim

On Mon, Mar 1, 2010 at 10:10 PM, Jonathon wrote:

Hello all,

I’ve been trying to debug my driver. It keeps generating double
faults and I think the cause is because of kernel stack overflow.
I’ve been trying to get a kernel dump by setting the dump settings in
the Windows control panel under System->Advanced settings. However,
when the machine blue screens, a kernel dump is not generated. Is
this on expected? Is it possible to get a dump after a double fault
(kernel stack overflow)?

Thanks,
J


WINDBG 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

Not getting a crash dump is a pain, but here are things to look for:

  1. Enough storage space on the drive where the .DMP file is being written to

  2. A large enough paging file

  3. Check the event log. Win7 now may delete your crash dump automatically
    instead of saving it, so you might have a message there about that if you’re
    on Win7.

  4. Are you using an Intel storage controller with the IASTOR port driver? If
    so, you might want to try finding an updated version on the website, I think
    there are buggy versions out there (empirical evidence, no hard data to
    support that).

Other than that, not getting a crash dump can remain an unsolved mystery
unfortunately since there isn’t much instrumentation in that path to
determine why things go wrong.

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Jonathon” wrote in message news:xxxxx@windbg…
> Hello all,
>
> I’ve been trying to debug my driver. It keeps generating double
> faults and I think the cause is because of kernel stack overflow.
> I’ve been trying to get a kernel dump by setting the dump settings in
> the Windows control panel under System->Advanced settings. However,
> when the machine blue screens, a kernel dump is not generated. Is
> this on expected? Is it possible to get a dump after a double fault
> (kernel stack overflow)?
>
> Thanks,
> J
>

Thanks for the suggestions. They are a great help. I am pretty sure
there is enough storage space. Is there a way to check the paging
file size? What’s a good size to have and how do I check what the
current size is?

On Tue, Mar 2, 2010 at 11:23 AM, Scott Noone wrote:
> Not getting a crash dump is a pain, but here are things to look for:
>
> 1) Enough storage space on the drive where the .DMP file is being written to
>
> 2) A large enough paging file
>
> 3) Check the event log. Win7 now may delete your crash dump automatically
> instead of saving it, so you might have a message there about that if you’re
> on Win7.
>
> 4) Are you using an Intel storage controller with the IASTOR port driver? If
> so, you might want to try finding an updated version on the website, I think
> there are buggy versions out there (empirical evidence, no hard data to
> support that).
>
> Other than that, not getting a crash dump can remain an unsolved mystery
> unfortunately since there isn’t much instrumentation in that path to
> determine why things go wrong.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “Jonathon” wrote in message news:xxxxx@windbg…
>>
>> Hello all,
>>
>> I’ve been trying to debug my driver. ?It keeps generating double
>> faults and I think the cause is because of kernel stack overflow.
>> I’ve been trying to get a kernel dump by setting the dump settings in
>> the Windows control panel under System->Advanced settings. ?However,
>> when the machine blue screens, a kernel dump is not generated. ?Is
>> this on expected? Is it possible to get a dump after a double fault
>> (kernel stack overflow)?
>>
>> Thanks,
>> J
>>
>
> —
> WINDBG 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
>

Generally the paging file is not a problem unless you’ve done something
weird (or something has done something weird without you knowing). You can
check the size under the performance options:

My Computer->Properties->Advanced->Performance [Settings]->Advanced->Virtual
memory

(I can’t believe you didn’t know that :))

For a full memory dump it needs to be the size of your physical memory plus
1MB. For a kernel summary dump it will vary, though to be safe it should be
at least the size of the kernel virtual address space (2GB on x86) plus some
overhead (probably 1MB also).

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Jonathon” wrote in message news:xxxxx@windbg…
> Thanks for the suggestions. They are a great help. I am pretty sure
> there is enough storage space. Is there a way to check the paging
> file size? What’s a good size to have and how do I check what the
> current size is?
>
>
>
> On Tue, Mar 2, 2010 at 11:23 AM, Scott Noone wrote:
>> Not getting a crash dump is a pain, but here are things to look for:
>>
>> 1) Enough storage space on the drive where the .DMP file is being written
>> to
>>
>> 2) A large enough paging file
>>
>> 3) Check the event log. Win7 now may delete your crash dump automatically
>> instead of saving it, so you might have a message there about that if
>> you’re
>> on Win7.
>>
>> 4) Are you using an Intel storage controller with the IASTOR port driver?
>> If
>> so, you might want to try finding an updated version on the website, I
>> think
>> there are buggy versions out there (empirical evidence, no hard data to
>> support that).
>>
>> Other than that, not getting a crash dump can remain an unsolved mystery
>> unfortunately since there isn’t much instrumentation in that path to
>> determine why things go wrong.
>>
>> -scott
>>
>> –
>> Scott Noone
>> Consulting Associate
>> OSR Open Systems Resources, Inc.
>> http://www.osronline.com
>>
>>
>> “Jonathon” wrote in message news:xxxxx@windbg…
>>>
>>> Hello all,
>>>
>>> I’ve been trying to debug my driver. It keeps generating double
>>> faults and I think the cause is because of kernel stack overflow.
>>> I’ve been trying to get a kernel dump by setting the dump settings in
>>> the Windows control panel under System->Advanced settings. However,
>>> when the machine blue screens, a kernel dump is not generated. Is
>>> this on expected? Is it possible to get a dump after a double fault
>>> (kernel stack overflow)?
>>>
>>> Thanks,
>>> J
>>>
>>
>> —
>> WINDBG 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
>>
>

/me recalls reading something about this recently…
/me cracks open his new copy of Windows Internals 5e
(/me grimaces to recall that it went on Safari right after I bought it)

There’s a long section on pages 1150-1152 about missing crash dumps.

*Paging file is too small to hold the dump.
*Kernel code/data structures corrupted at the time of the crash
*Disk subsystem is unable to handle write requests (may be cause of crash)
*If system has drivers who register a callback to add secondary dump
data to the crash, and they access paged memory (would cause a second crash)
*Recursive faults (corrupt trap handler causes page fault, or bad hardware)
*Sysinternals Blue Screen screensaver (XD)

/me savors the new-book smell for a moment.

Thanks,
Daniel

On 3/2/2010 1:07 PM, Scott Noone wrote:

Generally the paging file is not a problem unless you’ve done
something weird (or something has done something weird without you
knowing). You can check the size under the performance options:

My Computer->Properties->Advanced->Performance
[Settings]->Advanced->Virtual memory

(I can’t believe you didn’t know that :))

For a full memory dump it needs to be the size of your physical memory
plus 1MB. For a kernel summary dump it will vary, though to be safe it
should be at least the size of the kernel virtual address space (2GB
on x86) plus some overhead (probably 1MB also).

-scott

I do a bit of analysis on user-level dumps in other forums, and find that the majority of crashes without dumps (once the above suggestions are ruled out) are due to hardware failures.

Try running assorted stress tests to rule out a hardware issue. Then, rule out Windows as the cause (for example, the recursive fault discussed above). If all that passes - then you can start blaming the driver.