Diskrepanz in! Objsize in hexadezimal und dezimal

Question

Ich verwende ! Objsize Befehl, um den wahren Wert eines Objekts zu erhalten. Zum Beispiel, wenn ich den Befehl unten ausführe, sagt es mir, dass die Größe des Objekts bei der Adresse 00000003a275f218 18 hex ist, was 24 in dezimal übersetzt.

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

So weit so gut. Ich führe denselben Befehl für ein Objekt aus und seine Größe scheint eine Diskrepanz zwischen hex und dezimal zu haben.

Also die Größe in Hex ist 0xafbde200. Wenn ich es mit meinem calc in dezimal umwandle, ist das , während die Ausgabe des Befehls die dezimale Größe -1346510336 anzeigt. Kann mir jemand helfen zu verstehen, warum es Unterschiede in den Größen gibt?

Answer 1

Es ist ein Fehler in SOS . Wenn man sich die source code anschauen, werden Sie die Methode deklariert finden als

DECLARE_API(ObjSize) 

Es wird folgendes Format als Ausgabe verwendet

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

Wie Sie sehen, es %d als Formatbezeichner verwendet, das ist für vorzeichenbehaftete Dezimalzahlen. Das sollte %u anstelle von Ganzzahlen ohne Vorzeichen sein, da Sie offensichtlich keine Objekte mit einer negativen Speichermenge verwenden können.

Wenn Sie wissen, wie Sie Git verwenden, können Sie einen Patch bereitstellen.

können Sie ? in WinDbg verwenden Sie den Wert ohne Vorzeichen zu sehen:

0:000> ? 0xafbde200 
Evaluate expression: 2948456960 = 00000000`afbde200 

Answer 2

Unterschied ist das Zeichen. Es scheint das erste Bit (das ist 1, da das erste Hexadezimalbyte "A" ist) als negatives Vorzeichen zu interpretieren. Diese beiden Zahlen sind ansonsten gleich.

Paste -1346510336 auf calc.exe (Programmiermodus), umschalten auf Hex:

FFFFFFFFAFBDE200

Paste 2948456960, wechseln Sie zu Hex:

AFBDE200