Hi,
I am new to windbg scripting; Could you please advise if it is possible to fetch details of the suspected module resulted from !analyze -v cmd in windbg script.
I mean-
when we execute !naalyze -v cmd in output we get-
MODULE_NAME: ****
and windbg provides the link on this name which gives us further details on MODULE_NAME.
Is this MODULE_NAME associated to any variable which i can use in script as-
lmv m $modulename -> lmv m ****
Your help is much appreciated.
Thanks in advance!!!
wrote in message news:xxxxx@windbg…
> Hi,
>
> I am new to windbg scripting; Could you please advise if it is possible to
> fetch details of the suspected module resulted from !analyze -v cmd in
> windbg script.
> I mean-
> when we execute !naalyze -v cmd in output we get-
> MODULE_NAME:
> and windbg provides the link on this name which gives us further details
> on MODULE_NAME.
>
> Is this MODULE_NAME associated to any variable which i can use in script
> as-
> lmv m $modulename -> lmv m
>
> Your help is much appreciated.
> Thanks in advance!!!
Yes, in a sense. You can stream the !analyze output to external
program/script which will create a windbg script file, then execute this
file.
If you are familiar with windbg extension DLLs, it is possible to wrap all
the above into an extension command.
–pa
On Fri, Jul 1, 2011 at 12:16 PM, Pavel A. wrote:
> Yes, in a sense. You can stream the !analyze output to external
> program/script which will create a windbg script file, then execute this
> file.
> If you are familiar with windbg extension DLLs, it is possible to wrap all
> the above into an extension command.
You can probably employ .foreach token to do that.
Kris
Many Thanks for your reply Kris!
I can read the output of windbg logfile and run the lmvm cmd after fetching the module name using perl or python… but i do not want to reinitiate the windbg session…i wanty to get the details in same session…
I am sorry but with .foreach wouldn’t i get details of all the modules… Sorry if i am being stupid here…
If possible could you elaborate which token i can use to get details?
Is there any variable associated to it?
Thanks Again!!!
Why to reinitiate windbg session?
You use .shell -ci “!analyze -v” perl your-script.pl
then, assuming the script creates file dbgcmd: $$>< dbgcmd
–pa
On Mon, Jul 4, 2011 at 3:40 PM, wrote:
> I am sorry but with .foreach wouldn’t i get details of all the modules… Sorry if i am being stupid here…
> If possible could you elaborate which token i can use to get details?
.foreach tokenizes the output of given command(s), so theoretically
you should be able to do something like this:
r$t0=0;.foreach (tok { !analyze -v }) { .if (@$t0==1) { aS
${/v:bcModuleName} ${tok}; .break } .elsif ($spat(“${tok}”,
“MODULE_NAME:”)) { r$t0=1; } }
It should create ${bcModuleName} alias which contains module name:
.echo ${bcModuleName}
Now the problem is that, for some unknown reason, part of the !analyze
output is not processed by .foreach command (at least when I tried it
with KD and WinDBG).
“.shell -ci” approach didn’t work for me neither - same problem - only
part of !analyze -v output was streamed to my python script.
Kris
“Krzysztof Uchronski” wrote in message news:xxxxx@windbg…
Now the problem is that, for some unknown reason, part of the !analyze
output is not processed by .foreach command
Weird, I see the same thing:
kd> .foreach (tok { !analyze -D MODULE_NAME}) { .echo Foo token!}
MODULE_NAME: hdlock
Seems to be anything in the secondary part of the analysis that doesn’t get
sent to the same output (i.e. anything listed after, “Debugging Details”)
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
On Mon, Jul 4, 2011 at 3:40 PM, wrote:
> I am sorry but with .foreach wouldn’t i get details of all the modules…
> Sorry if i am being stupid here…
> If possible could you elaborate which token i can use to get details?
.foreach tokenizes the output of given command(s), so theoretically
you should be able to do something like this:
r$t0=0;.foreach (tok { !analyze -v }) { .if (@$t0==1) { aS
${/v:bcModuleName} ${tok}; .break } .elsif ($spat(“${tok}”,
“MODULE_NAME:”)) { r$t0=1; } }
It should create ${bcModuleName} alias which contains module name:
.echo ${bcModuleName}
Now the problem is that, for some unknown reason, part of the !analyze
output is not processed by .foreach command (at least when I tried it
with KD and WinDBG).
“.shell -ci” approach didn’t work for me neither - same problem - only
part of !analyze -v output was streamed to my python script.
Kris
I concur that this approach should work.
That being said, it has been my experience that going the extension route
never disappoints, at least as compared to the script route, if for no other
reason than that Windbg’s script syntax is just so unreasonable.
Extensions, on the other hand (all in my opinion, of course) rock.
Tremendously powerful. Even if you don’t need one for this (not that this
approach is necessarily a bad one - if it works, it works), getting familiar
with extensions is a great thing to do.
If you do go the extension route, I’d highly recommend the EngExtCpp
interface.
Good luck,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Friday, July 15, 2011 3:28 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] WINDBG SCRPTING- lmvm -Module name
“Krzysztof Uchronski” wrote in message news:xxxxx@windbg…
Now the problem is that, for some unknown reason, part of the !analyze
output is not processed by .foreach command
Weird, I see the same thing:
kd> .foreach (tok { !analyze -D MODULE_NAME}) { .echo Foo token!}
MODULE_NAME: hdlock
Seems to be anything in the secondary part of the analysis that doesn’t get
sent to the same output (i.e. anything listed after, “Debugging Details”)
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst OSR Open Systems
Resources, Inc.
http://www.osronline.com
On Mon, Jul 4, 2011 at 3:40 PM, wrote:
> I am sorry but with .foreach wouldn’t i get details of all the modules…
> Sorry if i am being stupid here…
> If possible could you elaborate which token i can use to get details?
.foreach tokenizes the output of given command(s), so theoretically you
should be able to do something like this:
r$t0=0;.foreach (tok { !analyze -v }) { .if (@$t0==1) { aS
${/v:bcModuleName} ${tok}; .break } .elsif ($spat(“${tok}”,
“MODULE_NAME:”)) { r$t0=1; } }
It should create ${bcModuleName} alias which contains module name:
.echo ${bcModuleName}
Now the problem is that, for some unknown reason, part of the !analyze
output is not processed by .foreach command (at least when I tried it with
KD and WinDBG).
“.shell -ci” approach didn’t work for me neither - same problem - only part
of !analyze -v output was streamed to my python script.
Kris
—
WINDBG is sponsored by OSR
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
On Fri, Jul 15, 2011 at 8:31 PM, M. M. O’Brien
wrote:
> That being said, it has been my experience that going the extension route
> never disappoints, at least as compared to the script route,
Funny you said that. I just did quick test with !analyze and output
callbacks and it seems to be working just fine.
> if for no other
> reason than that ?Windbg’s script syntax is just so unreasonable.
I completely agree that with extensions you have much more control
over what you’re doing. However I found dbg scripting quite rewarding
when I have to do something quickly. It’s also good for illustrating
some techniques.
Kris
Whatever works for you.
Mm
On Jul 15, 2011 6:40 PM, “Krzysztof Uchronski” wrote:
> On Fri, Jul 15, 2011 at 8:31 PM, M. M. O’Brien
> wrote:
>> That being said, it has been my experience that going the extension route
>> never disappoints, at least as compared to the script route,
> Funny you said that. I just did quick test with !analyze and output
> callbacks and it seems to be working just fine.
>
>> if for no other
>> reason than that Windbg’s script syntax is just so unreasonable.
> I completely agree that with extensions you have much more control
> over what you’re doing. However I found dbg scripting quite rewarding
> when I have to do something quickly. It’s also good for illustrating
> some techniques.
>
> Kris
>
> —
> WINDBG is sponsored by OSR
>
> 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
for some weird reason the tempfile that gets written which feeds the
CbreaderThread
gets only data upto DEBUGGING DETAILS:_______________________
after that all the data is transferred to windbg ui instead of file
so scripting fails is what i noticed some time back when
i tried tracing exts.analyze function then
but execution jumps between threads and i couldnt spare much time
the problem seems to located between here
0165D348 025D650C Arg1 = 025D650C ASCII “nt!_KiDoubleFaultStack”
0165D428 026B9A63 ext.026E1EC2
ext.026B9A61
0165D424
0165D5D4 026B6F37 ext.026B9842
ext.026B6F35
0165D5D0
0165D5F8 026E018A ext.026B6E10
ext.026E0185
0165D5F4
0165D63C 026CAA72 ext.026DFF62
ext.026CAA70
0165D638
0165D694 026DCE78 ext.026CA990
ext.026DCE76
0165D690
0165D968 026DD543 ? ext.026DBB80
ext.026DD53E
0165D964
0165D9A4 026DD7DF ext.026DD480
ext.026DD7DA
0165D9A0
0165DA40 026B0708 ext.026DD590
ext.026B0703
0165DA3C
0165DA44 0165DB50 Arg1 = 0165DB50 ASCII “-v”
0165DA74 0218CB52 Maybe ext.026B0503
dbgeng.ExtensionInfo::CallA+33F
0165DA70
0165DB14 0218CDA9 ? dbgeng.ExtensionInfo::CallA
dbgeng.0218CDA4
0165DB10
and this not only happens for !analyze iirc it happens for some other
functions too
On 7/16/11, Scott Noone wrote:
> “Krzysztof Uchronski” wrote in message news:xxxxx@windbg…
>>Now the problem is that, for some unknown reason, part of the !analyze
>>output is not processed by .foreach command
>
> Weird, I see the same thing:
>
> kd> .foreach (tok { !analyze -D MODULE_NAME}) { .echo Foo token!}
>
> MODULE_NAME: hdlock
>
> Seems to be anything in the secondary part of the analysis that doesn’t get
> sent to the same output (i.e. anything listed after, “Debugging Details”)
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> On Mon, Jul 4, 2011 at 3:40 PM, wrote:
>> I am sorry but with .foreach wouldn’t i get details of all the modules…
>> Sorry if i am being stupid here…
>> If possible could you elaborate which token i can use to get details?
>
> .foreach tokenizes the output of given command(s), so theoretically
> you should be able to do something like this:
> r$t0=0;.foreach (tok { !analyze -v }) { .if (@$t0==1) { aS
> ${/v:bcModuleName} ${tok}; .break } .elsif ($spat(“${tok}”,
> “MODULE_NAME:”)) { r$t0=1; } }
> It should create ${bcModuleName} alias which contains module name:
> .echo ${bcModuleName}
>
> Now the problem is that, for some unknown reason, part of the !analyze
> output is not processed by .foreach command (at least when I tried it
> with KD and WinDBG).
> “.shell -ci” approach didn’t work for me neither - same problem - only
> part of !analyze -v output was streamed to my python script.
>
> Kris
>
>
> —
> WINDBG is sponsored by OSR
>
> 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
>
–
thanks and regards
raj_r
Try to use python. RE is more-more conviniant, that windbg tokenizer.
To install python extension, go to pykd.codeplex.com
This is a sample parsing dbg command’s output by RE. Output is a python object representing module.
1: kd> !pycmd
>>import re
>>cmdstr = dbgCommand( “!analyze -v” )
>>moduleStr = re.search( r"MODULE_NAME:\s+(\w+)", cmdstr ).group(1)
>>moduleObj = loadModule( moduleStr )
>>print moduleObj
fffff8800718a000 0000000000043000
Yoy can do it by stand-alone script and run it as:
1: kd>!py parse
fffff8800718a000 0000000000043000
1: kd>
For getting help for pykd do:
Thanks everyone… probably i need to parse the stored output of analyze -v…
moving onto python would be difficult for me at this stage… 