I’m trying to forward port a simple windbg extension to 64 bit but I keep getting 32 bit values back.
E.g. I have this code:
// Get the GDT base address.
ULONG64 lTableBase = g_pExtensionApis->lpGetExpressionRoutine(“@GDTR”);
g_pExtensionApis->lpOutputRoutine(“GDT base = 0x%016x\r\n”, lTableBase);
but I get only the bottom 32 bits of the address that I get when I do “? @GDTR” in windbg connected to a Win 7 x64 box.
I have stuff defined like this
#define KDEXT_64BIT
#include “wdbgexts.h”
PWINDBG_EXTENSION_APIS64 g_pExtensionApis;
EXT_API_VERSION g_ApiVersion = { 3, 5, EXT_API_VERSION_NUMBER64, 0 };
So my initialization function looks like
VOID WDBGAPI WinDbgExtensionDllInit(
PWINDBG_EXTENSION_APIS64 lpExtensionApis,
USHORT usMajorVersion,
USHORT usMinorVersion)
{
// Save the pointers to the callback functions.
g_pExtensionApis = lpExtensionApis;
}
and I’m building from within Visual Studio 2012 with an x64 build and I confirmed a 64 bit binary is getting generated.
Any thoughts on what I’m still missing for moving this over to getting 64 bit values?
tks
JB
OK, I noticed there was a small format string error in that it should have
been 016lx instead of 016x, but that’s not the problem as it’s still only
giving me 32 bits of output.
JB
On Wed, Aug 7, 2013 at 10:54 AM, wrote:
> I’m trying to forward port a simple windbg extension to 64 bit but I keep
> getting 32 bit values back.
>
> E.g. I have this code:
>
> // Get the GDT base address.
> ULONG64 lTableBase = g_pExtensionApis->lpGetExpressionRoutine(“@GDTR”);
> g_pExtensionApis->lpOutputRoutine(“GDT base = 0x%016x\r\n”, lTableBase);
>
> but I get only the bottom 32 bits of the address that I get when I do “?
> @GDTR” in windbg connected to a Win 7 x64 box.
>
> I have stuff defined like this
>
> #define KDEXT_64BIT
> #include “wdbgexts.h”
>
> PWINDBG_EXTENSION_APIS64 g_pExtensionApis;
> EXT_API_VERSION g_ApiVersion = { 3, 5, EXT_API_VERSION_NUMBER64, 0 };
>
> So my initialization function looks like
>
> VOID WDBGAPI WinDbgExtensionDllInit(
> PWINDBG_EXTENSION_APIS64 lpExtensionApis,
> USHORT usMajorVersion,
> USHORT usMinorVersion)
> {
> // Save the pointers to the callback functions.
> g_pExtensionApis = lpExtensionApis;
> }
>
> and I’m building from within Visual Studio 2012 with an x64 build and I
> confirmed a 64 bit binary is getting generated.
>
> Any thoughts on what I’m still missing for moving this over to getting 64
> bit values?
>
> tks
>
> JB
>
> —
> 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
>
I don’t know about windbag extensions but gdtr contains limit (16 bit) and
gdt linear address base (64 bit for long mode).
And lTableBase is only 64 bit so it can’t contain limit and base address.
Maybe that’s the reason
On Wednesday, August 7, 2013, wrote:
I’m trying to forward port a simple windbg extension to 64 bit but I keep
getting 32 bit values back.
E.g. I have this code:
// Get the GDT base address.
ULONG64 lTableBase = g_pExtensionApis->lpGetExpressionRoutine(“@GDTR”);
g_pExtensionApis->lpOutputRoutine(“GDT base = 0x%016x\r\n”, lTableBase);
but I get only the bottom 32 bits of the address that I get when I do “?
@GDTR” in windbg connected to a Win 7 x64 box.
I have stuff defined like this
#define KDEXT_64BIT
#include “wdbgexts.h”
PWINDBG_EXTENSION_APIS64 g_pExtensionApis;
EXT_API_VERSION g_ApiVersion = { 3, 5, EXT_API_VERSION_NUMBER64, 0 };
So my initialization function looks like
VOID WDBGAPI WinDbgExtensionDllInit(
PWINDBG_EXTENSION_APIS64 lpExtensionApis,
USHORT usMajorVersion,
USHORT usMinorVersion)
{
// Save the pointers to the callback functions.
g_pExtensionApis = lpExtensionApis;
}
and I’m building from within Visual Studio 2012 with an x64 build and I
confirmed a 64 bit binary is getting generated.
Any thoughts on what I’m still missing for moving this over to getting 64
bit values?
tks
JB
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 breaks up the true GDTR which is 80 bits, into the “GDTR” which
contains the upper 64 bit base, and the “GDTL” which contains the lower 16
bit limit. So when you ask for @gtrl and @gdtr respectively in windbg they
end up working. And similarly if that were the problem, my old 32 bit code
wouldn’t have worked. Thanks though.
JB
On Wed, Aug 7, 2013 at 11:19 AM, Sergey Pisarev wrote:
> I don’t know about windbag extensions but gdtr contains limit (16 bit) and
> gdt linear address base (64 bit for long mode).
>
> And lTableBase is only 64 bit so it can’t contain limit and base address.
>
> Maybe that’s the reason
>
> On Wednesday, August 7, 2013, wrote:
>
>> I’m trying to forward port a simple windbg extension to 64 bit but I keep
>> getting 32 bit values back.
>>
>> E.g. I have this code:
>>
>> // Get the GDT base address.
>> ULONG64 lTableBase = g_pExtensionApis->lpGetExpressionRoutine(“@GDTR”);
>> g_pExtensionApis->lpOutputRoutine(“GDT base = 0x%016x\r\n”, lTableBase);
>>
>> but I get only the bottom 32 bits of the address that I get when I do “?
>> @GDTR” in windbg connected to a Win 7 x64 box.
>>
>> I have stuff defined like this
>>
>> #define KDEXT_64BIT
>> #include “wdbgexts.h”
>>
>> PWINDBG_EXTENSION_APIS64 g_pExtensionApis;
>> EXT_API_VERSION g_ApiVersion = { 3, 5, EXT_API_VERSION_NUMBER64, 0 };
>>
>> So my initialization function looks like
>>
>> VOID WDBGAPI WinDbgExtensionDllInit(
>> PWINDBG_EXTENSION_APIS64 lpExtensionApis,
>> USHORT usMajorVersion,
>> USHORT usMinorVersion)
>> {
>> // Save the pointers to the callback functions.
>> g_pExtensionApis = lpExtensionApis;
>> }
>>
>> and I’m building from within Visual Studio 2012 with an x64 build and I
>> confirmed a 64 bit binary is getting generated.
>>
>> Any thoughts on what I’m still missing for moving this over to getting 64
>> bit values?
>>
>> tks
>>
>> JB
>>
>> —
>> 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
I use %p to print pointer which is 32-bit for 32-bit target and 64-bit for 64-bit target.
Also: Are you sure that you only get 32-bit value? Maybe it’s the printf problem, not the problem of the interface? What does debugger show after call to g_pExtensionApis->lpGetExpressionRoutine() ?
%p seems to have done the trick. Which is good because I wasn’t looking
forward to debuging my windbg plugin in another instance of windbg 
Thanks!
JB
On Wed, Aug 7, 2013 at 1:07 PM, wrote:
> I use %p to print pointer which is 32-bit for 32-bit target and 64-bit for
> 64-bit target.
> Also: Are you sure that you only get 32-bit value? Maybe it’s the printf
> problem, not the problem of the interface? What does debugger show after
> call to g_pExtensionApis->lpGetExpressionRoutine() ?
>
>
> —
> 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
>
> I wasn’t looking forward to debuging my windbg plugin in another instance of windbg
While this is indeed possible (and the debugger-Windbg even gets symbols from debugee-Windbg), I find it far more comfortable to debug the extension directly in Visual Studio.