Last Frame of KB 0'd out?

All,

I apologize if this is the wrong venue for this question. I?m working in WinDBG and am trying to conduct root cause analysis on a crash happening in an application. I?m not able to understand much starting at the top of the stack but when I got to the last frame, I was puzzled. So my question to the group is ? why is the last frame of KB is all 0d out?

Example:
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
00129474 03f38bf9 00000000 00000000 01000002 wvcore!SPSubstringReplace+0x186
00129484 03f369bc 0000006c 00000003 00000001 ospdf!TTFFontLibrary::removeFontWithUniqueId+0xd99
001294a4 01891215 7fcb7fd8 70c18a00 7fd9a180 ospdf!TTFFontNameIterator::TTFFontNameIterator+0x84c
001294bc 01890c64 7fcb7fd8 70c18a00 00000004 wvcore!SPVectorSize+0x35
001294d4 03f28c8b 80035ad1 70c18a00 70e6d0f0 wvcore!SPVectorAddReference+0x24
00000000 00000000 00000000 00000000 00000000 ospdf!oit::FontStrike::GetFontFace+0xb8fb <====== Why is this all 0s?

Can anyone shed light on this? Or provide reference to reading material? I was under the impression I should be seeing actual values.

Thanks!

Devon

Devon Greene wrote:

I apologize if this is the wrong venue for this question. I’m working
in WinDBG and am trying to conduct root cause analysis on a crash
happening in an application. I’m not able to understand much starting
at the top of the stack but when I got to the last frame, I was
puzzled. So my question to the group is — why is the last frame of KB
is all 0d out?

Example:
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may
be wrong.
00129474 03f38bf9 00000000 00000000 01000002
wvcore!SPSubstringReplace+0x186
00129484 03f369bc 0000006c 00000003 00000001
ospdf!TTFFontLibrary::removeFontWithUniqueId+0xd99
001294a4 01891215 7fcb7fd8 70c18a00 7fd9a180
ospdf!TTFFontNameIterator::TTFFontNameIterator+0x84c
001294bc 01890c64 7fcb7fd8 70c18a00 00000004 wvcore!SPVectorSize+0x35
001294d4 03f28c8b 80035ad1 70c18a00 70e6d0f0
wvcore!SPVectorAddReference+0x24
00000000 00000000 00000000 00000000 00000000
ospdf!oit::FontStrike::GetFontFace+0xb8fb <====== Why is this all 0s?

Can anyone shed light on this? Or provide reference to reading
material? I was under the impression I should be seeing actual values.

You are, but the debugger can only do so much. Stack frames are all
just a software convention. The debugger can only trace them back as
long as all of the players follow the rules and store their registers in
the generally accepted spot. If some clever programmer decides not to
save his EBP register in the accepted spot, or if some rogue function
overwrites the end of an array, and trashes the saved values, that
linkage can all be lost.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim,

THanks for the quick response. That was the sanity check I needed. :slight_smile:

Devon

On 4/11/17, 12:17 PM, “xxxxx@lists.osr.com on behalf of Tim
Roberts”
wrote:

>Devon Greene wrote:
>>
>> I apologize if this is the wrong venue for this question. I?m working
>> in WinDBG and am trying to conduct root cause analysis on a crash
>> happening in an application. I?m not able to understand much starting
>> at the top of the stack but when I got to the last frame, I was
>> puzzled. So my question to the group is ? why is the last frame of KB
>> is all 0d out?
>>
>> Example:
>> ChildEBP RetAddr Args to Child
>> WARNING: Stack unwind information not available. Following frames may
>> be wrong.
>> 00129474 03f38bf9 00000000 00000000 01000002
>> wvcore!SPSubstringReplace+0x186
>> 00129484 03f369bc 0000006c 00000003 00000001
>> ospdf!TTFFontLibrary::removeFontWithUniqueId+0xd99
>> 001294a4 01891215 7fcb7fd8 70c18a00 7fd9a180
>> ospdf!TTFFontNameIterator::TTFFontNameIterator+0x84c
>> 001294bc 01890c64 7fcb7fd8 70c18a00 00000004 wvcore!SPVectorSize+0x35
>> 001294d4 03f28c8b 80035ad1 70c18a00 70e6d0f0
>> wvcore!SPVectorAddReference+0x24
>> 00000000 00000000 00000000 00000000 00000000
>> ospdf!oit::FontStrike::GetFontFace+0xb8fb <====== Why is this all 0s?
>>
>> Can anyone shed light on this? Or provide reference to reading
>> material? I was under the impression I should be seeing actual values.
>
>You are, but the debugger can only do so much. Stack frames are all
>just a software convention. The debugger can only trace them back as
>long as all of the players follow the rules and store their registers in
>the generally accepted spot. If some clever programmer decides not to
>save his EBP register in the accepted spot, or if some rogue function
>overwrites the end of an array, and trashes the saved values, that
>linkage can all be lost.
>
>–
>Tim Roberts, xxxxx@probo.com
>Providenza & Boekelheide, Inc.
>
>
>—
>WINDBG is sponsored by OSR
>
>OSR is hiring!! Info at
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osr.co
>m%2Fcareers&data=02%7C01%7Cdgreene%40ixiacom.com%7Cf1d284f5d1c84aefb86208d
>480fec73a%7C069fd614e3f843728e18cd06724a9b23%7C0%7C0%7C636275279126544726&
>sdata=7cNJ%2BidniNU3CjABcQeUAXYLXsxRvjOa0D9VPWHIWq4%3D&reserved=0
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at
>https:>om%2Fseminars&data=02%7C01%7Cdgreene%40ixiacom.com%7Cf1d284f5d1c84aefb8620
>8d480fec73a%7C069fd614e3f843728e18cd06724a9b23%7C0%7C0%7C63627527912654472
>6&sdata=4AEx2tm1JmWyatoh4TrVK4T2c4wlq%2FCd05%2BHM%2B%2BE2tE%3D&reserved=0>
>
>To unsubscribe, visit the List Server section of OSR Online at
>https:>line.com%2Fpage.cfm%3Fname%3DListServer&data=02%7C01%7Cdgreene%40ixiacom.c
>om%7Cf1d284f5d1c84aefb86208d480fec73a%7C069fd614e3f843728e18cd06724a9b23%7
>C0%7C0%7C636275279126544726&sdata=xUwR%2FURnqs473tIzIivQ29zjY3YRzkKWyjZpgH
>Rjc5s%3D&reserved=0></https:></https:>