• Question

  • I have a WFP driver registered at the FWPM_LAYER_OUTBOUND_IPPACKET_V4 layer that needs to know the user mode PID of the process associated with a given packet. For this, the code uses PsGetCurrentProcessId(). It seems however that this can sometimes return the incorrect PID (e.g. a PID associated with another process).

    Is this normal? Is there an alternative or better way to get this information?

    Wednesday, May 1, 2013 11:39 PM

All replies

  • Anyone have ideas on this?
    Friday, May 3, 2013 9:48 PM
  • You need get the PID at ALE layer.

    If you want to check the PID at FWPM_LAYER_OUTBOUND_IPPACKET_V4 layber, just need use the flow context to implement it.

    Hope this is help for you!

    Friday, July 19, 2013 2:57 AM
  • K-Drivers run in a random thread context.
    Saturday, April 12, 2014 8:07 PM
  • Hello!

    It is really strange that PID returned by PsGetCurrentProcessId() function belongs to another process. I would recommend to verify again PID of an application that initiated a network connection. I can also recommend to check application with PID returned by PsGetCurrentProcessId() function because it may also establish a network connection or can be the correct application currently used for execution of driver routine.

    It is possible that you are invoking PsGetCurrentProcessId() function within a separate context, e.g., using work items. Try to invoke PsGetCurrentProcessId() function directly within classification function of the callout.

    However, there still might be some other problems with PsGetCurrentProcessId() function. Consider http://stackoverflow.com/questions/14373608/why-does-psgetcurrentprocessid-return-null and https://groups.google.com/forum/#!topic/microsoft.public.development.device.drivers/_Eimay5wMrw.

    As an alternative to PsGetCurrentProcessId() function consider using of metadata parameter of a callout classification function. For example, pMetadata parameter allows fetching of metadata within the following function:

    VOID PerformBasicAction(_In_ const FWPS_INCOMING_VALUES* pClassifyValues,
                            _In_ const FWPS_INCOMING_METADATA_VALUES* pMetadata,
                            _Inout_opt_ VOID* pLayerData,
                            _In_opt_ const VOID* pClassifyContext,
                            _In_ const FWPS_FILTER* pFilter,
                            _In_ UINT64 flowContext,
                            _Inout_ FWPS_CLASSIFY_OUT* pClassifyOut,
                            _In_ FWP_ACTION_TYPE basicAction)

    The pMetadata parameter is a pointer to FWPS_INCOMING_METADATA_VALUES0 (http://msdn.microsoft.com/en-us/library/windows/hardware/ff552397.aspx) data structure. A processId member of this data structure is supposed to store PID of the precess that had started a network connection.

    If nothing helps consider to use "NetSh.exe WFP Capture Start" and "NetSh.exe WFP Capture Stop" commands to diagnose how WFP was capturing of connections.

    • Edited by Petr Alexeev Monday, April 14, 2014 1:39 PM Recalled another possible solution of the problem
    Monday, April 14, 2014 11:28 AM
  • As stated, you can use multiple methods to get the process ID at FWPM_LAYER_OUTBOUND_TRANSPORT_V{4|6}.

    The most common method would be to use a callout at ALE.
       1) get the processId member from the FWPS_INCOMING_METADATA_VALUES passed into the classifyFn.
       2) Call FwpsFlowAssociateContext to associate the process ID with the flow (if you have no other data needed, you can simply pass the PID as the flowContext parameter.  It will then show up in the classifyFn parameters as the flowContext.

    Be aware that you may also get a process other than what you are expecting.  For example, if you are expecting the PID for Explorer.exe (Windows Explorer) when browsing a network share, you would be mistaken.  Explorer uses SMB which is a System process, so the PID you'd see is the one for SYSTEM.

    Hope this helps,

    Dusty Harper [MSFT]
    Microsoft Corporation
    This posting is provided "AS IS", with NO warranties and confers NO rights

    Monday, April 21, 2014 6:06 PM