Bug in Windbg version 6.2.9200.16384

WINDBG
1

Hi,

I noticed that disassembler of the above mentioned Windbg shows byte-reversed value of instructions where 32-bit address is:

0:001> p
eax=01cdf4bf ebx=013cf638 ecx=00000000 edx=5c0aa588 esi=013cf6d0 edi=00000001
eip=5beeb48b esp=013ce720 ebp=013cf1d4 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
dbgeng!NotifyExceptionEvent+0x8d:
5beeb48b 813b03000080 cmp dword ptr [ebx],80000003h ds:0023:013cf638=03000080

but double-byte dump shows proper value:

0:001> dd 013cf638
013cf638 80000003 00000000 00000000 00000000

L.

2

yes i noticed it but since i predominantly use 6.12 it didn’t hurt me yet
but nevertheless annoying

.386
.model flat, stdcall
option casemap:none

.code
start:
mov eax , offset foo
redo:
cmp dword ptr ds:[eax] ,-1
je quit
add eax,4
jmp redo
foo:
dd 40h dup (80000000h)
dd 10h dup (0f0000000h)
dd 0ffffffffh
quit:
retn
end start

cdb -c “bp 401000;g;p” DummyExe.exe <------ 6.12

00401005 8338ff cmp dword ptr [eax],0FFFFFFFFh ds:0023:00401013=80000000 <—

“c:\Program Files\Windows Kits\8.0\Debuggers\x86\cdb.exe” -c “bp
401000;g;p” DummyExe.exe <------------ 6.92

00401005 8338ff cmp dword ptr [eax],0FFFFFFFFh
ds:0023:00401013=00000080 <—
0:000>

On 1/18/13, xxxxx@volny.cz wrote:
> Hi,
>
> I noticed that disassembler of the above mentioned Windbg shows
> byte-reversed value of instructions where 32-bit address is:
>
> 0:001> p
> eax=01cdf4bf ebx=013cf638 ecx=00000000 edx=5c0aa588 esi=013cf6d0
> edi=00000001
> eip=5beeb48b esp=013ce720 ebp=013cf1d4 iopl=0 nv up ei pl zr na pe
> nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
> efl=00000246
> dbgeng!NotifyExceptionEvent+0x8d:
> 5beeb48b 813b03000080 cmp dword ptr [ebx],80000003h
> ds:0023:013cf638=03000080
>
> but double-byte dump shows proper value:
>
> 0:001> dd 013cf638
> 013cf638 80000003 00000000 00000000 00000000
>
> L.
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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,

I noticed that disassembler of the above mentioned Windbg shows
byte-reversed value of instructions where 32-bit address is:

0:001> p
eax=01cdf4bf ebx=013cf638 ecx=00000000 edx=5c0aa588 esi=013cf6d0
edi=00000001
eip=5beeb48b esp=013ce720 ebp=013cf1d4 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000246
dbgeng!NotifyExceptionEvent+0x8d:
5beeb48b 813b03000080 cmp dword ptr [ebx],80000003h
ds:0023:013cf638=03000080

No, the value is displayed correctly. Each nybble pair is at an
increasing address, that is,
013cf638 = 03
013cf639 = 00
013cf63a = 00
013cf63b = 80

Since the x86/x64 family are little-endian machines, a multibyte value is
addressed at its lowest byte, 03.

It could be argued that it should have said

…638 = 03 00 00 80

where the spaces indicate that it is being displayed in memory byte order,
rather than as a DWORD-sized value, which would be more intuitive, given
the instruction operand size, but it is not a particular stretch to
realize the value is being displayed as a sequence of bytes in address
order.
joe

but double-byte dump shows proper value:

0:001> dd 013cf638
013cf638 80000003 00000000 00000000 00000000

L.

WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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

4

On 1/18/13, xxxxx@flounder.com wrote:

> No, the value is displayed correctly. Each nybble pair is at an
> increasing address, that is,

i am not so much of an academic may be you are right to the book
but windbg traditionally used to show the effective address as dword
or word or byte
depending on the size of operand and it was good going

this behavior has changed in the latest drop and it is very much annoying

i would prefer to see a dword as a dword and not displayed as a nibble whatever

i paste below comparison of 6.12 and 6.92 display below

i am looking for a dword BADBABE5 and 6.12 shows it as BADBABE5
while 6.92 Shows it as e5abdbba which i might say mildly as confusing
or preface it with an angry expletive when im not in a mild mood

6.12 display

0:000> p
00401005 8338ff cmp dword ptr [eax],0FFFFFFFFh
ds:0023:0040101a=badbabe5
0:000> p
00401008 668338ff cmp word ptr [eax],0FFFFh ds:0023:0040101a=abe5
0:000> p
0040100c 8038ff cmp byte ptr [eax],0FFh ds:0023:0040101a=e5

0:000> dd eax l1;dw eax l1; db eax l1;db eax l4

0040101a badbabe5
0040101a abe5
0040101a e5 .
0040101a e5 ab db ba …

6.92 display

0:000> p
00401005 8338ff cmp dword ptr [eax],0FFFFFFFFh
ds:0023:0040101a=e5abdbba
0:000> p
00401008 668338ff cmp word ptr [eax],0FFFFh ds:0023:0040101a=e5ab
0:000> p
0040100c 8038ff cmp byte ptr [eax],0FFh ds:0023:0040101a=e5
0:000> dd eax l1;dw eax l1; db eax l1;db eax l4
0040101a badbabe5
0040101a abe5
0040101a e5 .
0040101a e5 ab db ba

notice the byte nybleble order has not changed but display of
effective address when stepping through has changed and i would
disagree with books even if books were 100 % right and would prefer
the first non book (if it is so) way anyday
…

5

xxxxx@flounder.com wrote:

> Hi,
>
> I noticed that disassembler of the above mentioned Windbg shows
> byte-reversed value of instructions where 32-bit address is:
> …
> dbgeng!NotifyExceptionEvent+0x8d:
> 5beeb48b 813b03000080 cmp dword ptr [ebx],80000003h
> ds:0023:013cf638=03000080
No, the value is displayed correctly. Each nybble pair is at an
increasing address, that is,
013cf638 = 03
013cf639 = 00
013cf63a = 00
013cf63b = 80

Oh, please. No, it’s not. It’s showing the value as a dword. As a
dword, the value of that memory is 80000003. Your argument is silly.
This is a bug in Windbg.

It could be argued that it should have said

…638 = 03 00 00 80

where the spaces indicate that it is being displayed in memory byte order,
rather than as a DWORD-sized value, which would be more intuitive,

You meant to say “which would be correct”.

given the instruction operand size, but it is not a particular stretch to
realize the value is being displayed as a sequence of bytes in address
order.

I know you really like to play Devil’s Advocate, but please take a short
trip back to reality here. This is a bug, and there is no argument you
can make that will excuse it. If you’re going to display 4 bytes as a
dword on a little-endian system, then you are required by law and
international treaty to display them as a dword, and that means 80000003.

No “person skilled in the art” would ever expect the result you are
positing.

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

6

Yes, it is a bug, (in fact a regression) and it has been fixed in the internal Microsoft version of Windbg.

Unfortunately the fix was made VERY late in the Windows 8 release cycle, and did not meet the bar for inclusion in the release.

Microsoft internal versions of windbg no longer have this problem.

Unfortunately that doesn’t help the external community very much.

The fix will ship in the WDK releases that ship as part of the next release of Windows.

Joe.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, January 18, 2013 11:16 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Bug in Windbg version 6.2.9200.16384

xxxxx@flounder.com wrote:

> Hi,
>
> I noticed that disassembler of the above mentioned Windbg shows
> byte-reversed value of instructions where 32-bit address is:
> …
> dbgeng!NotifyExceptionEvent+0x8d:
> 5beeb48b 813b03000080 cmp dword ptr [ebx],80000003h
> ds:0023:013cf638=03000080
No, the value is displayed correctly. Each nybble pair is at an
increasing address, that is,
013cf638 = 03
013cf639 = 00
013cf63a = 00
013cf63b = 80

Oh, please. No, it’s not. It’s showing the value as a dword. As a dword, the value of that memory is 80000003. Your argument is silly.
This is a bug in Windbg.

It could be argued that it should have said

…638 = 03 00 00 80

where the spaces indicate that it is being displayed in memory byte
order, rather than as a DWORD-sized value, which would be more
intuitive,

You meant to say “which would be correct”.

given the instruction operand size, but it is not a particular stretch
to realize the value is being displayed as a sequence of bytes in
address order.

I know you really like to play Devil’s Advocate, but please take a short trip back to reality here. This is a bug, and there is no argument you can make that will excuse it. If you’re going to display 4 bytes as a dword on a little-endian system, then you are required by law and international treaty to display them as a dword, and that means 80000003.

No “person skilled in the art” would ever expect the result you are positing.

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

WINDBG is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

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

And will be when? Why you (you MSFT, not you, Joe) decided to restrict releases of the 'Bag to releases of the WDK is still completely mystifying to me. All I could glean from previous threads here is that some PHB’s decree has made it so, I couldn’t find anything rational in the defense of that decision, and still can’t.

Phil B
Not speaking for LogRhythm

Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
A LEADER 2012 SIEM Magic Quadrant
WINNER of SC Magazine’s 2012 SIEM Best Buy

8

Thank You Joe Ballantyne

On 1/19/13, Joe Ballantyne wrote:
> Yes, it is a bug, (in fact a regression) and it has been fixed in the
> internal Microsoft version of Windbg.
>
> Unfortunately the fix was made VERY late in the Windows 8 release cycle, and
> did not meet the bar for inclusion in the release.
>
> Microsoft internal versions of windbg no longer have this problem.
>
> Unfortunately that doesn’t help the external community very much.
>
> The fix will ship in the WDK releases that ship as part of the next release
> of Windows.
>
> Joe.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Friday, January 18, 2013 11:16 AM
> To: Kernel Debugging Interest List
> Subject: Re: [windbg] Bug in Windbg version 6.2.9200.16384
>
> xxxxx@flounder.com wrote:
>>> Hi,
>>>
>>> I noticed that disassembler of the above mentioned Windbg shows
>>> byte-reversed value of instructions where 32-bit address is:
>>> …
>>> dbgeng!NotifyExceptionEvent+0x8d:
>>> 5beeb48b 813b03000080 cmp dword ptr [ebx],80000003h
>>> ds:0023:013cf638=03000080
>> No, the value is displayed correctly. Each nybble pair is at an
>> increasing address, that is,
>> 013cf638 = 03
>> 013cf639 = 00
>> 013cf63a = 00
>> 013cf63b = 80
>
> Oh, please. No, it’s not. It’s showing the value as a dword. As a dword,
> the value of that memory is 80000003. Your argument is silly.
> This is a bug in Windbg.
>
>
>> It could be argued that it should have said
>>
>> …638 = 03 00 00 80
>>
>> where the spaces indicate that it is being displayed in memory byte
>> order, rather than as a DWORD-sized value, which would be more
>> intuitive,
>
> You meant to say “which would be correct”.
>
>
>> given the instruction operand size, but it is not a particular stretch
>> to realize the value is being displayed as a sequence of bytes in
>> address order.
>
> I know you really like to play Devil’s Advocate, but please take a short
> trip back to reality here. This is a bug, and there is no argument you can
> make that will excuse it. If you’re going to display 4 bytes as a dword on
> a little-endian system, then you are required by law and international
> treaty to display them as a dword, and that means 80000003.
>
> No “person skilled in the art” would ever expect the result you are
> positing.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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
>
>
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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
>

9

> Unfortunately the fix was made VERY late in the Windows 8 release cycle, and

did not meet the bar for inclusion in the release.

The fix will ship in the WDK releases that ship as part of the next release
of Windows.

Thank you, Joe. Does that mean next major version (9) or next service
pack?

L.