locked
Attempting to collect Process Full Path Names from 32-bit app running on 64-bit W2k3 fails

    Question

  • From My 32-bit compiled Application I am attempting to enumerate the Processes running in my W2k3 64-bit system to collect the Full Path Names of all processes running in the system.

     

    EnumProcessModules()

     - Collects only the 32-bit process Full Path Names on 64-bit

     

    CreateToolhelp32Snapshot()

    Module32First

    MODULEENTRY32.szExePath

    - Collects only the 32-bit process Full Path Name on 64-bit

     

    .NET in an unmanaged 32-bit Application

    Diagnostics:Stick out tonguerocess::GetProcesses()

    Diagnostics:Stick out tonguerocess*->MainModule->FileName

    - Fails with unhlepful message on 64-bit

     

     

    All of the Above methods for collecting the Full Path Name of the currently running process all work from 32-bit app on 32-bit platform.

     

    So, other than compiling my app on 64-bit, What method can I use for collecting the Full Path Name of all the currently running Processes in the box (other than System and Idle) ?

    Friday, February 15, 2008 5:02 PM

Answers

  •  

    My final solution was to collect the process data from WMI via the enumeration of Win32_Process class instances.

     

    WMI can collect/bridge the 32/64 bit worlds eliminating me from having a 64-bit compiled obj that my 32-bit app can call for visibility/collection of to the 64-bit processes (or 32-bit compiled obj for my 64-bit base app to launch/call for collecting 32 bit process information).

     

    SELECT ExecutablePath FROM Win32_Process WHERE ProcessID = %ProcessID%

    Monday, February 25, 2008 4:11 PM

All replies

  •  

    i am having a similar problem, although trying to do something different:

     

    note the thread here:

     

    http://forums.microsoft.com/msdn/ShowPost.aspx?siteid=1&postid=2899182

     

     

    did you find a solution?  do you mind sharing some code for it?

     

    best,

    Mike

     

    Monday, February 25, 2008 2:58 PM
  • I did open a ticket with MS - SRZ080219000262

     

    Their answer:

    Issue is not with the any native win32 API, namespace class or the property. The fundamental rule here is ,

    32-bit process can not enumerate the loaded modules of 64-bit process , and vice-versa.

    You was trying to enumerate the modules ( full path name ) of 64-bit process using the sample compiled as 32-bit , so it was not working .

    When you compile the sample as 64-bit , it is able to enum the modules of the 64-bit process. Success expected.

    Why Process Explorer is able to enumerate modules of both 32-bit and 64-bit processes at the same time.

    The reason here is , when process explorer launches , it also have a 64 bit version with it .There is some logic , 64-bit version is not actually visible to us , but it is there.

    So when through the Process Explorer you try to enum modules of 32-bit process , 32-bit version of Process explorer is active and displays the modules correctly.

    And same way you try to enum modules of 64-bit process , 64-bit version of Process explorer is active and displays the modules correctly.

    I prepared a small demonstration for you to make the points clear.

    1: When I run process explorer , it launches itself as 2 entries in the task manager. One for 32-bit and other for 64-bit.

    picture removed

    2 : Process explorer show itself as –

    picture removed

    This explains the approach to enum processes on 64 bit machine for both 32 and 64 bit processes.

    I can not find a public document which states this behavior. But there is a new API EnumProcessModulesEx Function which seems to be fixing this issue on Windows Vista and Windows Server 2008.

     

    Monday, February 25, 2008 4:08 PM
  •  

    My final solution was to collect the process data from WMI via the enumeration of Win32_Process class instances.

     

    WMI can collect/bridge the 32/64 bit worlds eliminating me from having a 64-bit compiled obj that my 32-bit app can call for visibility/collection of to the 64-bit processes (or 32-bit compiled obj for my 64-bit base app to launch/call for collecting 32 bit process information).

     

    SELECT ExecutablePath FROM Win32_Process WHERE ProcessID = %ProcessID%

    Monday, February 25, 2008 4:11 PM
  • thanks for the reply!

     

    if i use call to EnumProcessModulesEx  in my 32bit app on Vista, can it then access 64 bit process/module information?  or must i make the move to 64 bit program.  i am using a language that only compiles to 32 bit unfortunately-

     

     

    best,

    Mike

     

     

    Monday, February 25, 2008 4:13 PM
  •  lin1ood wrote:

     

    My final solution was to collect the process data from WMI via the enumeration of Win32_Process class instances.

     

    WMI can collect/bridge the 32/64 bit worlds eliminating me from having a 64-bit compiled obj that my 32-bit app can call for visibility/collection of to the 64-bit processes (or 32-bit compiled obj for my 64-bit base app to launch/call for collecting 32 bit process information).

     

    SELECT ExecutablePath FROM Win32_Process WHERE ProcessID = %ProcessID%

     

    doing this, how would i then get ahold of the base address of modules of a running 64 bit process (called from 32 bit app)?

     

    sorry so many questions and thanks again for the help:

     

    note:

     

    The CreateToolhelp32Snapshot / Process32First / Process32Next works fine to get the PID of 64 bit apps, but EnumProcessModules / GetModuleFileNameExA / GetModuleBaseNameA does not work on 64 bit processes that are running.

     

    I note the following in the MSDN knowledge base regarding EnumProcessModules:

     

    If this function is called from a 32-bit application running on WOW64, it can only enumerate the modules of a 32-bit process. To enumerate the modules of a 64-bit process from an application running on WOW64, use the CreateToolhelp32Snapshot function.

     

    and then on the CreateToolhelp32Snapshot page of the same site:

     

    CreateToolhelp32Snapshot Function
    ----------------------------------
    If the specified process is a 64-bit process and the caller is a 32-bit process, this call will fail. Note that you can use the QueryFullProcessImageName function to retrieve the full name of an executable image for both 32- and 64-bit processes from a 32-bit process.

     

    I See the information posted for QueryFullProcessImageName but am not sure how to implement it.

    do you do this instead of CreateToolhelp32Snapshot? then what? how do you access the list of modules running under that process?

     

    i am not sure how to get ahold of the list of modules of a running 64 bit process from a 32 bit application.

     

    for instance:

     

    My application is 32 bit program.  I am running it in Vista 64 bit OS.  it tries to access 64 bit program (notepad.exe, for instance) and list the attached modules of that process (kernel32.dll, for instance) and also the base address of the .exe and each of the .dll's.

     

    thanks!

    Monday, February 25, 2008 4:17 PM