ProcessExist or Maybe Run Command does not give the correct PID

[Emiel Wieldraaijer]

Hi,

If i run the following code on a W7 X86 it will give the correct PID result

$PID = Run(@SystemDir & "\mstsc.exe", @TempDir)
If ProcessExists($PID) Then Msgbox (64, "Process", "The Process ID = " & $PID)

When i run the same code on W7 X64 it will not show the correct PID

Thanks

Emiel

[Valik]

Works fine for me on Windows 7 x64 using both x86 and x64 versions of AutoIt.

[Emiel Wieldraaijer]

Hi Valik,

I've took a better look and i made a screenshot for you to see the error
The PID returned is the PID of the compiled executable. The error is caused by the Run Command. On My notebook Windows 7 X86 the problem does not exist

In my screenshot ​http://www.emro.nl/AutoIt/RunPIDError.png

Program name = ProcessExistTest.exe -> PID = 2268 (this is returned by the above example)
Program name = mstsc.exe -> PID = 3212 (this should be returned by the above example)

Windows 7 Ultimate X64
English language selected (MUI)

I hope you will take another look.

Best regards,

Emiel Wieldraaijer

[Valik]

You are not correct. The PID returned is 2688 (Two-Six-Eight-Eight). That is NOT 2268 (Two-Two-Six-Eight) which is the PID of ProcessExistTest.exe.

The behavior you describe can easily be caused by mstsc.exe restarting itself. I don't know why it would do that (that doesn't happen on my system) but that's likely what is causing the problem.

[Emiel Wieldraaijer]

Hi Valik,

Sorry you are totaly correct .. will check other X64 systems and see if i have the same problem

[Emiel Wieldraaijer]

Hi Valik,

I've checked another W7 X64 system (dutch pro), and you are correct it happens with mstsc.exe and not with calc.exe and notepad.exe but i cannot explain why it only happens to X64 and not with X86.

Thanks for you time

Best regards,

Emiel

[anonymous]

Hi Valik,

I know this is not a forum

But the solution for Mstsc.exe

Local $stOldVal = DllStructCreate("dword")
DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "ptr", DllStructGetPtr($stOldVal))
$PID = Run(@WindowsDir & "\system32\mstsc.exe", @TempDir)
If ProcessExists($PID) Then Msgbox (64, "Process", "The Process ID = " & $PID)
DllCall("kernel32.dll", "int", "Wow64RevertWow64FsRedirection", "ptr", DllStructGetPtr($stOldVal))

[Valik]

This is not a bug. Here's what is happening. The version of mstsc.exe in SysWOW64 is 32-bits. When you run this version it just loads a 64-bit version of mstsc.exe. That means its PID changes and the problem you describe happens. I've verified that the version in SysWOW64 is 32-bits with Dependency Walker. I have also verified that running that version results in a 64-bit process running (Process Explorer). Also, that process is orphaned (It has no parent). If I run the version from system32 I also get a 64-bit process but it does have a parent - the Explorer process I launched it from.

Now, this all relates to your specific case because you want to run the version in system32 explicitly and don't care that it's 64-bit. As you've discovered, the only way to do this from a 32-bit process is to briefly turn off redirection. My initial conclusion that this is not a bug stands. The only reason I'm explaining this now is because this ticket was referenced in #1901. I looked at this ticket, saw that I didn't provide a completely firm conclusion so I investigated something that came to me.

[anonymous]

Thanks..