none
WFPSampler doesn't play nicely with itself? RRS feed

  • Question

  • Hi,

    Our WFP driver is based upon the WFPSampler filtering out of band at the stream layer.  

    We had a report from a customer who was experiencing browsing issues (explorer showing corrupt pages or not completing page loads) when our software was installed with a 3rd-party anti-virus.  During investigations I couldn't see what either us or the 3rd-party driver were doing wrong so I thought I would try two versions of the WFPSampler just to ensure they played nicely together. 

    So I created a second version (from the version dated 4/2/2014), ensuring I changed all the relevant GUIDs, inf files etc. In addition the following changes were made:

    1) The driver creates the stream layer filter at startup.  This avoids the need to have the WFPSamplerService.exe or WFPSampler.exe installed.
    2) As suggested in this post:

    http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/c697fb91-1ff5-4eda-a04d-ff386ed67930/wfpsampler-stream-inject-synchronization?forum=wfp

    I added a wait lock to the WorkItemRoutine as follows:

    VOID BasicStreamInjectionWorkItemRoutine(_In_ PDEVICE_OBJECT pDeviceObject,
                                             _Inout_opt_ PVOID pContext)
    {
    #if DBG

       DbgPrintEx(DPFLTR_IHVNETWORK_ID,
                  DPFLTR_INFO_LEVEL,
                  " ---> BasicStreamInjectionWorkItemRoutine()\n");

    #endif /// DBG

       UNREFERENCED_PARAMETER(pDeviceObject);

       NT_ASSERT(pContext);

       NTSTATUS     status      = STATUS_SUCCESS;
       PIO_WORKITEM pIOWorkItem = (PIO_WORKITEM)pContext;
       KIRQL        irql        = PASSIVE_LEVEL;
       LIST_ENTRY*  pListEntry  = 0;

       WdfWaitLockAcquire(g_bsiSerializationList.waitlock, NULL);    <-- Added

       /// Seriailze the Stream injection to prevent data corruption
       KeAcquireSpinLock(&g_bsiSerializationList.spinlock,
                         &irql);

       .... rest of sample code

       WdfWaitLockRelease(g_bsiSerializationList.waitlock);          <-- Added

       if(pIOWorkItem)
          IoFreeWorkItem(pIOWorkItem);

    #if DBG

       DbgPrintEx(DPFLTR_IHVNETWORK_ID,
                  DPFLTR_INFO_LEVEL,
                  " <--- BasicStreamInjectionWorkItemRoutine()\n");

    #endif /// DBG

       return;
    }

    When either version of the sample is started alone browsing works fine on a Windows 8.1 pro, x64 (1 processor 4 cores).  However as soon as the second version is started browsing exhibits the symptoms reported by the customer, corrupt pages/page hangs.  This was also reproduced on a unpatched machine thereby eliminating any recent hot-fixes.  I also disabled the windows firewall and windows defender to ensure there were no other filters at the stream layer (as shown by netsh wfp capture start/stop).

    Perhaps this is because both versions of the sample are using work-items? Previous co-existence testing with other Anti-virus products hasn't shown any issues (which might be inline or using DPCs).

    Has anyone come across this issue? Any ideas on how this can be resolved?

    Can supply wfp capture logs and the sample code if needed.

    All help greatly appreciated.

    Thanks

    Monday, September 8, 2014 2:29 PM

All replies

  • Anyone from Microsoft? 

    Hoping someone can save me from having to raise this officially.

    Monday, September 22, 2014 8:55 AM