Unable to debug DynamoRIO with WinDbg

[phil.b...@gmail.com]

Hello,

I have a hard time debugging a recent version of DynamoRIO with WinDbg, i.e., 8.0.18663 on Windows 10 20H2 (build 19042.746). No dynamo_auto_start breakpoint is hit on x64, and I have access violations with WoW64. Are the debugging instructions at the Wiki up to date? What I did is:

<start WinDbg x64 with C:\dynamorio\bin64\drrun.exe -- notepad.exe>

0:004> .childdbg 1

0:004> g

<at start of notepad.exe>

1:004> bp dynamo_auto_start

Bp expression 'dynamo_auto_start' could not be resolved, adding deferred bp

*** Bp expression 'dynamo_auto_start' contains symbols not qualified with module name.

g

<notepad.exe runs normally, no breakpoint is hit>

On WoW64, I even get access violation:

<start WinDbg x86 with C:\dynamorio\bin32\drrun.exe -- hello_world32.exe>

0:004> .childdbg 1

0:004> g

<at start of hello_world32.exe>

1:004> bp dynamo_auto_start

Bp expression 'dynamo_auto_start' could not be resolved, adding deferred bp

*** Bp expression 'dynamo_auto_start' contains symbols not qualified with module name.

1:004> g

*** Unable to resolve unqualified symbol in Bp expression 'dynamo_auto_start' from module 'C:\WINDOWS\SysWOW64\kernel.appcore.dll'.

ModLoad: 75490000 7549f000   C:\WINDOWS\SysWOW64\kernel.appcore.dll

(4ee8.46f4): Access violation - code c0000005 (first chance)

If instead I use bp dynamorio!dynamo_auto_start, there is a different failure:

<start WinDbg x86 with C:\dynamorio\bin32\drrun.exe -- hello_world32.exe>

0:000> bp dynamorio!dynamo_auto_start

Bp expression 'dynamorio!dynamo_auto_start' could not be resolved, adding deferred bp

0:000> .childdbg 1

Processes created by the current process will be debugged

0:000> g

ModLoad: 7bdb0000 7bdb0000   dynamorio.dll

Unable to insert breakpoint 0 at 7be31610, Win32 error 0n299

    "Only part of a ReadProcessMemory or WriteProcessMemory request was completed."

bp0 at 7be31610 failed

WaitForEvent failed

eax=00000000 ebx=00000001 ecx=00000000 edx=00000000 esi=77723be0 edi=00000000

eip=777218ac esp=009fc6a8 ebp=009fce38 iopl=0         nv up ei pl nz na po nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202

ntdll!NtMapViewOfSection+0xc:

777218ac c22800          ret     28h

In the past (some 7.x version) I was able to use set a breakpoint like that and step through DynamoRIO.

Any guidance?

[Derek Bruening]

https://github.com/DynamoRIO/dynamorio/commit/9ce2418a168e9d406f36929f549ad43f7ae25470 changed the default Windows injection to map DR from the parent, so the load_dynamo and dynamo_auto_start code is no longer used, and the DR library is not loaded by the system loader.

What is the goal here: to debug a client?  Are the -msgbox_mask later attach points undesirable in your use case?

Breaking at the very first DR instruction requires locating the gencode which is most easily done from the parent.  We could create some instructions if there are people debugging DR itself.

Re: access violations: this comes up many times on this list on all platforms: an access violation, segmentation fault, bus error, etc. is *not* always an indication of a fatal error and is sometimes expected.  DR deliberately has safe_read and other mechanisms of dereferencing untrusted application addresses which incur a fault and recover.  So simply the fact that you saw an access violation is not enough information.

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/23de2bad-72ab-46a1-92cd-8e0d5eda592fn%40googlegroups.com.

[Derek Bruening]

Something like this will arrive at the first library code executed by DR, after the short gencode.  The way to avoid hardcoding the path is to use our convenience scripts after DR is further initialized as described on the wiki. 

.childdbg 1

bp drinjectlib!inject_gencode_mapped_helper

g

gu

r $t0=poi(map)

g

.sympath d:\path\to\lib64\debug

.reload dynamorio.dll=@$t0

bp dynamorio!dynamorio_earliest_init_takeover

g

[phil.b...@gmail.com]

Thank you very much for the instructions; your explanation about the changed injection makes perfect sense to me. My goal is indeed to debug DynamoRIO itself as a way to learn more about it. In the past, I was debugging https://github.com/DynamoRIO/dynamorio/issues/4130 and it taught me a lot.

You are absolutely right about the access violation.