exe information

[codesearcher]

I have ask and search on this forum on how to get the exe file information most specially the company name.
I have also search on google and pscode and I gathered some codes that I can test. And yes, some exe files have company name information but what puzzles me is that why some windows processes seems cannot be retrieve information like csrss.exe and dwm.exe but if you go to manually click the properties of the said exe files and on the details tab, you can see that there are informations about those files.

Is there another way to get those information ?

[DrUnicode]

csrss.exe
Try turning off 64-bit OS redirection.
Here is an example of how to run OnScreenKeyboard OSK.Exe on 64-bit OS.
Jut insert your code to get Exe Company name in place of ShellExeute.

Option Explicit

Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hwnd As Long, ByVal lpszOp As String, ByVal lpszFile As String, ByVal lpszParams As String, ByVal LpszDir As String, ByVal FsShowCmd As Long) As Long
Private Declare Function Wow64EnableWow64FsRedirection Lib "kernel32.dll" (ByVal Enable As Boolean) As Boolean
Private Declare Function GetProcAddress Lib "kernel32" (ByVal hModule As Long, ByVal lpProcName As String) As Long
Private Declare Function GetModuleHandle Lib "kernel32" Alias "GetModuleHandleA" (ByVal lpModuleName As String) As Long
Private Declare Function GetCurrentProcess Lib "kernel32" () As Long
Private Declare Function IsWow64Process Lib "kernel32" (ByVal hProc As Long, bWow64Process As Boolean) As Long
    
Private Sub Command1_Click()
   If Is64bit Then
      Wow64EnableWow64FsRedirection False
      ShellExecute Me.hwnd, "open", "osk.exe", "", App.Path, vbNormalFocus
      Wow64EnableWow64FsRedirection True
   Else
      ShellExecute Me.hwnd, "open", "osk.exe", "", App.Path, vbNormalFocus
   End If
End Sub

Public Function Is64bit() As Boolean
   If GetProcAddress(GetModuleHandle("kernel32"), "IsWow64Process") > 0 Then
      IsWow64Process GetCurrentProcess(), Is64bit
   End If
End Function

[codesearcher]

I tried to replace on shellexecute but still I dont get the info from c:\windows\syswow64\csrss.exe

Edit:

Ok, I edited my work and is now ok. Thanks DrUnicode for the disabling the redirection.

[DrUnicode]

It's in the code snippet "Wow64EnableWow64FsRedirection False". Just replace ShellExeute line with your code to get version info, company name, etc.

[codesearcher]

Now, I wonder why mysqld.exe dont have information like company name. Moreover, on the details tab, theres no information also. Is that normal to mysql mysqld.exe file ?

[Bonnie West]

The Wow64EnableWow64FsRedirection function actually requires a Byte argument and returns a Byte value. According to Windows Data Types, the BOOLEAN data type is, in fact, just 8 bits wide. Note that the all uppercase Windows BOOLEAN data type is different from VB's Boolean data type, which is 16 bits wide. More importantly, their True values are also different, in both size and value (1 vs -1).

BTW, MSDN and Raymond Chen actually recommends an alternative approach when wanting to directly access files in the native system directory:

32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection. Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one.

Windows Server 2003 and Windows XP: The Sysnative alias was added starting with Windows Vista.

Whenever you use one of these "global solutions to a local problem" types of solutions that change some fundamental behavior of the system, you have to make sure that everybody is on board with your decision.

The local solution would be to use the C:\Windows\SysNative virtual directory for files you want to look up in the native system directory rather than the emulated system directory.

• History—the Long Way Through. In their zeal to make this article meet length, the editors cut what I consider to be the most important part of the article! Here's the penultimate paragraph in its full unedited version, with the important part underlined.
  
  
  But wait, there's still more. What if you want to access the real 64-bit system directory from a 32-bit process? File system redirection will take your attempt to access the C:\Windows\System32 directory and redirect it to the C:\Windows\SysWOW64 directory. Programmatically, you can use functions with unwieldy names like Wow64DisableWow64FsRedirection, but those disable redirection for all operations until re-enabled, which causes trouble if you're doing anything more complicated than opening a single file, because a complex operation may result in multiple files being accessed and possibly even worker threads being created. Instead of using a gross switch like disabling file system redirection, you can use the special C:\Windows\SysNative virtual directory. When a 32-bit process tries to access the C:\Windows\SysNative directory, the operations are redirected to the real C:\Windows\System32 directory. A local solution to a local problem.

Now, I wonder why mysqld.exe dont have information like company name. Moreover, on the details tab, theres no information also. Is that normal to mysql mysqld.exe file ?

If that EXE has no version-information resource in it (which you can verify via Resource Hacker or similar resource viewer tools), then there's really nothing you can do about it.

[fafalone]

The issue that was going on with csrss.exe was that it didn't exist in SysWOW64, it only existed in System32, but was only accessible with redirection off.
Redirection on, C:\Windows\System32\csrss.exe not found to API, visible at that location in Explorer, not found and not visible in SysWOW64.
Redirection off, C:\Windows\System32\csrss.exe now visible, still visible at the location in Explorer

So I really don't understand why accessing it through SysNative even works when accessing it directly at its clearly actual location doesn't. (It does though, but checking the path of every file you query for version info to replace System32 and(?) SysWOW64 with SysNative seems like a pain)

[Bonnie West]

Normally, 32-bit programs don't need to access the native system directory of a 64-bit OS. So, if the 64-bit OS says to a 32-bit program that the csrss.exe file is missing in the System32 directory, then it can't indeed be found in the SysWOW64 directory that is meant to be the emulated System32 directory for 32-bit programs. Now, if a 32-bit program really wants to access the native system directory of a 64-bit OS (and not the emulated System32 directory), then all it needs to do to bypass the file system redirection is to use the special SysNative alias.

[fafalone]

So where is the actual physical location of csrss.exe on a 64-bit system? Because it's just confusing because Explorer says System32 and not SysWOW64, but API says neither System32 nor SysWOW64; then with redirection off both say System32 and not Wow64.

SysNative is proving to be a poor workaround too; absolutely everything revolving around it needs special handling (unlike normal links it doesn't resolve to the actual folder, so if you try to use 'open folder', an error occurs). If it's a special purpose access to a single file it's one thing; but my main concern is a generic handler for any file on the system that reports accurate information (including real location), from simple text files in Documents all the way though superhidden 64bit files. Need to be able to search actual locations, maybe the user wants to find the 64-bit version.

[Bonnie West]

... because Explorer says System32 and not SysWOW64, but API says neither System32 nor SysWOW64; then with redirection off both say System32 and not Wow64.

I'm not certain about this (I'm using Win 7 32-bit) but isn't the Explorer process in a 64-bit OS also 64-bit? If that's the case, then that explains the behavior you're seeing.

If it's a special purpose access to a single file it's one thing; but my main concern is a generic handler for any file on the system that reports accurate information (including real location), from simple text files in Documents all the way though superhidden 64bit files. Need to be able to search actual locations, maybe the user wants to find the 64-bit version.

The SysNative alias indeed doesn't seem to be the best fit in your particular scenario. In that case, the Wow64DisableWow64FsRedirection & Wow64RevertWow64FsRedirection pair of functions might be a more suitable choice in your situation. However, as mentioned in the articles linked above, you need to be very careful when using any of those 3 API functions that have thread-wide effects.

[codesearcher]

Bonnie, it seems that even is resource hacker there are exe files that dont have company name information.

[fafalone]

I came up with quite the elaborate way of calling the redirect functions when I forgot an 'entry point not found' error was recoverable, when we talked about this the other day.

[fafalone]

Bonnie, it seems that even is resource hacker there are exe files that dont have company name information.

There is no programmatic or legal requirement for an exe to have version information, and it's not something which is done automatically. You have to create a resource file and add version information, which in other languages isn't automatic where you just fill in a field like VB. So lots of programmers don't bother to do this.

The function I wrote when you first asked this question a couple days ago will work if you turn off 64-bit redirection before calling it. If that comes back blank, there simply isn't version information that contains the company name.