Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

[SOLVED]get other process's working dir


  • Please log in to reply
61 replies to this topic
amnesiac
  • Members
  • 124 posts
  • Last active: May 01 2014 03:04 AM
  • Joined: 07 Nov 2010
In process explorer I can right click a process and see it's current working directory. Here, I find the way to get it. i.e.

It might be in the poorly documented "Process Environment Block" (PEB). If so, you can use ReadProcessMemory to read another process's PEB.

But I don't know to do this in AutoHotkey. e.g. I can't find a documents related with the address of working dir in PEB.

Click to download Chinese resource for AutoHotkey.

Recommended: AutoHotkey_L My code is based on it or similar versions, e.g. AutoHotkey_H.
Together with AutoHotkey, we grow and march forward. No matter how the future will be, this period of days is still epic.


TLM
  • Administrators
  • 3864 posts
  • Last active:
  • Joined: 21 Aug 2006
This will loop through all of the running processes and show the respective dir.
objWMIService := ComObjGet( "winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2" )
colItems := objWMIService.ExecQuery("Select * from Win32_Process")._NewEnum
While colItems[objItem]
  MsgBox % objItem.ExecutablePath
Modify the loop to match the process your after.
Or make a list ( multi line concat ) and then match out the specific process you want..
hth ;).

Posted Image

don't duplicate, iterate!


rbrtryn
  • Members
  • 1177 posts
  • Last active: Sep 11 2013 08:04 PM
  • Joined: 22 Jun 2011
You could make this shorter using a for loop:
for Item in ComObjGet( "winmgmts:" ).ExecQuery("Select * from Win32_Process")
  MsgBox % Item.ExecutablePath

But note that the executable's path is not necessarily same as the its working directory.

My Scripts are written for the latest released version of AutoHotkey.

Need a secure, accessible place to backup your stuff? Use Dropbox!


TLM
  • Administrators
  • 3864 posts
  • Last active:
  • Joined: 21 Aug 2006
Not having to use the New Enumerator object is much more convenient.

note that the executable's path is not necessarily same as the its working directory.

Very true

Thanks rbrtryn

Posted Image

don't duplicate, iterate!


GodlyCheese
  • Members
  • 719 posts
  • Last active: Nov 11 2014 07:12 PM
  • Joined: 30 Aug 2012
I'd like to point out that, at least on my system, this returns an unholy number of blanks.

Edit: My potential fix didn't work, just goes to show I'm still quite bad at COM syntax.

TLM
  • Administrators
  • 3864 posts
  • Last active:
  • Joined: 21 Aug 2006

I'd like to point out that, at least on my system, this returns an unholy number of blanks

All empty key values or just some?

Posted Image

don't duplicate, iterate!


rbrtryn
  • Members
  • 1177 posts
  • Last active: Sep 11 2013 08:04 PM
  • Joined: 22 Jun 2011
For many system processes the executable path is blank. I don't know for sure why that occurs, but it may have something to due with them being in the main system path. :?

My Scripts are written for the latest released version of AutoHotkey.

Need a secure, accessible place to backup your stuff? Use Dropbox!


GodlyCheese
  • Members
  • 719 posts
  • Last active: Nov 11 2014 07:12 PM
  • Joined: 30 Aug 2012
Ah, I should have been more specific. The majority of the MsgBox are blank however a few do contain the proper values. It seems to be distributed randomly.

I would have said your code didn't work if it only contained blanks :p

MilesAhead
  • Members
  • 578 posts
  • Last active: Feb 29 2016 05:15 PM
  • Joined: 21 Jan 2009
Use WinGet to return the PID of the active window. Once you have the PID you can get the working directory of the process without COM.

edit: turns out it's an AutoIt3 UDF function. _WinAPI_GetProcessWorkingDirectory($PID = 0)
It's part of the WinAPIEx.au3 UDF. Anyway, it loops through calls to ReadProcessMemory via DllCall. It shouldn't be too difficult to translate to ahk.

The source can be downloaded.

"Some people, when confronted with a problem, think I know, I'll use regular expressions.  Now they have two problems."

- Jamie Zawinski


rbrtryn
  • Members
  • 1177 posts
  • Last active: Sep 11 2013 08:04 PM
  • Joined: 22 Jun 2011
Well, IMO using two lines of code via COM is better than reinventing the wheel with a whole other function.

On my system the ones that come up blank are all system processes:
System Idle Process
System
csrss.exe
svchost.exe
alg.exe
OSPPSVC.EXE
wmiprvse.exe
All of the other processes return the correct path.

My Scripts are written for the latest released version of AutoHotkey.

Need a secure, accessible place to backup your stuff? Use Dropbox!


MilesAhead
  • Members
  • 578 posts
  • Last active: Feb 29 2016 05:15 PM
  • Joined: 21 Jan 2009

All of the other processes return the correct path.


I think this misses the main point. The objective is to get the working directory of the target process. The function I referenced does this. I have a "ReRun" utility that monitors the active window for programs. If it's not Explorer or the current process, then I store the info. One such is the working directory. I don't want to post au3 code in an ahk forum(for some reason.. if it was .vbs I wouldn't feel trepidation) but if you were to look at the code it does everything with simple API. Either way you have to loop through the processes. But why invoke COM when you're not going to really use it for anything else in the app in most cases?

My ReRun app stores buttons for 32 programs in a Gui where each button has the program icon. They all have the working directory noted. Which leads me to believe the API method is pretty reliable.

You can get the UDF with the _WinAPI_GetProcessWorkingDirectory() function here:
<!-- m -->http://www.autoitscr... ... apiex-udf/<!-- m -->

There's maybe 3 DllCalls to convert to ahk syntax. That's it.

"Some people, when confronted with a problem, think I know, I'll use regular expressions.  Now they have two problems."

- Jamie Zawinski


GodlyCheese
  • Members
  • 719 posts
  • Last active: Nov 11 2014 07:12 PM
  • Joined: 30 Aug 2012

Well, IMO using two lines of code via COM is better than reinventing the wheel with a whole other function.

On my system the ones that come up blank are all system processes:

System Idle Process
System
csrss.exe
svchost.exe
alg.exe
OSPPSVC.EXE
wmiprvse.exe
All of the other processes return the correct path.


I don't know what all is coming up blank for my system (because there's 0 info in the MsgBox), but it's around a 3:1 ratio of blank:useful for the 30+ MsgBox I get. Is there a way to get the directory for only the active window btw? I would find that very useful.

TLM
  • Administrators
  • 3864 posts
  • Last active:
  • Joined: 21 Aug 2006

Well, IMO using two lines of code via COM is better than reinventing the wheel with a whole other function.

Agreed! At the same time there are places for commands like WinGet ( see below )..

I don't know what all is coming up blank for my system (because there's 0 info in the MsgBox), but it's around a 3:1 ratio of blank:useful for the 30+ MsgBox I get.

Some may be running in memory others may be deliberately hidden.
You just need to filter out the empty key values.
ProcDirList:=""
for Item in ComObjGet( "winmgmts:" ).ExecQuery("Select * from Win32_Process")
  ProcDirList .= ((Item:=Item.ExecutablePath) ? Item "`n`r" : "" )

MsgBox % ProcDirList

Is there a way to get the directory for only the active window btw? I would find that very useful.

WinGet, ProcPath, ProcessPath, A
  MsgBox % ProcPath

Posted Image

don't duplicate, iterate!


MilesAhead
  • Members
  • 578 posts
  • Last active: Feb 29 2016 05:15 PM
  • Joined: 21 Jan 2009
One trouble with using things like COM and WMI is they tend to be slow. It's ok if you just have an active window you click on and get the information. But if you monitor the active window constantly then it gets obvious real fast they're not up to the job. They bog to uselessness in that scenario. I'll go the WMI/COM way if there's no other way.

"Some people, when confronted with a problem, think I know, I'll use regular expressions.  Now they have two problems."

- Jamie Zawinski


TLM
  • Administrators
  • 3864 posts
  • Last active:
  • Joined: 21 Aug 2006
Not sure I can agree, I've written scripts that poll hardware in the 100ths of seconds and they seem to work just fine.
In the case of WMI, there are things you simply can't do without going 3rd party which probably use it anyway. I dont know.
What ever works I guess.

Posted Image

don't duplicate, iterate!