Get full path of a 64bit process

[malu05]

With 32 bit processes i use:

Func _ProcessGetLocation($iPID = @ScriptFullPath)
If $iPID = 0 Then Return SetError(1, 0, -1)

Local $aProc = DllCall('kernel32.dll', 'hwnd', 'OpenProcess', 'int', BitOR(0x0400, 0x0010), 'int', 0, 'int', $iPID)
If $aProc[0] = 0 Then Return SetError(1, 0, -1)

Local $vStruct = DllStructCreate('int[1024]')
DllCall('psapi.dll', 'int', 'EnumProcessModules', 'hwnd', $aProc[0], 'ptr', DllStructGetPtr($vStruct), 'int', DllStructGetSize($vStruct), 'int*', 0)


Local $aReturn = DllCall('psapi.dll', 'int', 'GetModuleFileNameEx', 'hwnd', $aProc[0], 'int', DllStructGetData($vStruct, 1), 'str', '', 'int', 2048)
If StringLen($aReturn[3]) = 0 Then Return SetError(2, 0, '')
Return $aReturn[3]
EndFunc ;==>_ProcessGetLocation

This will give me the full path of the .exe from the PID

But this does not seem to work with 64bit executables.

[guinness]

You have to compile you program as a 64-bit application to access those details. If you use WinAPIEx, then that function is already there.

[MilesAhead]

I wonder if there's a quick way to determine programmatically if the process that owns a window is 32 or 64 bit? I have a utility that does something similar to the OP code. It uses WinAPI and WinAPIEx functions to get the path of the process that owns the active window, working directory, command line etc.. But due to 32 bit emulation the DllCalls will be redirected to SysWow64 dlls on 64 bit OS if the app is compiled as 32 bit. If I compile as 64 bit I won't be able to get the info for 32 bit apps.

Is there a way to bridge the gap? The only thing that comes to mind would be calling external programs that are 32 or 64 bit and getting the info using some type of IPC that doesn't depend on "bitness." But to know which one to call I'd need a quick way to determine the "bitness" of the Window's owner.

edit: sticking debug msgs it seems OpenProcess works, but calls like GetModuleFilenameEx and the like fail when the process is 64 bits. I'll have to check out OpenProcess and see if it gives a bit indicator.

edit2:

IsWow64Process function

seems to be the one to use.

Edited October 11, 2012 by MilesAhead

[guinness]

_WinAPI_IsWow64Process in WinAPIEx.

[MilesAhead]

_WinAPI_IsWow64Process in WinAPIEx.

Thanks.

[MilesAhead]

This will give me the full path of the .exe from the PID

But this does not seem to work with 64bit executables.

...

I got this one from the forum. It's from gafrost. It does work for 64 bit apps when called from a 32 bit program running under Wow64. You could just adapt the top part to use the PID passed as param if you want. Typically I call it passing in "[Active]" as the $title param.

; Get the execuatble path of a window
; Author gafrost on AutoIt3 forum
Func _WinGetPath($title = "", $strComputer = 'localhost')
Local $win = WinGetTitle($title)
Local $pid = WinGetProcess($win)
Local $wbemFlagReturnImmediately = 0x10
Local $wbemFlagForwardOnly = 0x20
Local $colItems = ""
Local $objWMIService = ObjGet("winmgmts:" & $strComputer & "rootCIMV2")
$colItems = $objWMIService.ExecQuery("SELECT * FROM Win32_Process WHERE ProcessId = " & $pid, "WQL", _
$wbemFlagReturnImmediately + $wbemFlagForwardOnly)
If IsObj($colItems) Then
For $objItem In $colItems
If $objItem.ExecutablePath Then Return $objItem.ExecutablePath
Next
EndIf
Return ""
EndFunc ;==>_WinGetPath

In your main program you can call _WinAPI_IsWow64Process() to see if your app is running under Wow64. If it is, then you can test the external program with the same function using it's PID. If your program is under Wow64 but the external program is not, then you should use the _WinGetPath approach(the external exe is 64 bit.) If the external program is 32 bit then just use the GetModuleFileNameEx() method.

Edited October 14, 2012 by MilesAhead

[guinness]

Good find MilesAhead. I can see the potential for it to fail, but this is very unlikely and only in extreme circumstances.

[guinness]

I just remembered I coded something similar for the snippets wiki. Check out _WinGetDetails.

[MilesAhead]

Good find MilesAhead. I can see the potential for it to fail, but this is very unlikely and only in extreme circumstances.

I try to avoid the looping type info gathering in polling apps. But this is better than showing the user blank buttons. I use the more deterministic GetModuleFileNameEx once I open the process that owns the active window.if the owner is a 32 bit app..

It can be frustrating the hodge-podge that's produced as one language does one thing easily but makes another thing a nightmare. I have scripts in other implementations that get the process info 32 or 64 bit without squawking. But man! it's a big hassle just to put an icon on a button in the Gui! In au3 one just gets it right from the exe file and sticks it on!! Heh. I finally upgraded from SciTE4AutoIt3 3.20 today. I was using 1.79. Not having the same class name meant opening an au3 file didn't jump into the ahk editor just because it was already open. But I'm glad I finally bumped it up. It's not often that would happen anyway. Control-F5 is more fun now.

I just remembered I coded something similar for the snippets wiki. Check out _WinGetDetails.

Thanks for the functions. I bookmarked 'em.

Edited October 15, 2012 by MilesAhead