I am trying to write a windbg extension dll. I compile it as a 64bit dll
and debugging it by loading the extension in one instance of 64bit windbg and
debugging the extension code itself in a second instance of windbg by
attaching it to the first instance of windbg.
The problem I am facing is if I issue an extension implemented command in
first instance of windbg with an argument, I get the call to my extension
code but the arguments received like *dwProcessor, etc *have nonsensical
values and*args* has a memory access error. (I am using DECLARE_API to
declare my extension commands).
If I do the above with my extension compiled as 32bit dll and load it in a
32bit windbg then everything works as its supposed to. I get the argument
string passed with the command in *args.*
I am using visual studio 2013 professional and windows 8.1 sdk to compile
the extension.
Seems like 64bit windbg is not calling the extension command correctly but
32bit windbg is.
Got the answer problem fixed! DELCARE_API extension function declaration
emits a different function signature than the expected by the 64bit engine
I guess. Correct function signature to use is *PDEBUG_EXTENSION_CALL. *
Regards
Sanjeev
On Fri, Oct 16, 2015 at 6:34 PM, sanjeev wrote:
> Hi All > > I am trying to write a windbg extension dll. I compile it as a 64bit dll > and debugging it by loading the extension in one instance of 64bit windbg and > debugging the extension code itself in a second instance of windbg by > attaching it to the first instance of windbg. > > The problem I am facing is if I issue an extension implemented command in > first instance of windbg with an argument, I get the call to my extension > code but the arguments received like dwProcessor, etc have nonsensical > values andargs has a memory access error. (I am using DECLARE_API to > declare my extension commands). > > If I do the above with my extension compiled as 32bit dll and load it in a > 32bit windbg then everything works as its supposed to. I get the argument > string passed with the command in args. > > I am using visual studio 2013 professional and windows 8.1 sdk to compile > the extension. > > Seems like 64bit windbg is not calling the extension command correctly > but 32bit windbg is. > > Any idea about what could be going wrong? > > Thank you. > Sanjeev >
DECLARE_API is wdbgexts it is kinda ooolld you should be mucking with
either dbgeng or engextcpp
by the way DECLARE_API becomes DECLARE_API64 if KDEXT_64BIT is defined
the dwCurrentpc will be either either ULONG or ULONG64
On 10/16/15, sanjeev wrote: > Got the answer problem fixed! DELCARE_API extension function declaration > emits a different function signature than the expected by the 64bit engine > I guess. Correct function signature to use is *PDEBUG_EXTENSION_CALL. * > > Regards > Sanjeev > > On Fri, Oct 16, 2015 at 6:34 PM, sanjeev wrote: > >> Hi All >> >> I am trying to write a windbg extension dll. I compile it as a 64bit dll >> and debugging it by loading the extension in one instance of 64bit windbg >> and >> debugging the extension code itself in a second instance of windbg by >> attaching it to the first instance of windbg. >> >> The problem I am facing is if I issue an extension implemented command in >> first instance of windbg with an argument, I get the call to my extension >> code but the arguments received like dwProcessor, etc have nonsensical >> values andargs has a memory access error. (I am using DECLARE_API to >> declare my extension commands). >> >> If I do the above with my extension compiled as 32bit dll and load it in >> a >> 32bit windbg then everything works as its supposed to. I get the argument >> string passed with the command in args. >> >> I am using visual studio 2013 professional and windows 8.1 sdk to compile >> the extension. >> >> Seems like 64bit windbg is not calling the extension command correctly >> but 32bit windbg is. >> >> Any idea about what could be going wrong? >> >> Thank you. >> Sanjeev >> > > — > 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