Unable to inject

[Manish Arora]

Hi Folks

I am trying to use drinject to launch an executable (PCMark 7) under a memtrace tracing tool. I am able to run calc under the same tool and using the same launch mechanism but this particular binary does not seem to run under the tool. 

1) img1 shows the command lines used.

2) Actually when I use drinject as shown in figure 2, a new process is launched but i get an error message as shown and tracing does not work.

Any ideas what may be going wrong?

thanks

Manish

[Qin Zhao]

for Q1, I thought drconfig.exe is only for registering an application to make DR inject it when it runs, but won't start the application. As shown in your img1, it is registered, but not started.

for Q2, is PCMark7 a 64-bit app? The error usually means cannot find the config file for that application for some reason, e.g. 64-bit app but the config file is for 32-bit app.

Manish

--
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 post to this group, send email to dynamor...@googlegroups.com.
Visit this group at http://groups.google.com/group/dynamorio-users.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Interested in Yoga? Be careful of The Yoga Cult or The Scary Yoga Obsession.

More information from  Lorie Anderson and Rick Ross.

[Derek Bruening]

If you take a recent build from http://build.chromium.org/p/client.dynamorio/builds/ you'll get "ERROR: Target process c:\src\dr\test\hello64.exe is for the wrong architecture" on a mismatch.

If that's not the problem, you want to run a debug version of drinject or drrun to get diagnostics on the point of failure.  Unfortunately, currently only the release build is in the exported package so you'd need to build from sources.

[Manish Arora]

Hi Derek

1) I checked the executable using dumpbin and it is a 32bit binary. Using the latest version as suggested by you gives me the wrong architecture error whe using 64 bit drrun/config/inject, so its not a target mismatch.

2) After spending a day or so, I was able to build the 32 bit debug version and produce error logs. Here is what I get when using drrun.exe (same errors using drconfig and drinject):

I get 3 windows popup messages:

Warning: could not read image name from PEB.

Warning: This application is not configured to to run under Dynamorio! Use drconfig.exe or drrun.exe to configure.

GetThreadContext failed

Any ideas why this may be happening?

regards

Manish

[Derek Bruening]

On Mon, Jul 15, 2013 at 10:47 PM, Manish Arora <mar...@eng.ucsd.edu> wrote:

I get 3 windows popup messages:

Warning: could not read image name from PEB.

Warning: This application is not configured to to run under Dynamorio! Use drconfig.exe or drrun.exe to configure.

GetThreadContext failed

Step through in windbg and get the NTSTATUS error codes from NtReadVirtualMemory failure (1st warning) and NtGetTContexthread failure (final error).

[Manish Arora]

Hi Derek

I am having trouble setting up windbg to run with drrun.exe. Do you have any scripts/workspace I can use to help with the windbg setup?

1) Cap1, Cap2 and Cap3 show my symbol search, source search and command lines used.

2) Cap4 shows that I set breakpoints on main using bp and checked them using bl. They seem to be set but when I run the program using g, neither does it break at main, nor do the sources show up. Instead it throws the Warning as shown meaning that execution has gone past main.

Any ideas what I might be doing wrong with windbg?

regards

Manish

[Manish Arora]

Hi Derek

I noticed that you have provided some windbg instructions at https://code.google.com/p/dynamorio/wiki/Debugging#Debugging_Tips.

1) I launched windbg from the command like using the -pt 1 -c "$><C:\Users\Administrator\Desktop\dynamorio\tools\windbg-scripts\load_syms64" line. I get an error on the script as shown in the attached file cap5. 

2) Next I followed the sequence of commands > .childdbg 1, g, l+t and so forth but get errors as shown in the attached figure.

I am using windbg 6.12.0002.633 AMD64 on a win7 64 bit system. Any ideas?

regards

Manish

[Derek Bruening]

You're debugging the launching program drrun.exe, not an app under DR, so you don't want a load_syms script.  This is a regular app.  Use the Visual Studio debugger if you know that better.  But, you need to build with symbols: "image000..." instead of "drrun.exe" for the executable shows that it was either not built with /Zi or not linked with /debug.  Without symbols the debugger can't find main.

[Manish Arora]

> Step through in windbg and get the NTSTATUS error codes from NtReadVirtualMemory failure (1st warning) and NtGetTContexthread failure (final error).

Hi Derek, I am getting 0x8000000d and 0xc000000d as shown in the attached figures. These correspond to 

0x8000000D STATUS_PARTIAL_COPY

Because of protection conflicts, not all the requested bytes could be copied.

0xC000000D STATUS_INVALID_PARAMETER

An invalid parameter was passed to a service or function

Whats next? 

thanks

Manish

[Derek Bruening]

These are the exact errors expected when trying to use 32-bit drrun on a 64-bit application.  Plus, the Task Manager image from img2.png from your first message does not have the "*32" suffix on "PCMark7Cmd.exe".  That implies it's a 64-bit image.

You said you ran dumpbin.  Can you paste the evidence you took to mean it's a 32-bit image.

What does ProcessExplorer say (it has an Image Type column).

You said "Using the latest version as suggested by you gives me the wrong architecture error whe using 64 bit drrun/config/inject, so its not a target mismatch.".  That error is not produced by drconfig.  Can you double-check what a recent bin32/drrun says and whether a recent bin64/drrun works.

- Derek

--

[Manish Arora]

Hi Derek

1) Dumbin seems to suggest that it is a 32bit executable (Cap8 x86 instead of x64) but maybe I am reading it wrong.

>>>>Can you double-check what a recent bin32/drrun says and whether a recent bin64/drrun works

2) I built rev 2203 of the repo and ran both the bin32/drrun and bin64/drrun. The 32 bit version gives the same errors as the last time (the exact errors expected when trying to use 32-bit drrun on a 64-bit application) as shown in Cap9. The 64 bit version gives "Target process ... is for the wrong architecture" error as shown in Cap10. 

3) I ran the application under the command line and looked at process explorer as suggested (shown in Cap11). It does seem to be a 64bit. However it launches children that are both 64bit (WebBrowser,exe) and 32bit (PCMark7Manager.exe). 

4) I build the debug 64 version of single stepped thru the code. The function exe_is_right_bitwidth seem to be comparing the headers read and expected. They seem to mismatch as shown in Cap12 and Cap13.

Any ideas?

regards

Manish

[Byron Hawkins]

Hi Manish,

It looks to me like PCMark7Cmd.exe is indeed a 64-bit executable. I see the x86 values in dumpbin that you mentioned, but try running it directly in the x86 version of windbg (without DynamoRIO)--you'll get an error 50: "request not supported". But in the x64 version of windbg it runs fine (after setting up windbg to automatically elevate). So it seems to have funny headers, which dumpbin maybe doesn't know about, yet windows does see it as an x64 executable.

I would suggest setting the x64 DynamoRIO binary to automatically elevate, and then run PCMark7Cmd.exe in it.

Byron

[Derek Bruening]

The explanation is that CLR images built with /clr:safe create a 32-bit PE that is loaded to match the underlying kernel's bitwidth.  So on a 64-bit kernel, the kernel modifies the PE header to be PE32+ (changes the magic #, SizeOfOptionalHeader, and later fields).  There also seems to be at least one issue running such an app under DR once DR is properly injected into the new process.  Issue 1224 covers handling such images.  Unfortunately we won't be able to add such support for the imminent next DR release but we can try for the subsequent.  If you'd like to help by debugging the runtime issues (see the app crash info in the issue) please let us know.

[Manish Arora]

Hi Derek

Any other workarounds this? The problem seems to be in trying to start the program. Would running the program from the command line first and then connecting to it later on via DynamoRIO work?

regards

Manish

[Derek Bruening]

r2206 enables the -nocheck option to bypass the arch check.  But, like I said in the issue, I hit an app crash up front when running this application.