KMDF: bug? WdfIoTargetClose calls paged routine

WdfIoTargetClose, which may be called at IRQL<=DISPATCH_LEVEL, has a call to
IoUnregisterPlugPlayNotification, which must be called at
IRQL=PASSIVE_LEVEL. This happens in the context of a normal system
shutdown.

I think I can rearrange things so that my call to WdfIoTargetClose happens
at passive. Note that my I/O target has routines specified for
EvtIoTargetQueryRemove, EvtIoTargetRemoveCanceled, and
EvtIoTargetRemoveComplete, with the intention of cleaning up the target when
the system shuts down (or otherwise causes a remove), but none of these have
been invoked.

Here's a !analyze:

kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 808f703c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 808f703c, address which referenced memory

Debugging Details:

WRITE_ADDRESS: 808f703c

CURRENT_IRQL: 2

FAULTING_IP:
nt!IoUnregisterPlugPlayNotification+0
808f703c 8bff mov edi,edi

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 808253e7 to 8086c81c

STACK_TEXT:
f795a294 808253e7 00000003 808f703c 00000000
nt!RtlpBreakWithStatusInstruction
f795a2e0 808262bc 00000003 808f703c 808f703c nt!KiBugCheckDebugBreak+0x19
f795a678 80886099 0000000a 808f703c 00000002 nt!KeBugCheck2+0x5b2
f795a678 808f703c 0000000a 808f703c 00000002 nt!KiTrap0E+0x2a1
f795a708 f72be1b7 e18dfd70 82732f10 f73217b0
nt!IoUnregisterPlugPlayNotification
f795a748 f72bb084 00000002 827eee10 827eeefc
Wdf01000!FxIoTargetRemote::Close+0x5f0
f795a760 f75391b6 7d993118 8266cee0 f795a854
Wdf01000!imp_WdfIoTargetClose+0x82
f795a770 f7538a54 7d993118 827eee10 827eeefc AAVolFlt!WdfIoTargetClose+0x16
[c:\winddk\wdf\kmdf10\inc\wdfiotarget.h @ 328]
f795a854 f72f5dfc 7d8111e8 7cfd50b0 00000000
AAVolFlt!AAVolEvtIoDeviceControl+0x5b4
[c:\working\appassure\aavolflt\aavolflt.c @ 915]
f795a878 f72f75d3 7d8111e8 7cfd50b0 00000000
Wdf01000!FxIoQueueIoDeviceControl::Invoke+0x30
f795a8b0 f72f9e1d 8302af48 8302af48 827eee10
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x61b
f795a8d0 f72fb739 827eee00 827eee10 82e0ee00
Wdf01000!FxIoQueue::DispatchEvents+0x5a8
f795a8f0 f72fe11f 00000000 80a4aa90 82421ae0
Wdf01000!FxIoQueue::QueueRequest+0x348
f795a918 f72e999b 8302af48 f795a954 809aa50c
Wdf01000!FxPkgIo::Dispatch+0x520
f795a924 809aa50c 82421ae0 82e0ee00 82e0ef88
Wdf01000!FxDevice::Dispatch+0x7f
f795a954 8081d36b 809ba528 f795a974 809ba528 nt!IovCallDriver+0x112
f795a960 809ba528 80a4aa90 823f8aa0 00000000 nt!IofCallDriver+0x13
f795a974 809aa50c 823f8aa0 82e0ee00 82e0efac nt!ViFilterDispatchGeneric+0x2a
f795a9a4 8081d36b f714203b f795aa18 f714203b nt!IovCallDriver+0x112
f795a9b0 f714203b 82e0ee00 f795aa34 00000000 nt!IofCallDriver+0x13
f795aa18 f711d0aa f795aa90 82e0ee00 80a4aa90
Ntfs!NtfsCommonDeviceControl+0xef
f795aa7c f712f505 f795aa90 82e0ee00 00000001 Ntfs!NtfsFsdDispatchSwitch+0xe4
f795ab98 809aa50c 82278020 82e0ee00 00000000 Ntfs!NtfsFsdDispatchWait+0x1c
f795abc8 8081d36b f71b8b43 f795abf8 f71b8b43 nt!IovCallDriver+0x112
f795abd4 f71b8b43 00000000 829cef5c 00000000 nt!IofCallDriver+0x13
f795abf8 f71b967d f795ac18 8225a020 00000000
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f795ac30 f71c902f 82ca8e10 00000000 82ca8e10
fltMgr!FltPerformSynchronousIo+0xb9
f795ac90 f71c914c 82ca8e10 81d57dc0 0000000e
fltMgr!IssueControlOperation+0x2c1
f795acc0 f74fef0e 82ca8e10 81d57dc0 83223a08
fltMgr!FltDeviceIoControlFile+0x26
f795acf4 f74fea04 833b0e50 f74fe910 800005c0
AAFsFlt!AAFsCloseAAVolIoctl+0x7e [c:\working\appassure\aafsflt\aafsdata.c @
878]
f795ad08 f74fbc0a 833b0e50 00000000 00000000 AAFsFlt!AAFsCloseLogFile+0xf4
[c:\working\appassure\aafsflt\aafsdata.c @ 549]
f795ad28 f71cf527 f795ad54 00000001 f795ad6c
AAFsFlt!AAFsInstanceTeardownComplete+0x5a
[c:\working\appassure\aafsflt\aafsinit.c @ 823]
f795ad38 f71c7848 f795ad54 00000001 823179e8
fltMgr!FltvInstanceTeardownComplete+0x15
f795ad6c f71c1362 829bac18 00000001 808a76fc fltMgr!FltpFreeInstance+0x98
f795ad80 8087a469 82bf2fe0 00000000 823179e8
fltMgr!FltpCommonDetachVolumeWorker+0x12
f795adac 8094095c 82bf2fe0 00000000 00000000 nt!ExpWorkerThread+0xeb
f795addc 8088757a 8087a37e 80000001 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
Wdf01000!FxIoTargetRemote::Close+5f0
f72be1b7 8d45e4 lea eax,[ebp-0x1c]

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 5

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Wdf01000!FxIoTargetRemote::Close+5f0

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 438e21c3

FAILURE_BUCKET_ID: 0xA_W_VRF_Wdf01000!FxIoTargetRemote::Close+5f0

BUCKET_ID: 0xA_W_VRF_Wdf01000!FxIoTargetRemote::Close+5f0

Followup: MachineOwner

EvtIoTargetQueryRemove / EvtIoTargetRemoveCanceled /
EvtIoTargetRemoveComplete are only called when the target device get's
query remove->remove (e.g. a graceful remove) or a surprise remove.
Stacks are not torn down on shutdown, so you won't get these callbacks
in that scenario.

The IRQL restriction on WdfIoTargetClose should be PASSIVE_LEVEL b/c it
needs to call IoUnregisterPlugPlayNotification(). Later on it will
actually call ZwClose as well, which also has an IRQL==PASSIVE_LEVEL
restriction. I will have the docs updated.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, March 16, 2006 9:32 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF: bug? WdfIoTargetClose calls paged routine

WdfIoTargetClose, which may be called at IRQL<=DISPATCH_LEVEL, has a
call to
IoUnregisterPlugPlayNotification, which must be called at
IRQL=PASSIVE_LEVEL. This happens in the context of a normal system
shutdown.

I think I can rearrange things so that my call to WdfIoTargetClose
happens
at passive. Note that my I/O target has routines specified for
EvtIoTargetQueryRemove, EvtIoTargetRemoveCanceled, and
EvtIoTargetRemoveComplete, with the intention of cleaning up the target
when
the system shuts down (or otherwise causes a remove), but none of these
have
been invoked.

Here's a !analyze:

kd> !analyze -v
************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 808f703c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 808f703c, address which referenced memory

Debugging Details:

WRITE_ADDRESS: 808f703c

CURRENT_IRQL: 2

FAULTING_IP:
nt!IoUnregisterPlugPlayNotification+0
808f703c 8bff mov edi,edi

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 808253e7 to 8086c81c

STACK_TEXT:
f795a294 808253e7 00000003 808f703c 00000000
nt!RtlpBreakWithStatusInstruction
f795a2e0 808262bc 00000003 808f703c 808f703c
nt!KiBugCheckDebugBreak+0x19
f795a678 80886099 0000000a 808f703c 00000002 nt!KeBugCheck2+0x5b2
f795a678 808f703c 0000000a 808f703c 00000002 nt!KiTrap0E+0x2a1
f795a708 f72be1b7 e18dfd70 82732f10 f73217b0
nt!IoUnregisterPlugPlayNotification
f795a748 f72bb084 00000002 827eee10 827eeefc
Wdf01000!FxIoTargetRemote::Close+0x5f0
f795a760 f75391b6 7d993118 8266cee0 f795a854
Wdf01000!imp_WdfIoTargetClose+0x82
f795a770 f7538a54 7d993118 827eee10 827eeefc
AAVolFlt!WdfIoTargetClose+0x16
[c:\winddk\wdf\kmdf10\inc\wdfiotarget.h @ 328]
f795a854 f72f5dfc 7d8111e8 7cfd50b0 00000000
AAVolFlt!AAVolEvtIoDeviceControl+0x5b4
[c:\working\appassure\aavolflt\aavolflt.c @ 915]
f795a878 f72f75d3 7d8111e8 7cfd50b0 00000000
Wdf01000!FxIoQueueIoDeviceControl::Invoke+0x30
f795a8b0 f72f9e1d 8302af48 8302af48 827eee10
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x61b
f795a8d0 f72fb739 827eee00 827eee10 82e0ee00
Wdf01000!FxIoQueue::DispatchEvents+0x5a8
f795a8f0 f72fe11f 00000000 80a4aa90 82421ae0
Wdf01000!FxIoQueue::QueueRequest+0x348
f795a918 f72e999b 8302af48 f795a954 809aa50c
Wdf01000!FxPkgIo::Dispatch+0x520
f795a924 809aa50c 82421ae0 82e0ee00 82e0ef88
Wdf01000!FxDevice::Dispatch+0x7f
f795a954 8081d36b 809ba528 f795a974 809ba528 nt!IovCallDriver+0x112
f795a960 809ba528 80a4aa90 823f8aa0 00000000 nt!IofCallDriver+0x13
f795a974 809aa50c 823f8aa0 82e0ee00 82e0efac
nt!ViFilterDispatchGeneric+0x2a
f795a9a4 8081d36b f714203b f795aa18 f714203b nt!IovCallDriver+0x112
f795a9b0 f714203b 82e0ee00 f795aa34 00000000 nt!IofCallDriver+0x13
f795aa18 f711d0aa f795aa90 82e0ee00 80a4aa90
Ntfs!NtfsCommonDeviceControl+0xef
f795aa7c f712f505 f795aa90 82e0ee00 00000001
Ntfs!NtfsFsdDispatchSwitch+0xe4
f795ab98 809aa50c 82278020 82e0ee00 00000000
Ntfs!NtfsFsdDispatchWait+0x1c
f795abc8 8081d36b f71b8b43 f795abf8 f71b8b43 nt!IovCallDriver+0x112
f795abd4 f71b8b43 00000000 829cef5c 00000000 nt!IofCallDriver+0x13
f795abf8 f71b967d f795ac18 8225a020 00000000
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f795ac30 f71c902f 82ca8e10 00000000 82ca8e10
fltMgr!FltPerformSynchronousIo+0xb9
f795ac90 f71c914c 82ca8e10 81d57dc0 0000000e
fltMgr!IssueControlOperation+0x2c1
f795acc0 f74fef0e 82ca8e10 81d57dc0 83223a08
fltMgr!FltDeviceIoControlFile+0x26
f795acf4 f74fea04 833b0e50 f74fe910 800005c0
AAFsFlt!AAFsCloseAAVolIoctl+0x7e
[c:\working\appassure\aafsflt\aafsdata.c @
878]
f795ad08 f74fbc0a 833b0e50 00000000 00000000
AAFsFlt!AAFsCloseLogFile+0xf4
[c:\working\appassure\aafsflt\aafsdata.c @ 549]
f795ad28 f71cf527 f795ad54 00000001 f795ad6c
AAFsFlt!AAFsInstanceTeardownComplete+0x5a
[c:\working\appassure\aafsflt\aafsinit.c @ 823]
f795ad38 f71c7848 f795ad54 00000001 823179e8
fltMgr!FltvInstanceTeardownComplete+0x15
f795ad6c f71c1362 829bac18 00000001 808a76fc
fltMgr!FltpFreeInstance+0x98
f795ad80 8087a469 82bf2fe0 00000000 823179e8
fltMgr!FltpCommonDetachVolumeWorker+0x12
f795adac 8094095c 82bf2fe0 00000000 00000000 nt!ExpWorkerThread+0xeb
f795addc 8088757a 8087a37e 80000001 00000000
nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
Wdf01000!FxIoTargetRemote::Close+5f0
f72be1b7 8d45e4 lea eax,[ebp-0x1c]

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 5

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Wdf01000!FxIoTargetRemote::Close+5f0

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 438e21c3

FAILURE_BUCKET_ID: 0xA_W_VRF_Wdf01000!FxIoTargetRemote::Close+5f0

BUCKET_ID: 0xA_W_VRF_Wdf01000!FxIoTargetRemote::Close+5f0

Followup: MachineOwner


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

OK, thanks. Ensuring that I make the call from PASSIVE_LEVEL did eliminate
the problem.

  • Dan.

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Thursday, March 16, 2006 11:16 AM
Subject: RE: [ntdev] KMDF: bug? WdfIoTargetClose calls paged routine

EvtIoTargetQueryRemove / EvtIoTargetRemoveCanceled /
EvtIoTargetRemoveComplete are only called when the target device get’s
query remove->remove (e.g. a graceful remove) or a surprise remove.
Stacks are not torn down on shutdown, so you won’t get these callbacks
in that scenario.

The IRQL restriction on WdfIoTargetClose should be PASSIVE_LEVEL b/c it
needs to call IoUnregisterPlugPlayNotification(). Later on it will
actually call ZwClose as well, which also has an IRQL==PASSIVE_LEVEL
restriction. I will have the docs updated.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, March 16, 2006 9:32 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF: bug? WdfIoTargetClose calls paged routine

WdfIoTargetClose, which may be called at IRQL<=DISPATCH_LEVEL, has a
call to
IoUnregisterPlugPlayNotification, which must be called at
IRQL=PASSIVE_LEVEL. This happens in the context of a normal system
shutdown.

I think I can rearrange things so that my call to WdfIoTargetClose
happens
at passive. Note that my I/O target has routines specified for
EvtIoTargetQueryRemove, EvtIoTargetRemoveCanceled, and
EvtIoTargetRemoveComplete, with the intention of cleaning up the target
when
the system shuts down (or otherwise causes a remove), but none of these
have
been invoked.

Here’s a !analyze:

kd> !analyze -v
***********************************************************



Bugcheck Analysis



*****************************************************************


IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 808f703c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 808f703c, address which referenced memory

Debugging Details:
------------------

WRITE_ADDRESS: 808f703c

CURRENT_IRQL: 2

FAULTING_IP:
nt!IoUnregisterPlugPlayNotification+0
808f703c 8bff mov edi,edi

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 808253e7 to 8086c81c

STACK_TEXT:
f795a294 808253e7 00000003 808f703c 00000000
nt!RtlpBreakWithStatusInstruction
f795a2e0 808262bc 00000003 808f703c 808f703c
nt!KiBugCheckDebugBreak+0x19
f795a678 80886099 0000000a 808f703c 00000002 nt!KeBugCheck2+0x5b2
f795a678 808f703c 0000000a 808f703c 00000002 nt!KiTrap0E+0x2a1
f795a708 f72be1b7 e18dfd70 82732f10 f73217b0
nt!IoUnregisterPlugPlayNotification
f795a748 f72bb084 00000002 827eee10 827eeefc
Wdf01000!FxIoTargetRemote::Close+0x5f0
f795a760 f75391b6 7d993118 8266cee0 f795a854
Wdf01000!imp_WdfIoTargetClose+0x82
f795a770 f7538a54 7d993118 827eee10 827eeefc
AAVolFlt!WdfIoTargetClose+0x16
[c:\winddk\wdf\kmdf10\inc\wdfiotarget.h @ 328]
f795a854 f72f5dfc 7d8111e8 7cfd50b0 00000000
AAVolFlt!AAVolEvtIoDeviceControl+0x5b4
[c:\working\appassure\aavolflt\aavolflt.c @ 915]
f795a878 f72f75d3 7d8111e8 7cfd50b0 00000000
Wdf01000!FxIoQueueIoDeviceControl::Invoke+0x30
f795a8b0 f72f9e1d 8302af48 8302af48 827eee10
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x61b
f795a8d0 f72fb739 827eee00 827eee10 82e0ee00
Wdf01000!FxIoQueue::DispatchEvents+0x5a8
f795a8f0 f72fe11f 00000000 80a4aa90 82421ae0
Wdf01000!FxIoQueue::QueueRequest+0x348
f795a918 f72e999b 8302af48 f795a954 809aa50c
Wdf01000!FxPkgIo::Dispatch+0x520
f795a924 809aa50c 82421ae0 82e0ee00 82e0ef88
Wdf01000!FxDevice::Dispatch+0x7f
f795a954 8081d36b 809ba528 f795a974 809ba528 nt!IovCallDriver+0x112
f795a960 809ba528 80a4aa90 823f8aa0 00000000 nt!IofCallDriver+0x13
f795a974 809aa50c 823f8aa0 82e0ee00 82e0efac
nt!ViFilterDispatchGeneric+0x2a
f795a9a4 8081d36b f714203b f795aa18 f714203b nt!IovCallDriver+0x112
f795a9b0 f714203b 82e0ee00 f795aa34 00000000 nt!IofCallDriver+0x13
f795aa18 f711d0aa f795aa90 82e0ee00 80a4aa90
Ntfs!NtfsCommonDeviceControl+0xef
f795aa7c f712f505 f795aa90 82e0ee00 00000001
Ntfs!NtfsFsdDispatchSwitch+0xe4
f795ab98 809aa50c 82278020 82e0ee00 00000000
Ntfs!NtfsFsdDispatchWait+0x1c
f795abc8 8081d36b f71b8b43 f795abf8 f71b8b43 nt!IovCallDriver+0x112
f795abd4 f71b8b43 00000000 829cef5c 00000000 nt!IofCallDriver+0x13
f795abf8 f71b967d f795ac18 8225a020 00000000
fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f795ac30 f71c902f 82ca8e10 00000000 82ca8e10
fltMgr!FltPerformSynchronousIo+0xb9
f795ac90 f71c914c 82ca8e10 81d57dc0 0000000e
fltMgr!IssueControlOperation+0x2c1
f795acc0 f74fef0e 82ca8e10 81d57dc0 83223a08
fltMgr!FltDeviceIoControlFile+0x26
f795acf4 f74fea04 833b0e50 f74fe910 800005c0
AAFsFlt!AAFsCloseAAVolIoctl+0x7e
[c:\working\appassure\aafsflt\aafsdata.c @
878]
f795ad08 f74fbc0a 833b0e50 00000000 00000000
AAFsFlt!AAFsCloseLogFile+0xf4
[c:\working\appassure\aafsflt\aafsdata.c @ 549]
f795ad28 f71cf527 f795ad54 00000001 f795ad6c
AAFsFlt!AAFsInstanceTeardownComplete+0x5a
[c:\working\appassure\aafsflt\aafsinit.c @ 823]
f795ad38 f71c7848 f795ad54 00000001 823179e8
fltMgr!FltvInstanceTeardownComplete+0x15
f795ad6c f71c1362 829bac18 00000001 808a76fc
fltMgr!FltpFreeInstance+0x98
f795ad80 8087a469 82bf2fe0 00000000 823179e8
fltMgr!FltpCommonDetachVolumeWorker+0x12
f795adac 8094095c 82bf2fe0 00000000 00000000 nt!ExpWorkerThread+0xeb
f795addc 8088757a 8087a37e 80000001 00000000
nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
Wdf01000!FxIoTargetRemote::Close+5f0
f72be1b7 8d45e4 lea eax,[ebp-0x1c]

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 5

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Wdf01000!FxIoTargetRemote::Close+5f0

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 438e21c3

FAILURE_BUCKET_ID: 0xA_W_VRF_Wdf01000!FxIoTargetRemote::Close+5f0

BUCKET_ID: 0xA_W_VRF_Wdf01000!FxIoTargetRemote::Close+5f0

Followup: MachineOwner
---------


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


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