Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1792 closed Bug (Works For Me)

ProcessExist or Maybe Run Command does not give the correct PID

Reported by: Emiel Wieldraaijer Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: PID ProcessExists run X64 Cc:



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



Attachments (0)

Change History (8)

comment:1 Changed 13 years ago by Valik

  • Resolution set to Works For Me
  • Status changed from new to closed

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

comment:2 Changed 13 years ago by 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

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

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by Emiel Wieldraaijer

Hi Valik,

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

comment:5 Changed 13 years ago by 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,


comment:6 Changed 13 years ago by 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))

comment:7 Changed 13 years ago by 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.

comment:8 Changed 13 years ago by anonymous


Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

as closed The ticket will remain with no owner.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.