2

I use !objsize command to get the true value of an object. For example when I run the command below, it tells me that size of object at address 00000003a275f218 is 18 hex which translates to 24 in decimal.

0:000> !ObjSize 00000003a275f218 
sizeof(00000003a275f218) = 24 (0x18) bytes

So far so good. I am running same command on an object and its size seem to have a discrepancy between hex and decimal. enter image description here

So the size in hex is 0xafbde200. When I convert it to decimal using my calc, this comes to be 2948456960 whereas the output of command is showing decimal size to be -1346510336. Can someone help me understand why there is difference in sizes?

whoami
  • 1,689
  • 3
  • 22
  • 45

2 Answers2

3

It's a bug in SOS. If you look at the source code, you'll find the method declared as

DECLARE_API(ObjSize)

It uses the following format as output

ExtOut("sizeof(%p) = %d (0x%x) bytes (%S)\n", SOS_PTR(obj), size, size, methodTable.GetName());

As you can see it uses %d as the format specifier, which is for signed decimal integers. That should be %u for unsigned decimal integers instead, since obviously you can't have objects using negative amount of memory.

If you know how to use Git, you may provide a patch.

You can use ? in WinDbg to see the unsigned value:

0:000> ? 0xafbde200
Evaluate expression: 2948456960 = 00000000`afbde200
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
2

Difference is the sign. It seems to be interpreting the first bit (which is 1 since the first hex byte is "A") as a negative sign. These two numbers are otherwise the same.

Paste -1346510336 on calc.exe (programmer mode), switch to Hex:

FFFFFFFFAFBDE200

Paste 2948456960, switch to Hex:

AFBDE200

Otávio Décio
  • 73,752
  • 17
  • 161
  • 228