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

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

WFP callout unload/load problem when using FwpsFlowAssociateContext0(...) function

Nikolay_VasilievNikolay_Vasiliev Member Posts: 1
Hello,

I playing with Inspect sample from Microsoft which illustrates the use of different WFP callouts. I noticed that once I am associating my own context to a flow handle in ALE_AUTH_CONNECT_V4 using FwpsFlowAssociateContext0 I am starting to have problems with driver unloading/loading.

I.e., if I unload driver using

net stop inspect

and then load it using

net start inspect

I receive the following error:

System error 2 has occurred.
The system cannot find the file specified.

It tried to unregister all the flow contextes using FwpsFlowRemoveContext0 in Unload routine (I kept them in list and then just iterate over list and call FwpsFlowRemoveContext0 on each element) but this does not help.

If I do not associate context with flow handle I don't have any problems: I can load/unload driver in stress tests script and everything works for days.

I have, therefore the following questions:

1. Why OS gives such a strange error message on load? It could have cancelled the unloading of driver as long as there are any pending contextes associated with the flow handles?

2. Why even after removing the context with FwpsFlowRemoveContext0 I still have the problem?

3. If it is a bug of Windows, is there any KB article explaining it?

Thanks for any thoughts on this!

Comments

  • Thomas_DivineThomas_Divine Member Posts: 325
    On Unload consider:

    Delete your WFP filters.
    Unregister your callouts.

    Note: The act of unregistering your callouts should cause your flow delete
    callouts to be called for each flow. In flow delete you simply free your
    context - don't call FlowRemoveContext.

    AFTER deleting filters and unregistering callouts you might insure your list
    is empty.

    Keep at it. This will work once you re-read the docs and attend to the
    details.

    Thomas F. Divine


    -----Original Message-----
    From: [email protected]
    [mailto:[email protected]] On Behalf Of
    [email protected]
    Sent: Thursday, May 9, 2013 6:21 AM
    To: Windows System Software Devs Interest List
    Subject: [ntdev] WFP callout unload/load problem when using
    FwpsFlowAssociateContext0(...) function

    Hello,

    I playing with Inspect sample from Microsoft which illustrates the use of
    different WFP callouts. I noticed that once I am associating my own context
    to a flow handle in ALE_AUTH_CONNECT_V4 using FwpsFlowAssociateContext0 I am
    starting to have problems with driver unloading/loading.

    I.e., if I unload driver using

    net stop inspect

    and then load it using

    net start inspect

    I receive the following error:

    System error 2 has occurred.
    The system cannot find the file specified.

    It tried to unregister all the flow contextes using FwpsFlowRemoveContext0
    in Unload routine (I kept them in list and then just iterate over list and
    call FwpsFlowRemoveContext0 on each element) but this does not help.

    If I do not associate context with flow handle I don't have any problems: I
    can load/unload driver in stress tests script and everything works for days.

    I have, therefore the following questions:

    1. Why OS gives such a strange error message on load? It could have
    cancelled the unloading of driver as long as there are any pending contextes
    associated with the flow handles?

    2. Why even after removing the context with FwpsFlowRemoveContext0 I still
    have the problem?

    3. If it is a bug of Windows, is there any KB article explaining it?

    Thanks for any thoughts on this!

    ---
    NTDEV is sponsored by OSR

    OSR is HIRING!! See http://www.osr.com/careers

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • john-7john-7 Member Posts: 12

    Hello All,

    I am getting the same issue.
    even after unregistering all the filters and unregistering all the callouts in the order the
    DRIVER_OBJECT is still present (It does not show up in Driver\ list)
    and shows the PointerCount is still 1 for the driver object when !object

    <

    address> is printed.

    The driver is unloaded using sc stop , during unload someone opens a handle to the object and PointerCount suddenly jumps but is reset back.
    there is a breakpoint on write access for object header for the driver object

    Hence the driver can't unload. can someone please check and let me know what am I missing.

    I have attached the entire windbg trace and pasted a little bit of info.
    thanks

    3: kd> !object ffff9306c660ba60 Object: ffff9306c660ba60 Type: (ffff9306c450ab00) Driver ObjectHeader: ffff9306c660ba30 (new version) HandleCount: 0 PointerCount: 3 Directory Object: ffffc88fbd8f17c0 Name: GIAppDef 3: kd> ba w8 ffff9306c660ba30 3: kd> g TRACE: GetMSDosName : nameInfo = C:\Windows\System32\sc.exe TRACE: GetUtf8StringLengthRaw : Getting utf8 string length for C:\Windows\System32\sc.exe TRACE: GetUtf8StringLengthRaw : --- Exiting GetUtf8StringLengthRaw --- TRACE: GetUtf8StringLengthRaw : Getting utf8 string length for sc stop giappdef TRACE: GetUtf8StringLengthRaw : --- Exiting GetUtf8StringLengthRaw --- TRACE: MemCopy : dest = FFFFC8003E33AFD0, src = FFFFC8003E346FE0, len = 27 TRACE: MemCopy : --- Exiting MemCopy --- TRACE: MemCopy : dest = FFFFC8003E33AFEB, src = FFFFC8003E1C4FE0, len = 18 TRACE: MemCopy : --- Exiting MemCopy --- TRACE: MemCopy : dest = FFFFC8003DF0AEF0, src = FFFFC8003DF4AEF0, len = 267 TRACE: MemCopy : --- Exiting MemCopy --- TRACE: IsMemEqual : s1 = FFFFC8003E33AF5C, s2 = FFFFC80038610FBC, len = 32 TRACE: IsMemEqual : --- Exiting IsMemEqual --- DEBUG: _GetHashKey : PROCESS type C:\Windows\System32\sc.exe alarm key 2331978580 DEBUG: GIAppDefProcCreateExitCb : Process with PID 4472 starting. ProcessTable update successful. Breakpoint 1 hit nt!ObfReferenceObject+0x25: fffff803aab0c305 48ffc3 inc rbx
    3: kd> !object ffff9306c660ba60 Object: ffff9306c660ba60 Type: (ffff9306c450ab00) Driver ObjectHeader: ffff9306c660ba30 (new version) HandleCount: 0 PointerCount: 4 Directory Object: ffffc88fbd8f17c0 Name: GIAppDef 3: kd> kv # Child-SP RetAddr : Args to Child : Call Site 00 ffffe78111e4fca0 fffff803aaeffb0a : ffffc88fc92ae030 ffffe78111e4fde0 ffffe78100000002 ffffc88fc5829670 : nt!ObfReferenceObject+0x25 01 ffffe78111e4fce0 fffff803aae25d0d : ffff9306c8ce3000 ffffe78111e4ff40 ffffe78100000240 ffff9306c450ab00 : nt!ObpLookupObjectName+0xa1a 02 ffffe78111e4feb0 fffff803aae3b9ad : ffffe78100000001 ffff9306c705b080 0000000000000000 ffffe781`11e50350 :

  • john-7john-7 Member Posts: 12

    I have found why the driver can't be unloaded but still need help to resolve this problem. The issue is that while unloading - I call FwpsFlowRemoveContext for remaining flow contexts which are stored in a linked list) returns STATUS_UNSUCCESSFUL (There is no context currently associated with the data flow.) as per https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/fwpsk/nf-fwpsk-fwpsflowremovecontext0

    However there are contexts associated because FwpsCalloutUnregisterById() fails with DEVICE_BUSY. https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/fwpsk/nf-fwpsk-fwpscalloutunregisterbyid0
    I have verified that This is an active flow and the process (svchost) which initiated this flow is still active.
    The flow deletion function for this flow has not been called.

    Any clues about this issue, why FwpsFlowRemoveContext fails?

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
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE