I wrote callout driver for implementing firewall functionality in my VPN product.
I call FwpsPendOperation0( inMetaValues->completionHandle, & (dataPending->completionContext) ) in my callout function, which registered on FWPS_LAYER_ALE_AUTH_CONNECT_V4 layer. Then I call FwpsCompleteOperation0( dataPending->completionContext, 0 ) in my workitem routine and get BSOD.
What wrong?
Attach WinDbg, setup symbols and post output of !analyze -v here
wrote news:xxxxx@ntdev…
>I wrote callout driver for implementing firewall functionality in my VPN
>product.
> I call FwpsPendOperation0( inMetaValues->completionHandle, &
> (dataPending->completionContext) ) in my callout function, which
> registered on FWPS_LAYER_ALE_AUTH_CONNECT_V4 layer. Then I call
> FwpsCompleteOperation0( dataPending->completionContext, 0 ) in my workitem
> routine and get BSOD.
> What wrong?
>
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, April 13, 2007 2:41 AM
Subject: [ntdev] Question on Windows Filtering Platform
>I wrote callout driver for implementing firewall functionality in my VPN
>product.
> I call FwpsPendOperation0( inMetaValues->completionHandle, &
> (dataPending->completionContext) ) in my callout function, which
> registered on FWPS_LAYER_ALE_AUTH_CONNECT_V4 layer. Then I call
> FwpsCompleteOperation0( dataPending->completionContext, 0 ) in my workitem
> routine and get BSOD.
> What wrong?
>
Attach a debugger (windbg) and/or generate a crash dump and provide the
output of !analyze -v to the list.
GV
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
I try to pass netBufferList (I save it in my classify callout) as second param in FwpsCompleteOperation0 - same result.
Look at WinDbg output:
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 9b3bd758, address which referenced memory
Debugging Details:
DBGHELP: C:\Program Files\Debugging Tools for Windows\ntkrnlmp.exe - file not found
DBGHELP: ntkrnlmp.exe not found in E:\Share\Work\Vista\debug
DBGHELP: E:\Share\SymbolsServer\ntkrnlmp.exe\4549AD6C395000\ntkrnlmp.exe - OK
DBGHELP: C:\Program Files\Debugging Tools for Windows\tcpip.sys - file not found
DBGHELP: tcpip.sys not found in E:\Share\Work\Vista\debug
DBGHELP: E:\Share\SymbolsServer\tcpip.sys\4549B337d1000\tcpip.sys - OK
DBGHELP: C:\Program Files\Debugging Tools for Windows\rfhlpr.sys - file not found
DBGHELP: E:\Share\Work\Vista\debug\rfhlpr.sys - OK
DBGHELP: E:\Share\Work\Vista\debug\rfhlpr.sys found
WRITE_ADDRESS: 00000000
CURRENT_IRQL: 2
FAULTING_IP:
tcpip!WfpAleDeleteRemoteEndpoint+26
9b3bd758 890a mov dword ptr [edx],ecx
DEFAULT_BUCKET_ID: VISTA_RC
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
TRAP_FRAME: 82511c08 – (.trap ffffffff82511c08)
ErrCode = 00000002
eax=9b52a938 ebx=00000000 ecx=00000000 edx=00000000 esi=9b52a840 edi=9b3edf80
eip=9b3bd758 esp=82511c7c ebp=82511c8c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
tcpip!WfpAleDeleteRemoteEndpoint+0x26:
9b3bd758 890a mov dword ptr [edx],ecx ds:0023:00000000=???
Resetting default scope
LAST_CONTROL_TRANSFER: from 818ad13f to 81835688
STACK_TEXT:
825117ec 818ad13f 00000003 8251a37c 00000000 nt!RtlpBreakWithStatusInstruction
8251183c 818adbac 00000003 00000000 9b3bd758 nt!KiBugCheckDebugBreak+0x1c
82511be8 818494d4 0000000a 00000000 00000002 nt!KeBugCheck2+0x5f4
82511be8 9b3bd758 0000000a 00000000 00000002 nt!KiTrap0E+0x2ac
82511c8c 9b3bcd74 9b52a840 818f55fc 9c0e2418 tcpip!WfpAleDeleteRemoteEndpoint+0x26
82511ccc 9b3bcdc4 c0000022 841c4ee8 9b7feb50 tcpip!WfpAleHandleSendCompletion+0x78
82511cec 9b3bc84d 9c0e2418 00000000 9b656d50 tcpip!WfpAlepAuthorizeSendCompletion+0x2f
82511d20 9c73b238 9c0e2418 00000000 82511d44 tcpip!WfpAleCompleteOperation+0x6a
82511d30 81a18f9a 9b7feb50 9c0d8098 83b89580 rfhlpr!WorkItemProc+0x18 [e:\share\work\vista\rfhlpr\rfhlpr.c @ 341]
82511d44 8186b8aa 9b656d50 00000000 83b89580 nt!IopProcessWorkItem+0x23
82511d7c 819afbfd 9b656d50 8251a680 00000000 nt!ExpWorkerThread+0xfd
82511dc0 8189a396 8186b7ad 00000001 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
rfhlpr!WorkItemProc+18 [e:\share\work\vista\rfhlpr\rfhlpr.c @ 341]
9c73b238 8b4d0c mov ecx,dword ptr [ebp+0Ch]
FAULTING_SOURCE_CODE:
337: dataPending->appPath
338: );
339: */
340: FwpsCompleteOperation0( dataPending->completionContext, dataPending->NetBufferList );
341: IoFreeWorkItem( dataPending->ioWorkItem );
342: ExFreePool( dataPending );
343: return;
344: }
345:
346:
SYMBOL_STACK_INDEX: 8
SYMBOL_NAME: rfhlpr!WorkItemProc+18
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: rfhlpr
IMAGE_NAME: rfhlpr.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 462352c9
FAILURE_BUCKET_ID: 0xD1_W_rfhlpr!WorkItemProc+18
BUCKET_ID: 0xD1_W_rfhlpr!WorkItemProc+18
Followup: MachineOwner
1: kd> lmvm rfhlpr
start end module name
9c73a000 9c740000 rfhlpr (private pdb symbols) E:\Share\Work\Vista\debug\rfhlpr.pdb
Loaded symbol image file: rfhlpr.sys
Image path: ??\C:\Windows\System32\drivers\rfhlpr.sys
Image name: rfhlpr.sys
Timestamp: Mon Apr 16 14:41:13 2007 (462352C9)
CheckSum: 0000F260
ImageSize: 00006000
Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
Fix incorrect using classifyOut->outContext (I change it by mistake), but situation wasn’t better:
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8a707521, The address that the exception occurred at
Arg3: 825159b8, Exception Record Address
Arg4: 825156b4, Context Record Address
Debugging Details:
DBGHELP: C:\Program Files\Debugging Tools for Windows\ntkrnlmp.exe - file not found
DBGHELP: ntkrnlmp.exe not found in E:\Share\Work\Vista\debug
DBGHELP: E:\Share\SymbolsServer\ntkrnlmp.exe\4549AD6C395000\ntkrnlmp.exe - OK
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.
FAULTING_IP:
tcpip!WfpAlepReauthorizeOutboundConnection+17f
8a707521 660fb65b04 movzx bx,byte ptr [ebx+4]
EXCEPTION_RECORD: 825159b8 – (.exr ffffffff825159b8)
ExceptionAddress: 8a707521 (tcpip!WfpAlepReauthorizeOutboundConnection+0x0000017f)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000004
Attempt to read from address 00000004
CONTEXT: 825156b4 – (.cxr ffffffff825156b4)
eax=8a79a2d0 ebx=00000000 ecx=00000020 edx=00000001 esi=9b5d2a60 edi=00000003
eip=8a707521 esp=82515a80 ebp=82515bdc iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
tcpip!WfpAlepReauthorizeOutboundConnection+0x17f:
8a707521 660fb65b04 movzx bx,byte ptr [ebx+4] ds:0023:00000004=??
Resetting default scope
PROCESS_NAME: System
CURRENT_IRQL: 0
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.
READ_ADDRESS: 00000004
BUGCHECK_STR: 0x7E
DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
LAST_CONTROL_TRANSFER: from 8a70724f to 8a707521
STACK_TEXT:
82515bdc 8a70724f 9b5d2a60 00000000 8a79a2d0 tcpip!WfpAlepReauthorizeOutboundConnection+0x17f
82515c50 8a77bd49 8a79a2d0 00000002 00000001 tcpip!WfpAleReauthorizeOutboundConnection+0xda
82515ccc 8a77bdc4 842f0e70 9b5d2a60 a0d57170 tcpip!WfpAleHandleSendCompletion+0x4d
82515cec 8a77b84d 842f0e70 00000000 a0cee4b0 tcpip!WfpAlepAuthorizeSendCompletion+0x2f
82515d20 9c2dd228 842f0e70 00000000 82515d44 tcpip!WfpAleCompleteOperation+0x6a
82515d30 81a18f9a a0d57170 a0e4f860 83b8bd78 rfhlpr!WorkItemProc+0x18 [e:\share\work\vista\rfhlpr\rfhlpr.c @ 341]
82515d44 8186b8aa a0cee4b0 00000000 83b8bd78 nt!IopProcessWorkItem+0x23
82515d7c 819afbfd a0cee4b0 8251e680 00000000 nt!ExpWorkerThread+0xfd
82515dc0 8189a396 8186b7ad 00000001 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
rfhlpr!WorkItemProc+18 [e:\share\work\vista\rfhlpr\rfhlpr.c @ 341]
9c2dd228 8b4d0c mov ecx,dword ptr [ebp+0Ch]
FAULTING_SOURCE_CODE:
337: dataPending->appPath
338: );
339: */
340: FwpsCompleteOperation0( dataPending->completionContext, dataPending->NetBufferList );
341: IoFreeWorkItem( dataPending->ioWorkItem );
342: ExFreePool( dataPending );
343: return;
344: }
345:
346:
SYMBOL_STACK_INDEX: 5
SYMBOL_NAME: rfhlpr!WorkItemProc+18
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: rfhlpr
IMAGE_NAME: rfhlpr.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 46237907
STACK_COMMAND: .cxr 0xffffffff825156b4 ; kb
FAILURE_BUCKET_ID: 0x7E_rfhlpr!WorkItemProc+18
BUCKET_ID: 0x7E_rfhlpr!WorkItemProc+18
Followup: MachineOwner
Have you cloned the NetBufferList before firing up that WorkItem?
Regards
Frank
wrote news:xxxxx@ntdev…
> Fix incorrect using classifyOut->outContext (I change it by mistake), but
> situation wasn’t better:
> 1: kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>
>
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
> This is a very common bugcheck. Usually the exception address pinpoints
> the driver/function that caused the problem. Always note this address
> as well as the link date of the driver/image that contains this address.
> Arguments:
> Arg1: c0000005, The exception code that was not handled
> Arg2: 8a707521, The address that the exception occurred at
> Arg3: 825159b8, Exception Record Address
> Arg4: 825156b4, Context Record Address
>
> Debugging Details:
> ------------------
>
> DBGHELP: C:\Program Files\Debugging Tools for Windows\ntkrnlmp.exe - file
> not found
> DBGHELP: ntkrnlmp.exe not found in E:\Share\Work\Vista\debug
> DBGHELP: E:\Share\SymbolsServer\ntkrnlmp.exe\4549AD6C395000\ntkrnlmp.exe -
> OK
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
> referenced memory at “0x%08lx”. The memory could not be “%s”.
>
> FAULTING_IP:
> tcpip!WfpAlepReauthorizeOutboundConnection+17f
> 8a707521 660fb65b04 movzx bx,byte ptr [ebx+4]
>
> EXCEPTION_RECORD: 825159b8 – (.exr ffffffff825159b8)
> ExceptionAddress: 8a707521
> (tcpip!WfpAlepReauthorizeOutboundConnection+0x0000017f)
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 00000000
> Parameter[1]: 00000004
> Attempt to read from address 00000004
>
> CONTEXT: 825156b4 – (.cxr ffffffff825156b4)
> eax=8a79a2d0 ebx=00000000 ecx=00000020 edx=00000001 esi=9b5d2a60
> edi=00000003
> eip=8a707521 esp=82515a80 ebp=82515bdc iopl=0 nv up ei pl nz na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010202
> tcpip!WfpAlepReauthorizeOutboundConnection+0x17f:
> 8a707521 660fb65b04 movzx bx,byte ptr [ebx+4]
> ds:0023:00000004=??
> Resetting default scope
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 0
>
> ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
> referenced memory at “0x%08lx”. The memory could not be “%s”.
>
> READ_ADDRESS: 00000004
>
> BUGCHECK_STR: 0x7E
>
> DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
>
> LAST_CONTROL_TRANSFER: from 8a70724f to 8a707521
>
> STACK_TEXT:
> 82515bdc 8a70724f 9b5d2a60 00000000 8a79a2d0
> tcpip!WfpAlepReauthorizeOutboundConnection+0x17f
> 82515c50 8a77bd49 8a79a2d0 00000002 00000001
> tcpip!WfpAleReauthorizeOutboundConnection+0xda
> 82515ccc 8a77bdc4 842f0e70 9b5d2a60 a0d57170
> tcpip!WfpAleHandleSendCompletion+0x4d
> 82515cec 8a77b84d 842f0e70 00000000 a0cee4b0
> tcpip!WfpAlepAuthorizeSendCompletion+0x2f
> 82515d20 9c2dd228 842f0e70 00000000 82515d44
> tcpip!WfpAleCompleteOperation+0x6a
> 82515d30 81a18f9a a0d57170 a0e4f860 83b8bd78 rfhlpr!WorkItemProc+0x18
> [e:\share\work\vista\rfhlpr\rfhlpr.c @ 341]
> 82515d44 8186b8aa a0cee4b0 00000000 83b8bd78 nt!IopProcessWorkItem+0x23
> 82515d7c 819afbfd a0cee4b0 8251e680 00000000 nt!ExpWorkerThread+0xfd
> 82515dc0 8189a396 8186b7ad 00000001 00000000
> nt!PspSystemThreadStartup+0x9d
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> rfhlpr!WorkItemProc+18 [e:\share\work\vista\rfhlpr\rfhlpr.c @ 341]
> 9c2dd228 8b4d0c mov ecx,dword ptr [ebp+0Ch]
>
> FAULTING_SOURCE_CODE:
> 337: dataPending->appPath
> 338: );
> 339: */
> 340: FwpsCompleteOperation0( dataPending->completionContext,
> dataPending->NetBufferList );
>> 341: IoFreeWorkItem( dataPending->ioWorkItem );
> 342: ExFreePool( dataPending );
> 343: return;
> 344: }
> 345:
> 346:
>
>
> SYMBOL_STACK_INDEX: 5
>
> SYMBOL_NAME: rfhlpr!WorkItemProc+18
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: rfhlpr
>
> IMAGE_NAME: rfhlpr.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 46237907
>
> STACK_COMMAND: .cxr 0xffffffff825156b4 ; kb
>
> FAILURE_BUCKET_ID: 0x7E_rfhlpr!WorkItemProc+18
>
> BUCKET_ID: 0x7E_rfhlpr!WorkItemProc+18
>
> Followup: MachineOwner
> ---------
>
>
Yes.
status = FwpsAllocateCloneNetBufferList0( netBufferList, NULL, NULL, 0, &dataPending->NetBufferList );
With cloned NetBufferList:
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 9b79d758, address which referenced memory
Debugging Details:
DBGHELP: C:\Program Files\Debugging Tools for Windows\ntkrnlmp.exe - file not found
DBGHELP: ntkrnlmp.exe not found in E:\Share\Work\Vista\debug
DBGHELP: E:\Share\SymbolsServer\ntkrnlmp.exe\4549AD6C395000\ntkrnlmp.exe - OK
DBGHELP: C:\Program Files\Debugging Tools for Windows\tcpip.sys - file not found
DBGHELP: tcpip.sys not found in E:\Share\Work\Vista\debug
DBGHELP: E:\Share\SymbolsServer\tcpip.sys\4549B337d1000\tcpip.sys - OK
DBGHELP: C:\Program Files\Debugging Tools for Windows\rfhlpr.sys - file not found
DBGHELP: E:\Share\Work\Vista\debug\rfhlpr.sys - OK
DBGHELP: E:\Share\Work\Vista\debug\rfhlpr.sys found
WRITE_ADDRESS: 00000000
CURRENT_IRQL: 2
FAULTING_IP:
tcpip!WfpAleDeleteRemoteEndpoint+26
9b79d758 890a mov dword ptr [edx],ecx
DEFAULT_BUCKET_ID: VISTA_RC
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
TRAP_FRAME: a1d97c08 – (.trap ffffffffa1d97c08)
ErrCode = 00000002
eax=9b834ea8 ebx=00000000 ecx=00000000 edx=00000000 esi=9b834db0 edi=9b7cdf80
eip=9b79d758 esp=a1d97c7c ebp=a1d97c8c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
tcpip!WfpAleDeleteRemoteEndpoint+0x26:
9b79d758 890a mov dword ptr [edx],ecx ds:0023:00000000=???
Resetting default scope
LAST_CONTROL_TRANSFER: from 818ad13f to 81835688
STACK_TEXT:
a1d977ec 818ad13f 00000003 a1d9c37c 00000000 nt!RtlpBreakWithStatusInstruction
a1d9783c 818adbac 00000003 00000000 9b79d758 nt!KiBugCheckDebugBreak+0x1c
a1d97be8 818494d4 0000000a 00000000 00000002 nt!KeBugCheck2+0x5f4
a1d97be8 9b79d758 0000000a 00000000 00000002 nt!KiTrap0E+0x2ac
a1d97c8c 9b79cd74 9b834db0 818f55fc 84474dc0 tcpip!WfpAleDeleteRemoteEndpoint+0x26
a1d97ccc 9b79cdc4 c0000022 9bbb8320 8449e138 tcpip!WfpAleHandleSendCompletion+0x78
a1d97cec 9b79c84d 84474dc0 00000000 845569d0 tcpip!WfpAlepAuthorizeSendCompletion+0x2f
a1d97d20 9c67b238 84474dc0 00000000 a1d97d44 tcpip!WfpAleCompleteOperation+0x6a
a1d97d30 81a18f9a 8449e138 9b0ab008 9b879740 rfhlpr!WorkItemProc+0x18 [e:\share\work\vista\rfhlpr\rfhlpr.c @ 341]
a1d97d44 8186b8aa 845569d0 00000000 9b879740 nt!IopProcessWorkItem+0x23
a1d97d7c 819afbfd 845569d0 a1d9c680 00000000 nt!ExpWorkerThread+0xfd
a1d97dc0 8189a396 8186b7ad 80000001 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
rfhlpr!WorkItemProc+18 [e:\share\work\vista\rfhlpr\rfhlpr.c @ 341]
9c67b238 6a00 push 0
FAULTING_SOURCE_CODE:
337: dataPending->appPath
338: );
339: */
340: FwpsCompleteOperation0( dataPending->completionContext, dataPending->NetBufferList );
341: FwpsFreeCloneNetBufferList0( dataPending->NetBufferList, 0 );
342: IoFreeWorkItem( dataPending->ioWorkItem );
343: ExFreePool( dataPending );
344: return;
345: }
346:
SYMBOL_STACK_INDEX: 8
SYMBOL_NAME: rfhlpr!WorkItemProc+18
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: rfhlpr
IMAGE_NAME: rfhlpr.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 46249876
FAILURE_BUCKET_ID: 0xD1_W_rfhlpr!WorkItemProc+18
BUCKET_ID: 0xD1_W_rfhlpr!WorkItemProc+18
Followup: MachineOwner
Is anybody from an authoritative Microsoft source can says: “WFP is ready for use” ?
My experiments says the opposite: “WFP - inappropriate joke”.
Oleg,
Why don’t you want just to give it up on WFP, and, instead, write NDIS LWF
(unless your product itself is NDIS 6 driver, of course)?
WFP seems to be really a nightmare - no one really knows how it works, because its documentation is, softly speaking, “very, very imprecise” (do be honest, I find it just unusable). As opposed to that, NDIS 6 is fairly well documented and, in general, seems to be practically trouble-free, compared the earlier NDIS versions
( at least as far as filters and protocol drivers are concerned )
Anton Bassov
I am NOT an authoritative Microsoft source, but at work we have used every
layer within WFP and it works for us. We also have an NDIS LWF, and that
works as well.
-Preston
On 4/17/07 7:16 AM, “xxxxx@infotecs.ru” wrote:
> Is anybody from an authoritative Microsoft source can says: “WFP is ready for
> use” ?
> My experiments says the opposite: “WFP - inappropriate joke”.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Excuse me for asking such stupid questions…but haven’t you dropped the
originating request in your callout-function by setting actionType to
FWP_ACTION_BLOCK?
wrote news:xxxxx@ntdev…
> Is anybody from an authoritative Microsoft source can says: “WFP is ready
> for use” ?
> My experiments says the opposite: “WFP - inappropriate joke”.
>
classifyOut->actionType = FWP_ACTION_BLOCK;
classifyOut->rights &= ~FWPS_RIGHT_ACTION_WRITE;
classifyOut->flags |= FWPS_CLASSIFY_OUT_FLAG_ABSORB;
IoQueueWorkItem( dataPending->ioWorkItem, WorkItemProc, DelayedWorkQueue, dataPending );
I have also faced same problem befor for ale_connect_layer… i think there
is some problem with this layer with udp packet implementation… i have also
posted some query befor…
On 4/17/07, xxxxx@infotecs.ru wrote:
>
> classifyOut->actionType = FWP_ACTION_BLOCK;
> classifyOut->rights &= ~FWPS_RIGHT_ACTION_WRITE;
> classifyOut->flags |= FWPS_CLASSIFY_OUT_FLAG_ABSORB;
>
> IoQueueWorkItem( dataPending->ioWorkItem, WorkItemProc,
> DelayedWorkQueue, dataPending );
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Hi, niraj jha. I read you posts. My last experiments shows what FwpsCompleteOperation0( …, 0 ) work with TCP and UDP on FWPS_LAYER_ALE_AUTH_CONNECT_V4 layer (ICMP brings to BSOD).
On which layer I can handle ICMP?
And how I can recognize repeated call of classifyFn, forced by FwpsCompleteOperation0?
Well i am still confused with ale outbound implementation… in my case udp
is generating problem and in your case icmp… it should have some proper
reinjection function which is not avilable yet… for recognizing repeated
call of classifyFn i simply made a statful entry for that packet befor
calling FwpsCompleteOperation0 and in classifyFn i use to check the entry
in that table first…
On 4/18/07, xxxxx@infotecs.ru wrote:
>
> Hi, niraj jha. I read you posts. My last experiments shows what
> FwpsCompleteOperation0( …, 0 ) work with TCP and UDP on
> FWPS_LAYER_ALE_AUTH_CONNECT_V4 layer (ICMP brings to BSOD).
> On which layer I can handle ICMP?
> And how I can recognize repeated call of classifyFn, forced by
> FwpsCompleteOperation0?
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Yet another investigation. Using FwpsPendOperation0 on FWPS_LAYER_ALE_FLOW_ESTABLISHED_V4 layer not possible for ping, since inMetaValues->completionHandle equal 0 and FwpsPendOperation0 return STATUS_FWP_NULL_POINTER (0xC022001CL) correspondingly.
we can`t use FwpsPendOperation0 function for
FWPS_LAYER_ALE_FLOW_ESTABLISHED_V4 … document says we can only pend
packet on FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_*Xxx*,
FWPM_LAYER_ALE_AUTH_LISTEN_*Xxx*, or FWPM_LAYER_ALE_AUTH_CONNECT_*Xxx* …
FWPS_LAYER_ALE_FLOW_ESTABLISHED_V4 runs on context with process…
so i do`t think it will pend… Better to switch to the network layer may be
it will solve your problem…
On 4/18/07, xxxxx@infotecs.ru wrote:
>
> Yet another investigation. Using FwpsPendOperation0 on
> FWPS_LAYER_ALE_FLOW_ESTABLISHED_V4 layer not possible for ping, since
> inMetaValues->completionHandle equal 0 and FwpsPendOperation0 return
> STATUS_FWP_NULL_POINTER (0xC022001CL) correspondingly.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>>document says we can only pend
>packet on FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_*Xxx*,
>FWPM_LAYER_ALE_AUTH_LISTEN_*Xxx*, or FWPM_LAYER_ALE_AUTH_CONNECT_*Xxx*
Yes, I remember. But “ping” don’t appear on FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_*Xxx* and FWPM_LAYER_ALE_AUTH_LISTEN_*Xxx*. On FWPM_LAYER_ALE_AUTH_CONNECT_*Xxx* I gets BSOD in case pending “ping”. What I missed?
Have you checked this with other layers i mean network or transpoprt?
On 4/18/07, xxxxx@infotecs.ru wrote:
>
> >>document says we can only pend
> >>packet on FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_Xxx,
> >>FWPM_LAYER_ALE_AUTH_LISTEN_Xxx, or FWPM_LAYER_ALE_AUTH_CONNECT_Xxx
> Yes, I remember. But “ping” don’t appear on
> FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_Xxx and
> FWPM_LAYER_ALE_AUTH_LISTEN_Xxx. On FWPM_LAYER_ALE_AUTH_CONNECT_Xxx I
> gets BSOD in case pending “ping”. What I missed?
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>