badb0d00

WINDBG
1

Dear all,

I have noticed the address 0xbadb0d00 appearing quite frequently on various
different crash dump stack traces from different servers.

Is there something special about this address?

A quick search of WinDBG shows it appearing in this mailing list several
times since I subscribed in 2010, as well as in other mailing lists/USENET
groups. Usually it seems to appear when an exception is raised
(nt!CommonDispatchException, nt!KiDispatchException, nt!KiTrap) but also
with win32k!NtUserWaitMessage, nt!KiFastCallEntry and
hal!HalpClockInterrupt).

Here’s a recent one of mine, from a kernel dump:

STACK_TEXT:
f2c47760 e062d868 0000008e c0000005 de2b7103 nt!KeBugCheckEx+0x1b
f2c47b24 e068a31a f2c47b40 00000000 f2c47b94 nt!KiDispatchException+0x3a2
f2c47b8c e068a2ce f2c47c58 de2b7103 badb0d00 nt!CommonDispatchException+0x4a
f2c47ba0 de297292 00000000 e1d736c0 e1dbf008 nt!Kei386EoiHelper+0x186

kd> !address badb0d00
address badb0d00 not found in any known Kernel Address Range ----

kd> dd badb0d00
badb0d00 ??? ??? ??? ???
badb0d10 ??? ??? ??? ???
badb0d20 ??? ??? ??? ???
badb0d30 ??? ??? ??? ???
badb0d40 ??? ??? ??? ???
badb0d50 ??? ??? ??? ???
badb0d60 ??? ??? ??? ???
badb0d70 ??? ??? ??? ???

I’m wondering where this address came from, and why it appears to often. I
thought it might have been some sort of ‘magic number’ (ala
http://en.wikipedia.org/wiki/Magic_number_(programming)), but I can’t
find any reference to it.

Am I just reading too much into this particular hex string because it looks
a bit like “Bad Bod”, or is there some reason for it?

Thanks,

–
AdamT

2

It’s probably used for similar reasons as 0xbad0b0b0:

http://computer.forensikblog.de/en/2009/04/0xbad0b0b0.html

On Thu, Dec 20, 2012 at 10:04 AM, Adam Thompson wrote:

> Dear all,
>
> I have noticed the address 0xbadb0d00 appearing quite frequently on
> various different crash dump stack traces from different servers.
>
> Is there something special about this address?
>
> A quick search of WinDBG shows it appearing in this mailing list several
> times since I subscribed in 2010, as well as in other mailing lists/USENET
> groups. Usually it seems to appear when an exception is raised
> (nt!CommonDispatchException, nt!KiDispatchException, nt!KiTrap) but also
> with win32k!NtUserWaitMessage, nt!KiFastCallEntry and
> hal!HalpClockInterrupt).
>
> Here’s a recent one of mine, from a kernel dump:
>
> STACK_TEXT:
> f2c47760 e062d868 0000008e c0000005 de2b7103 nt!KeBugCheckEx+0x1b
> f2c47b24 e068a31a f2c47b40 00000000 f2c47b94 nt!KiDispatchException+0x3a2
> f2c47b8c e068a2ce f2c47c58 de2b7103 badb0d00
> nt!CommonDispatchException+0x4a
> f2c47ba0 de297292 00000000 e1d736c0 e1dbf008 nt!Kei386EoiHelper+0x186
>
> kd> !address badb0d00
> address badb0d00 not found in any known Kernel Address Range ----
>
> kd> dd badb0d00
> badb0d00 ??? ??? ??? ???
> badb0d10 ??? ??? ??? ???
> badb0d20 ??? ??? ??? ???
> badb0d30 ??? ??? ??? ???
> badb0d40 ??? ??? ??? ???
> badb0d50 ??? ??? ??? ???
> badb0d60 ??? ??? ??? ???
> badb0d70 ??? ??? ??? ???
>
>
> I’m wondering where this address came from, and why it appears to often.
> I thought it might have been some sort of ‘magic number’ (ala
> http://en.wikipedia.org/wiki/Magic_number_(programming)), but I can’t
> find any reference to it.
>
> Am I just reading too much into this particular hex string because it
> looks a bit like “Bad Bod”, or is there some reason for it?
>
> Thanks,
>
>
> –
> AdamT
>
> — 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

3

On 20 December 2012 15:38, Michael Hale Ligh wrote:

> It’s probably used for similar reasons as 0xbad0b0b0:
>
> http://computer.forensikblog.de/en/2009/04/0xbad0b0b0.html
>
>
>
Thanks!

That looks like a very interesting site. I think I’ve got myself some
reading to do…

–
AdamT

4

it is normally observed in _KTRAP_FRAME -> DbgArgMark

lkd> !grep -i -e “trap” -c “!process 0 17 explorer.exe”
a8d1ad5c 7c90e514 0140ff44 7c90e514 badb0d00
nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ a8d1ad64)
a8e22d48 7c90e514 00000208 0148ffac 0148ffb0
nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ a8e22d64)
a8c27d4c 7c90e514 00e6fd68 00000000 00000000
nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ a8c27d64)
a8be7d4c 7c90e514 01c2fe14 00000000 00000000
nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ a8be7d64)
a8df2d48 7c90e514 000001c8 0206ff74 00000000
nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ a8df2d64)
a8e52d48 7c90e514 000001c8 020aff74 00000000
nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ a8e52d64)
lkd> dt nt!_KTRAP_FRAME DbgArgMark a8d1ad64
+0x008 DbgArgMark : 0xbadb0d00
lkd> dt nt!_KTRAP_FRAME DbgArgMark a8e22d64
+0x008 DbgArgMark : 0xbadb0d00
lkd> dt nt!_KTRAP_FRAME DbgArgMark a8c27d64
+0x008 DbgArgMark : 0xbadb0d00
lkd> dt nt!_KTRAP_FRAME DbgArgMark a8be7d64
+0x008 DbgArgMark : 0xbadb0d00
lkd> dt nt!_KTRAP_FRAME DbgArgMark a8df2d64
+0x008 DbgArgMark : 0xbadb0d00
lkd> dt nt!_KTRAP_FRAME DbgArgMark a8e52d64
+0x008 DbgArgMark : ??
Memory read error a8e52d6c

On 12/20/12, Adam Thompson wrote:
> On 20 December 2012 15:38, Michael Hale Ligh
> wrote:
>
>> It’s probably used for similar reasons as 0xbad0b0b0:
>>
>> http://computer.forensikblog.de/en/2009/04/0xbad0b0b0.html
>>
>>
>>
> Thanks!
>
> That looks like a very interesting site. I think I’ve got myself some
> reading to do…
>
> –
> AdamT
>
> —
> 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

5

Adam Thompson wrote:

I have noticed the address 0xbadb0d00 appearing quite frequently on
various different crash dump stack traces from different servers.

Is there something special about this address?
…
I’m wondering where this address came from, and why it appears to
often. I thought it might have been some sort of ‘magic number’ (ala
http://en.wikipedia.org/wiki/Magic_number_(programming)), but I
can’t find any reference to it.

Am I just reading too much into this particular hex string because it
looks a bit like “Bad Bod”, or is there some reason for it?

Both. That value is used to initialize uninitialized memory in some
circumstances, because it is so easily identified in debugging dumps.

Personally, I usually use 0xdeadbeef or 0xfeedf00d…

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

6

well this particular badb0d00 in KiXXXXX is used as marker
google can show you many asserts (_KTRAP_FRAME->DbgArgmark)

a simple pattern searching in windbg can yield many badbod00’s in
almost all Kitraps

lkd> lm m nt
start end module name
804d7000 806cf980 nt (pdb symbols)
f:\symbols\ntkrnlpa.pdb\4BF71966DA15428C9532FDC1F6886F571\ntkrnlpa.pdb
lkd> # badb0d00 804d7000 L?(806cf980-804d7000)
nt!KiCallUserMode+0xda:
804ff776 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiSystemService+0x57:
8053d4f8 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiFastCallEntry+0x7f:
8053d5df c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiGetTickCount+0xab:
8053daa9 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiSetLowWaitHighThread+0x57:
8053dcf7 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiUnexpectedInterruptTail+0x8d:
8053de84 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap00+0x4c:
8053e208 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap01+0x4c:
8053e380 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiDebugService+0x4c:
8053e62c c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap03+0x4c:
8053e750 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap04+0x4c:
8053e8d0 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap05+0x4c:
8053ea2c c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap06+0x4c2:
8053f016 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap07+0x4c:
8053f208 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap09+0x4c:
8053f62c c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap0A+0x4a:
8053f74a c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap0B+0x4a:
8053f88a c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap0C+0x4a:
8053fae6 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap0D+0x187:
8053ff07 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap0E+0x4a:
805404d2 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap0F+0x4c:
80540804 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap10+0x4c:
80540924 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap11+0x4a:
80540a5a c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiTrap13+0x4c:
80540bc4 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
nt!KiInterruptTemplate+0x83:
8054165d c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d0db3 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d11eb c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d1383 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d153f c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d1867 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d1a03 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d1cef c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d1f8b c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d21ad c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d24e3 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d2683 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d2a4b c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d2bef c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
806d37d2 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h

On 12/21/12, Tim Roberts wrote:
> Adam Thompson wrote:
>>
>> I have noticed the address 0xbadb0d00 appearing quite frequently on
>> various different crash dump stack traces from different servers.
>>
>> Is there something special about this address?
>> …
>> I’m wondering where this address came from, and why it appears to
>> often. I thought it might have been some sort of ‘magic number’ (ala
>> http://en.wikipedia.org/wiki/Magic_number_(programming)), but I
>> can’t find any reference to it.
>>
>> Am I just reading too much into this particular hex string because it
>> looks a bit like “Bad Bod”, or is there some reason for it?
>
> Both. That value is used to initialize uninitialized memory in some
> circumstances, because it is so easily identified in debugging dumps.
>
> Personally, I usually use 0xdeadbeef or 0xfeedf00d…
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>