Following is giving me a syntax error:
kd> .call /v nvnwbx32!EVENTLOG_ReadEventCancelRoutine(this,0x6caaeca0)
^
Syntax error in ‘.call /v
nvnwbx32!EVENTLOG_ReadEventCancelRoutine(this,0x6caaeca0)’
Any idea what is it that I am doing wrong?
Thanks,
-Praveen
On 11/23/06, Praveen Kumar Amritaluru wrote:
>
> Following is giving me a syntax error:
>
> kd> .call /v nvnwbx32!EVENTLOG_ReadEventCancelRoutine(this,0x6caaeca0)
> ^
> Syntax error in ‘.call /v
> nvnwbx32!EVENTLOG_ReadEventCancelRoutine(this,0x6caaeca0)’
first of all .call is applicable in user mode only its not intended for kd
from help file
second i have tried it several times and it never seemed to work for me
it always spat out not a function some thing and i thought i might be doing
some thing wrong as i havent
encountered anyone asking about it in these lists or in google groups
like this
ntdll!DbgBreakPoint:
7c901230 cc int 3
0:001> .call user32!MessageBoxA( 0,0,0,0)
^ Symbol not a function in ‘.call
user32!MessageBoxA( 0,0,0,0)’
0:001> x user32!MessageBoxExA
77d8057d user32!MessageBoxExA =
0:001> x user32!MessageBoxA
77d8050b user32!MessageBoxA =
0:001> .call 77d8050b( 0,0,0,0)
^ Symbol not a function in ‘.call 77d8050b( 0,0,0,0)’
0:001> .call /v 77d8050b( 0,0,0,0)
^ Symbol not a function in ‘.call /v 77d8050b(
0,0,0,0)’
0:001> .call /v 0x77d8050b( 0,0,0,0)
^ Symbol not a function in ‘.call /v 0x77d8050b(
0,0,0,0)’
0:001> .call /v 0x77d8050b ( 0,0,0,0)
^ Symbol not a function in ‘.call /v 0x77d8050b (
0,0,0,0)’
0:001> .call /v eip ( 0,0,0,0)
^ Symbol not a function in ‘.call /v eip ( 0,0,0,0)’
maybe im doing some thing wrong may be its broken
ive used the equivalent functionality in gdb several times and it never had
any problems there
a sample
Breakpoint 1, 0x08048372 in main ()
(gdb) x/i $eip
0x8048372 : and $0xfffffff0,%esp
(gdb) set di i
(gdb) x/i $eip
0x8048372 : and esp,0xfffffff0
(gdb) help call
Call a function in the program.
The argument is the function name and arguments, in the notation of the
current working language. The result is printed and saved in the value
history, if it is not void.
(gdb) call printf(“hello this is a call test from gdb”)
$1 = 34
(gdb) call strlen(“hello this is a call test from gdb”)
$2 = 34
(gdb)
maybe someone else could shed some light on this
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
"raj_r" wrote in message news:xxxxx@windbg...
On 11/23/06, Praveen Kumar Amritaluru wrote:
Following is giving me a syntax error:
kd> .call /v nvnwbx32!EVENTLOG_ReadEventCancelRoutine(this,0x6caaeca0)
^
Syntax error in '.call /v
nvnwbx32!EVENTLOG_ReadEventCancelRoutine(this,0x6caaeca0)'
first of all .call is applicable in user mode only its not intended for kd from help file
second i have tried it several times and it never seemed to work for me
it always spat out not a function some thing and i thought i might be doing some thing wrong as i havent
encountered anyone asking about it in these lists or in google groups
like this
ntdll!DbgBreakPoint:
7c901230 cc int 3
0:001> .call user32!MessageBoxA( 0,0,0,0)
^ Symbol not a function in '.call user32!MessageBoxA( 0,0,0,0)'
0:001> x user32!MessageBoxExA
77d8057d user32!MessageBoxExA =
0:001> x user32!MessageBoxA
77d8050b user32!MessageBoxA =
0:001> .call 77d8050b( 0,0,0,0)
^ Symbol not a function in '.call 77d8050b( 0,0,0,0)'
0:001> .call /v 77d8050b( 0,0,0,0)
^ Symbol not a function in '.call /v 77d8050b( 0,0,0,0)'
0:001> .call /v 0x77d8050b( 0,0,0,0)
^ Symbol not a function in '.call /v 0x77d8050b( 0,0,0,0)'
0:001> .call /v 0x77d8050b ( 0,0,0,0)
^ Symbol not a function in '.call /v 0x77d8050b ( 0,0,0,0)'
0:001> .call /v eip ( 0,0,0,0)
^ Symbol not a function in '.call /v eip ( 0,0,0,0)'
maybe im doing some thing wrong may be its broken
ive used the equivalent functionality in gdb several times and it never had any problems there
a sample
Breakpoint 1, 0x08048372 in main ()
(gdb) x/i $eip
0x8048372 : and $0xfffffff0,%esp
(gdb) set di i
(gdb) x/i $eip
0x8048372 : and esp,0xfffffff0
(gdb) help call
Call a function in the program.
The argument is the function name and arguments, in the notation of the
current working language. The result is printed and saved in the value
history, if it is not void.
(gdb) call printf("hello this is a call test from gdb")
$1 = 34
(gdb) call strlen("hello this is a call test from gdb")
$2 = 34
(gdb)
maybe someone else could shed some light on this
On 11/24/06, Skywing wrote:
> You need to have the private .pdb in order to use `.call’; the public
> (stripped) pdbs do not include things like argument or calling convention
> information in general. This effectively just limits it to programs that
> you compile… Failing that, you could try something like sdbgext’s
> !remotecall (which lets you manually provide calling convention and argument
> information) -
> http://www.valhallalegends.com/skywing/files/sdbgext/sdbgext.zip (VC8 CRT
> required for use, and only supports x86 targets).
> –
>
Thanks SkyWing for the heads up, i was wanting to call some antidebug
routines in place
effectively something like the infamous IsDebuggerPresent() or ZwQuery
variations sometimes and it failed so your point about having private pdbs
do clarify certain limitations
I have used your sdbgexts once while enumerating the !Hwnd comparison of
ollydbg to your output on a gui
actually i wanted to try and import a memory dump of drivers map from ida to
windbg thats when i encountered your sdbgexts but it was not able to to do
it could you clarify if sdbgext is able to import idas map (especially
.writemem dump of some boot loading driver before
IopInitializeBuiltinDriver -> but after its relocated to 0xffff range from
0x8010### range
Thanks and Regards
raj_r
Yes, you should be able to import the .map file that IDA generates from a PE file. That was the primary motivation for that extension, in fact; to allow you to synchronize symbols you name in IDA with the debugger. It should work for both usermode and kernelmode targets. The extension is however limited to just x86 targets in some configurations right now due to the way that it traverses the loaded module list in the target. Specifically, if you don’t give !loadsym or !unloadsym a full path to the module (which you need to do for kernel mode targets, in general, so this does not really apply to you), then sdbgext will try to fetch the module filename from the remote system’s loaded module list, and currently sdbgext only knows how to understand an x86-style loaded module list.
As previously alluded to, you’ll need to give !loadsym a local path (i.e. something the machine running WinDbg can access) to the .sys file for a kernel target though, as right now it needs to be able to open the PE file locally in order to get information about the image section offsets. The extension does not run any code from the binary (just maps it with SEC_IMAGE and fishes out the section headers from the in-memory PE image).
Also, if you are trying to name memory that isn’t associated with an entry in the loaded module list, you will need to supply a debugger-machine-relative path to the binary in question, or sdbgext will try (and fail) to get a filename from the loaded module list in the target.
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“raj_r” wrote in message news:xxxxx@windbg…
On 11/24/06, Skywing wrote:
You need to have the private .pdb in order to use `.call’; the public (stripped) pdbs do not include things like argument or calling convention information in general. This effectively just limits it to programs that you compile… Failing that, you could try something like sdbgext’s !remotecall (which lets you manually provide calling convention and argument information) - http://www.valhallalegends.com/skywing/files/sdbgext/sdbgext.zip (VC8 CRT required for use, and only supports x86 targets).
–
Thanks SkyWing for the heads up, i was wanting to call some antidebug routines in place
effectively something like the infamous IsDebuggerPresent() or ZwQuery variations sometimes and it failed so your point about having private pdbs do clarify certain limitations
I have used your sdbgexts once while enumerating the !Hwnd comparison of ollydbg to your output on a gui
actually i wanted to try and import a memory dump of drivers map from ida to windbg thats when i encountered your sdbgexts but it was not able to to do it could you clarify if sdbgext is able to import idas map (especially .writemem dump of some boot loading driver before IopInitializeBuiltinDriver -> but after its relocated to 0xffff range from 0x8010### range
Thanks and Regards
raj_r
On 11/25/06, Skywing wrote:
>
> Yes, you should be able to import the .map file that IDA generates from a
> PE file. That was the primary motivation for that extension, in fact; to
> allow you to synchronize symbols you name in IDA with the debugger. It
> should work for both usermode and kernelmode targets. The extension is
> however limited to just x86 targets in some configurations right now due to
> the way that it traverses the loaded module list in the target.
> Specifically, if you don’t give !loadsym or !unloadsym a full path to the
> module (which you need to do for kernel mode targets, in general, so this
> does not really apply to you), then sdbgext will try to fetch the module
> filename from the remote system’s loaded module list, and currently sdbgext
> only knows how to understand an x86-style loaded module list.
>
> As previously alluded to, you’ll need to give !loadsym a local path (i.e.
> something the machine running WinDbg can access) to the .sys file for a
> kernel target though, as right now it needs to be able to open the PE file
> locally in order to get information about the image section offsets. The
> extension does not run any code from the binary (just maps it with SEC_IMAGE
> and fishes out the section headers from the in-memory PE image).
>
> Also, if you are trying to name memory that isn’t associated with an entry
> in the loaded module list, you will need to supply a
> debugger-machine-relative path to the binary in question, or sdbgext will
> try (and fail) to get a filename from the loaded module list in the target.
>
>
> –
>
> Ken Johnson (Skywing)
> Windows SDK MVP
> http://www.nynaeve.net
>
Thanks Skywing for Replying back and sorry to the o/p for hijacking this
thread
since my answer would in no way be related to either the topic or windbg in
general i replied back to
you offline hope you could find a few minutes to go through the ramblings
Thanks and Regards
raj_r