Problem running Win64 Intel64 apps not statically linked to user32.dll - stdin and stdout not acting as expected

[derekbruening]

From tevi.dev...@gtempaccount.com on May 12, 2009 11:06:30

What steps will reproduce the problem? 1.Run provided Win64 Intel64 swim.exe under dynamo as follows (Note it
does not statically link to user32.dll):
swim.exe < swim.in > swim.out
2.The only way I could get Win64 Intel64 apps, that do not statically link
to user32.dll, to run under dynamo was to
a. register cmd.exe to run under dynamo
b. register swim.exe to run under dynamo
c. open command prompt window
d. run drinject sim.exe < swim.in > swim.out
NOTE - it would not run under dynamo if I did not do drinject
3.The problem is that swim.exe never gets any input from swim.in
4.Also for Win64 Intel64 apps the produce output to stdout, I do not see
any output on the screen - e.g. gzip.exe input.source 60
from cpu2k, when run under dynamo What is the expected output? What do you see instead? run swim.exe < swim.in > swim.out
on native to see expected output. What version of the product are you using? On what operating system? Win64 Server 2003. dynamo 1.4.0.20 Please provide any additional information below.

Attachment: swim.exe swim.in

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=142

[derekbruening]

From derek.br...@gmail.com on May 13, 2009 09:29:38

initial theory is that follow-children injection is not working here and the late
injection results in stdin being messed up, but needs real investigation to confirm

xref PR 333891: cygwin g++-compiled apps suppress all output from DR, where late
injection resulted in stderr/stdout being messed up

xref PR 251677: 64-bit early inject into child process

xref PR 277686: bugs booting 64-bit XP, where 64-bit follow-children injection didn't
seem to be working as it should

presumably this works fine with 32-bit cmd and 32-bit swim.exe?

[derekbruening]

From derek.br...@gmail.com on April 21, 2010 07:01:37

discovered and fixed an issue in drinject causing failure to properly inherit std*
handles: fixed in r320 . I believe that will fix the problem here.

Status: Fixed