Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


How to convert full process path to only process name ?

zakadamzakadam Member Posts: 9

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.

Comments

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,173

    I think that you will find that the value returned from PsGetProcessImageFileName is 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)
  • zakadamzakadam Member Posts: 9

    @rod_widdowson said:
    I think that you will find that the value returned from PsGetProcessImageFileName is 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.

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,379

    (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...

    -scott
    OSR

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 374
    via Email
    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.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,253

    "UWF" like the Universal Write Filter? LOL... what have they done that causes a bug to appear in FltParseFileName? That's too funny.

    I'm not questioning your report, Mr. @Dejan_Maksimovic ... I'm simply marveling at the wonderful world in which we Windows KM devs live.

    P

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 374
    via Email
    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.

    Kind regards, Dejan Maksimovic.
    FS Lead: http://www.alfasp.com


    "UWF" like the Universal Write Filter? LOL... what have they done that
  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,173

    I cannot even imagine how a filter would cause that problem...

    Is it a name provider?

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 374
    via Email
    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...
    >
    > Is it a name provider?
  • NtDev_GeekNtDev_Geek Member - All Emails Posts: 114

    Here this is an old but work like a jam take a look. I think it may help you further.
    https://www.osronline.com/article.cfm^article=472.htm

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE