Hi all!
I have used IoQueryFileDosDeviceName() to get full path of a process. Now my question is how to convert this full path (c:\myfolder\ApacheOpenOfficeEng.exe) to process name (ApacheOpenOfficeEng.exe)
I already try psGetProcessImageFileName() but only 14 characters (ApacheOpenOffi) is printed because this fonction is limited to the first 16 (ASCII) characters of the image file name.
Sorry for my english.
Thank advance.
I think that you will find that the value returned from PsGetProcessImageFileNameis the processname (by definition) and what you want is the full file name associated with the process.
I’d suggest two solutions - depending on how accurate this needs to be
Do it by hand. Work backwards from the end of c:\myfolder\ApacheOpenOfficeEng.exe until you get to the first \ or the front of the string.
Get Filter Manager to do it. Open the file (FltCreate) then do a FltGetFileNameInformationUnsafe and finally a FltParseFileNameInformation. You’ll need to convert the DOS name into a proper name - usually dont by preprending \??\ to the name (\??\c:\myfolder\ApacheOpenOfficeEng.exe)
@rod_widdowson said:
I think that you will find that the value returned from PsGetProcessImageFileNameis the processname (by definition) and what you want is the full file name associated with the process.
I’d suggest two solutions - depending on how accurate this needs to be
Do it by hand. Work backwards from the end of c:\myfolder\ApacheOpenOfficeEng.exe until you get to the first \ or the front of the string.
Get Filter Manager to do it. Open the file (FltCreate) then do a FltGetFileNameInformationUnsafe and finally a FltParseFileNameInformation. You’ll need to convert the DOS name into a proper name - usually dont by preprending \??\ to the name (\??\c:\myfolder\ApacheOpenOfficeEng.exe)
My problem is successfully SOLVED.
I thank Mr. Tim Roberts and Mr. rod_widdowson for giving me the idea. Also, many thank to Mr. ThatsBerkan for his source code.
(Happy New Year, everyone! Getting caught up on posts from over the holiday…)
Just to throw it out there for the archives: FltMgr also provides FltParseFileName to do this sort of parsing on a UNICODE_STRING (no FLT_FILE_NAME_INFORMATION required). I always like code I don’t have to write…
There is a bug in that routine, unless they fixed it recently.
Namely, if UWF is enabled, it will incorrectly parse file names that start
with 5 characters in the top folder, e.g.
\Fldr5\Somefilename.ext
This is seen in FltParseFileNameInformation as well, which is how I found
out.
The bug can bring dowm a system, if your driver treats tbe resulting
strings as valid fully, and assumes that the sum of component lengths is
equal to the total length. It js not, but it is +2.
I cannot even imagine how a filter would cause that problem…
It is not like UWF parses the file name itself; the returned
FLT_FILE_NAME_INFORMATION (or whatever type file name you get) is correct!
It is the PARSING of the file name, by FltMgr APIs, that fails in that
particular case.
How does that matter when it comes to parsing?
What a name provider returns is a UNICODE_STRING.
FltMgr is the one that parses that string. And it fails in that one
extremely specific example, by adding an extra size to one of the
parsed components.
Specifically, this is the check that I perform for that case: if(lpName-\>Name.Length \< lpName-\>Volume.Length)
lpName is an FLT_FILE_NAME_INFORMATION structure.
rod_widdowson commented on How to convert full process path to only process
name ?
> I cannot even imagine how a filter would cause that problem…