1

I would like to create a script in windbg that sets a breakpoint in System.Windows.Forms.Application+MarshalingControl..ctor and when that breakpoint is being hit, it just dumps the stack trace into a log file that i open.

I'm using the sos extension's !Name2EE command to get the JITTED code address, but i still don't have a way to get the exact address from what is being returned:

.block{.shell -ci "!Name2EE *!System.Windows.Forms.Application+MarshalingControl..ctor" FIND "JITTED Code Address:"}

but this returns: JITTED Code Address: 63348434 Where i would like to get only the address number itself.

Any suggestions?

Ziv
  • 13
  • 2
  • want some hack on hack try this :) 0:004> .shell -ci "!Name2EE * Console.WriteLine" grep J | head -n 2 JITTED Code Address: 5cc859ac JITTED Code Address: 5d2e52f4 .shell: Process exited 0:004> .shell -ci "!Name2EE * Console.WriteLine" grep J | head -n 2 | awk "{print $4}" 5cc859ac 5d2e52f4 .shell: Process exited – blabb Jul 05 '16 at 07:26

1 Answers1

0

Getting the jitted address

You can surround that by a .foreach which eats the words JITTED Code Address: by using /pS 3 (initial skip) and eats .shell: Process exited by /ps 3 (skip):

I tried with

0:000> .foreach /pS 3 /ps 3 (var {.shell -ci ".echo JITTED Code Address: 63348434" FIND "JITTED Code Address:"}) {.echo ${var}}
63348434

You should use

.block{.foreach /pS 3 /ps 3(var {.shell -ci "!Name2EE *!System.Windows.Forms.Application+MarshalingControl..ctor" FIND "JITTED Code Address:"}) {.echo ${var}}}

and then change .echo ${var} to whatever you like to do with the address.

Be aware of edge cases: the method may not have been jitted yet.

Managed breakpoint

I wonder a bit why you want to put a breakpoint at the jitted address and why a managed breakpoint does not work for you. Have you tried !mbm and !mbp?

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • Related if `!mbm` does not work: http://stackoverflow.com/questions/11768921/breakpoint-set-by-sosex-mbp-or-sosex-mbm-not-working – Thomas Weller Jul 05 '16 at 09:15
  • Thanks Thomas! You're suggestion worked. I'm still new with WinDBG's options - so didn't even know sosex exists. By the way, is there an option to run WinDBG in sort of a silent mode? let it just run a script without opening the WinDBG's UI? – Ziv Jul 07 '16 at 06:01
  • @Ziv: There's `cdb`, the console debugger. If you add a statement like `q` at the end of your script, it should exit automatically. Still possible it opens a console window. – Thomas Weller Jul 07 '16 at 06:08