Hello,
I’m handling async Irp’s in a Non-PnP driver, using
TdiBuildxxx functions. In some very rare cases, my
complition routines are called after my driver is
unlaoded.
I thought about 2 optional solutions:
- Referance my driver object before sending Irp and
dereferance it on complition - I think it is a
problematic solution since when my driver is in
UnloadPending state, when I dereferance the driver
object, there might be a context switch right before
the return and than again a crash might happen:
NTSTATUS MyCompRoutine()
{
Some code
.
.
.
ObDereferenceObject(MyDriverObject)
return STATUS_MORE_PROCESSING_REQUIRED ; code>
}
2. Using the IoSetCompletionRoutineEx with my driver’s
device object, the problem: I’m using the TdiBuildxxx
functions which are macros that using
IoSetCompletionRoutine and not
IoSetCompletionRoutineEx…any idea (except redefine
these macros?)
Thanks in advance
Alon
__________________________________
Yahoo! Mail - PC Magazine Editors’ Choice 2005
http://mail.yahoo.com
i think it’s Ok for you to allocate your own Irp with the routine
IoAllocateIrp and then you should initialize the certain
fileds in the irp and irp stack location. You’d better follow the
TdiBuildxxx Macro when you do your job!
Best Regards,
hanzhu
Alon wrote:
Hello,
I’m handling async Irp’s in a Non-PnP driver, using
TdiBuildxxx functions. In some very rare cases, my
complition routines are called after my driver is
unlaoded.
I thought about 2 optional solutions:
- Referance my driver object before sending Irp and
dereferance it on complition - I think it is a
problematic solution since when my driver is in
UnloadPending state, when I dereferance the driver
object, there might be a context switch right before
the return and than again a crash might happen:
NTSTATUS MyCompRoutine()
{
Some code
.
.
.
ObDereferenceObject(MyDriverObject)
return STATUS_MORE_PROCESSING_REQUIRED ; > code>
> }
> 2. Using the IoSetCompletionRoutineEx with my driver’s
> device object, the problem: I’m using the TdiBuildxxx
> functions which are macros that using
> IoSetCompletionRoutine and not
> IoSetCompletionRoutineEx…any idea (except redefine
> these macros?)
>
> Thanks in advance
>
> Alon
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors’ Choice 2005
> http://mail.yahoo.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
Hi,
Well, thank for the answer but I didn’t understand the
suggestion…you simly suggest to manually implement
these macros (TdiBuildxxx)?
Alon
“hanzhu” wrote in message
news:xxxxx@ntdev…
> i think it’s Ok for you to allocate your own Irp
with the routine
> IoAllocateIrp and then you should initialize the
certain
> fileds in the irp and irp stack location. You’d
better follow the
> TdiBuildxxx Macro when you do your job!
>
> Best Regards,
> hanzhu
> Alon wrote:
> > Hello,
> >
> > I’m handling async Irp’s in a Non-PnP driver,
using
> > TdiBuildxxx functions. In some very rare cases, my
> > complition routines are called after my driver is
> > unlaoded.
> > I thought about 2 optional solutions:
> > 1. Referance my driver object before sending Irp
and
> > dereferance it on complition - I think it is a
> > problematic solution since when my driver is in
> > UnloadPending state, when I dereferance the driver
> > object, there might be a context switch right
before
> > the return and than again a crash might happen:
> > NTSTATUS MyCompRoutine()
> > {
> > Some code
> > .
> > .
> > .
> > ObDereferenceObject(MyDriverObject)
> > return STATUS_MORE_PROCESSING_REQUIRED ;
> > code>
> > }
> > 2. Using the IoSetCompletionRoutineEx with my
driver’s
> > device object, the problem: I’m using the
TdiBuildxxx
> > functions which are macros that using
> > IoSetCompletionRoutine and not
> > IoSetCompletionRoutineEx…any idea (except
redefine
> > these macros?)
> >
> > Thanks in advance
> >
> > Alon
> >
> >
> >
> >
> >
> > Yahoo! Mail - PC Magazine Editors’ Choice 2005
> > http://mail.yahoo.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
xxxxx@gmail.com
> > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> >
> >
>
>
>
Yahoo! Mail - PC Magazine Editors’ Choice 2005
http://mail.yahoo.com
Alon,
Independent of how you make the IRPs, if your driver creates IRPs and also
supports unloading, you must ensure that all IRPs that you have created and
have a ‘reference’ to your driver (a CRTN, for instance, in your driver like
yours) have completed and been deallocated before your driver unloads. This
is often accomplished by keeping a reference count (count of pending IO) and
waiting in the Unload handler until that count is zero.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alon
Sent: Wednesday, November 16, 2005 10:22 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoSetCompletionRoutineEx & TdiBuildxxx functions
Hi,
Well, thank for the answer but I didn’t understand the suggestion…you
simly suggest to manually implement these macros (TdiBuildxxx)?
Alon
“hanzhu” wrote in message news:xxxxx@ntdev…
> i think it’s Ok for you to allocate your own Irp
with the routine
> IoAllocateIrp and then you should initialize the
certain
> fileds in the irp and irp stack location. You’d
better follow the
> TdiBuildxxx Macro when you do your job!
>
> Best Regards,
> hanzhu
> Alon wrote:
> > Hello,
> >
> > I’m handling async Irp’s in a Non-PnP driver,
using
> > TdiBuildxxx functions. In some very rare cases, my complition
> > routines are called after my driver is unlaoded.
> > I thought about 2 optional solutions:
> > 1. Referance my driver object before sending Irp
and
> > dereferance it on complition - I think it is a problematic solution
> > since when my driver is in UnloadPending state, when I dereferance
> > the driver object, there might be a context switch right
before
> > the return and than again a crash might happen:
> > NTSTATUS MyCompRoutine()
> > {
> > Some code
> > .
> > .
> > .
> > ObDereferenceObject(MyDriverObject)
> > return STATUS_MORE_PROCESSING_REQUIRED ;
> > code>
> > }
> > 2. Using the IoSetCompletionRoutineEx with my
driver’s
> > device object, the problem: I’m using the
TdiBuildxxx
> > functions which are macros that using IoSetCompletionRoutine and not
> > IoSetCompletionRoutineEx…any idea (except
redefine
> > these macros?)
> >
> > Thanks in advance
> >
> > Alon
> >
> >
> >
> >
> >
> > Yahoo! Mail - PC Magazine Editors’ Choice 2005 http://mail.yahoo.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
xxxxx@gmail.com
> > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> >
> >
>
>
>
Yahoo! Mail - PC Magazine Editors’ Choice 2005 http://mail.yahoo.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@msn.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
The initial NT architecture apparently wasn’t designed with unloading
drivers in mind, so, MS still continues, to this day, to patch holes in it
made by PnP and unloading drivers. The patches I immediately know of are
IoQueueWorkItem, IoSetCompletionRoutineEx and KeFlushQueuedDpcs.
It looks like IoSetCompletionRoutineEx was added to solve exactly your
problem. What makes you keep looking for a different solution (which likely
doesn’t exist, otherwise MS wouldn’t have added IoSetCompletionRoutineEx)?
“Alon” wrote in message news:xxxxx@ntdev…
> Hello,
>
> I’m handling async Irp’s in a Non-PnP driver, using
> TdiBuildxxx functions. In some very rare cases, my
> complition routines are called after my driver is
> unlaoded.
> I thought about 2 optional solutions:
> 1. Referance my driver object before sending Irp and
> dereferance it on complition - I think it is a
> problematic solution since when my driver is in
> UnloadPending state, when I dereferance the driver
> object, there might be a context switch right before
> the return and than again a crash might happen:
> NTSTATUS MyCompRoutine()
> {
> Some code
> .
> .
> .
> ObDereferenceObject(MyDriverObject)
> return STATUS_MORE_PROCESSING_REQUIRED ; > code>
> }
> 2. Using the IoSetCompletionRoutineEx with my driver’s
> device object, the problem: I’m using the TdiBuildxxx
> functions which are macros that using
> IoSetCompletionRoutine and not
> IoSetCompletionRoutineEx…any idea (except redefine
> these macros?)
>
> Thanks in advance
>
> Alon
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors’ Choice 2005
> http://mail.yahoo.com
>
>
If you implement the Tdixxx Macro manually,you can use the
IoSetCompletionRoutineEx.
In my opinion,just like you have pointed out,IoSetCompletionRoutineEx
may be the only method which may
solve this problem.
Best Regards,
hanzhu
Alon wrote:
Hi,
Well, thank for the answer but I didn’t understand the
suggestion…you simly suggest to manually implement
these macros (TdiBuildxxx)?
Alon
“hanzhu” wrote in message
> news:xxxxx@ntdev…
>
>> i think it’s Ok for you to allocate your own Irp
>>
> with the routine
>
>> IoAllocateIrp and then you should initialize the
>>
> certain
>
>> fileds in the irp and irp stack location. You’d
>>
> better follow the
>
>> TdiBuildxxx Macro when you do your job!
>>
>> Best Regards,
>> hanzhu
>> Alon wrote:
>>
>>> Hello,
>>>
>>> I’m handling async Irp’s in a Non-PnP driver,
>>>
> using
>
>>> TdiBuildxxx functions. In some very rare cases, my
>>> complition routines are called after my driver is
>>> unlaoded.
>>> I thought about 2 optional solutions:
>>> 1. Referance my driver object before sending Irp
>>>
> and
>
>>> dereferance it on complition - I think it is a
>>> problematic solution since when my driver is in
>>> UnloadPending state, when I dereferance the driver
>>> object, there might be a context switch right
>>>
> before
>
>>> the return and than again a crash might happen:
>>> NTSTATUS MyCompRoutine()
>>> {
>>> Some code
>>> .
>>> .
>>> .
>>> ObDereferenceObject(MyDriverObject)
>>> return STATUS_MORE_PROCESSING_REQUIRED ;
>>>
> >
>>> code>
>>> }
>>> 2. Using the IoSetCompletionRoutineEx with my
>>>
> driver’s
>
>>> device object, the problem: I’m using the
>>>
> TdiBuildxxx
>
>>> functions which are macros that using
>>> IoSetCompletionRoutine and not
>>> IoSetCompletionRoutineEx…any idea (except
>>>
> redefine
>
>>> these macros?)
>>>
>>> Thanks in advance
>>>
>>> Alon
>>>
>>>
>>>
>>>
>>>
>>> Yahoo! Mail - PC Magazine Editors’ Choice 2005
>>> http://mail.yahoo.com
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>>
> http://www.osronline.com/article.cfm?id=256
>
>>> You are currently subscribed to ntdev as:
>>>
> xxxxx@gmail.com
>
>>> To unsubscribe send a blank email to
>>>
> xxxxx@lists.osr.com
>
>>>
>>>
>>
>>
>
>
>
>
>
> Yahoo! Mail - PC Magazine Editors’ Choice 2005
> http://mail.yahoo.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
If you think that IoSetCompletionRoutineEx will solve the problem, why not
just pass NULL for the completion routine parameter of the TdiBuild… macro
and then call IoSetCompletionRoutineEx afterwards??
Regards
Mark
“hanzhu” wrote in message news:xxxxx@ntdev…
> If you implement the Tdixxx Macro manually,you can use the
> IoSetCompletionRoutineEx.
> In my opinion,just like you have pointed out,IoSetCompletionRoutineEx may
> be the only method which may
> solve this problem.
> Best Regards,
> hanzhu
> Alon wrote:
>> Hi,
>>
>> Well, thank for the answer but I didn’t understand the
>> suggestion…you simly suggest to manually implement
>> these macros (TdiBuildxxx)?
>>
>> Alon
>>
>>
>> “hanzhu” wrote in message
>> news:xxxxx@ntdev…
>>
>>> i think it’s Ok for you to allocate your own Irp
>>>
>> with the routine
>>> IoAllocateIrp and then you should initialize the
>>>
>> certain
>>
>>> fileds in the irp and irp stack location. You’d
>>>
>> better follow the
>>> TdiBuildxxx Macro when you do your job!
>>>
>>> Best Regards,
>>> hanzhu
>>> Alon wrote:
>>>
>>>> Hello,
>>>>
>>>> I’m handling async Irp’s in a Non-PnP driver,
>>>>
>> using
>>
>>>> TdiBuildxxx functions. In some very rare cases, my
>>>> complition routines are called after my driver is
>>>> unlaoded.
>>>> I thought about 2 optional solutions:
>>>> 1. Referance my driver object before sending Irp
>>>>
>> and
>>
>>>> dereferance it on complition - I think it is a
>>>> problematic solution since when my driver is in
>>>> UnloadPending state, when I dereferance the driver
>>>> object, there might be a context switch right
>>>>
>> before
>>
>>>> the return and than again a crash might happen:
>>>> NTSTATUS MyCompRoutine()
>>>> {
>>>> Some code
>>>> .
>>>> .
>>>> .
>>>> ObDereferenceObject(MyDriverObject)
>>>> return STATUS_MORE_PROCESSING_REQUIRED ;
>>>>
>> >>
>>>> code>
>>>> }
>>>> 2. Using the IoSetCompletionRoutineEx with my
>>>>
>> driver’s
>>
>>>> device object, the problem: I’m using the
>>>>
>> TdiBuildxxx
>>
>>>> functions which are macros that using
>>>> IoSetCompletionRoutine and not
>>>> IoSetCompletionRoutineEx…any idea (except
>>>>
>> redefine
>>
>>>> these macros?)
>>>>
>>>> Thanks in advance
>>>>
>>>> Alon
>>>>
>>>>
>>>>
>>>>
>>>> Yahoo! Mail - PC Magazine Editors’
>>>> Choice 2005 http://mail.yahoo.com
>>>>
>>>>
>>>> —
>>>> Questions? First check the Kernel Driver FAQ at
>>>>
>> http://www.osronline.com/article.cfm?id=256
>>
>>>> You are currently subscribed to ntdev as:
>>>>
>> xxxxx@gmail.com
>>
>>>> To unsubscribe send a blank email to
>>>>
>> xxxxx@lists.osr.com
>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> Yahoo! Mail - PC Magazine Editors’
>> Choice 2005 http://mail.yahoo.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@gmail.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
Please remember that IoSetCompletionRoutineEx returns an NTSTATUS, it
*can* fail so you must check the return value. Furthermore, once it is
called, the irp must be sent so that the completion routine is run.
This is b/c IoSetCompletionRoutineEx allocates a piece of memory that is
only freed when the completion routine is executed.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Cook
Sent: Thursday, November 17, 2005 12:54 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoSetCompletionRoutineEx & TdiBuildxxx functions
If you think that IoSetCompletionRoutineEx will solve the problem, why
not
just pass NULL for the completion routine parameter of the TdiBuild…
macro
and then call IoSetCompletionRoutineEx afterwards??
Regards
Mark
“hanzhu” wrote in message news:xxxxx@ntdev…
> If you implement the Tdixxx Macro manually,you can use the
> IoSetCompletionRoutineEx.
> In my opinion,just like you have pointed out,IoSetCompletionRoutineEx
may
> be the only method which may
> solve this problem.
> Best Regards,
> hanzhu
> Alon wrote:
>> Hi,
>>
>> Well, thank for the answer but I didn’t understand the
>> suggestion…you simly suggest to manually implement
>> these macros (TdiBuildxxx)?
>>
>> Alon
>>
>>
>> “hanzhu” wrote in message
>> news:xxxxx@ntdev…
>>
>>> i think it’s Ok for you to allocate your own Irp
>>>
>> with the routine
>>> IoAllocateIrp and then you should initialize the
>>>
>> certain
>>
>>> fileds in the irp and irp stack location. You’d
>>>
>> better follow the
>>> TdiBuildxxx Macro when you do your job!
>>>
>>> Best Regards,
>>> hanzhu
>>> Alon wrote:
>>>
>>>> Hello,
>>>>
>>>> I’m handling async Irp’s in a Non-PnP driver,
>>>>
>> using
>>
>>>> TdiBuildxxx functions. In some very rare cases, my
>>>> complition routines are called after my driver is
>>>> unlaoded.
>>>> I thought about 2 optional solutions:
>>>> 1. Referance my driver object before sending Irp
>>>>
>> and
>>
>>>> dereferance it on complition - I think it is a
>>>> problematic solution since when my driver is in
>>>> UnloadPending state, when I dereferance the driver
>>>> object, there might be a context switch right
>>>>
>> before
>>
>>>> the return and than again a crash might happen:
>>>> NTSTATUS MyCompRoutine()
>>>> {
>>>> Some code
>>>> .
>>>> .
>>>> .
>>>> ObDereferenceObject(MyDriverObject)
>>>> return STATUS_MORE_PROCESSING_REQUIRED ;
>>>>
>> >>
>>>> code>
>>>> }
>>>> 2. Using the IoSetCompletionRoutineEx with my
>>>>
>> driver’s
>>
>>>> device object, the problem: I’m using the
>>>>
>> TdiBuildxxx
>>
>>>> functions which are macros that using
>>>> IoSetCompletionRoutine and not
>>>> IoSetCompletionRoutineEx…any idea (except
>>>>
>> redefine
>>
>>>> these macros?)
>>>>
>>>> Thanks in advance
>>>>
>>>> Alon
>>>>
>>>>
>>>>
>>>>
>>>> Yahoo! Mail - PC Magazine
Editors’
>>>> Choice 2005 http://mail.yahoo.com
>>>>
>>>>
>>>> —
>>>> Questions? First check the Kernel Driver FAQ at
>>>>
>> http://www.osronline.com/article.cfm?id=256
>>
>>>> You are currently subscribed to ntdev as:
>>>>
>> xxxxx@gmail.com
>>
>>>> To unsubscribe send a blank email to
>>>>
>> xxxxx@lists.osr.com
>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> Yahoo! Mail - PC Magazine Editors’
>> Choice 2005 http://mail.yahoo.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@gmail.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
As I know sprintf() as well as snprintf(), vsprintf() and vsnprintf()
function is used to print formated line into memory buffer. To use them in
Linux kernel driver one must include the header file. In
Windows the ntoskrnl.exe exports these functions.
–
Dmitry
18 November 2005 06:21, Doron Holan wrote:
> Please remember that IoSetCompletionRoutineEx returns an NTSTATUS, it
> can fail so you must check the return value. Furthermore, once it is
> called, the irp must be sent so that the completion routine is run.
> This is b/c IoSetCompletionRoutineEx allocates a piece of memory that is
> only freed when the completion routine is executed.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Cook
> Sent: Thursday, November 17, 2005 12:54 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] IoSetCompletionRoutineEx & TdiBuildxxx functions
>
> If you think that IoSetCompletionRoutineEx will solve the problem, why
> not
> just pass NULL for the completion routine parameter of the TdiBuild…
> macro
> and then call IoSetCompletionRoutineEx afterwards??
>
> Regards
>
> Mark
>
>
>
> “hanzhu” wrote in message news:xxxxx@ntdev…
> > If you implement the Tdixxx Macro manually,you can use the
> > IoSetCompletionRoutineEx.
> > In my opinion,just like you have pointed out,IoSetCompletionRoutineEx
> may
> > be the only method which may
> > solve this problem.
> > Best Regards,
> > hanzhu
> > Alon wrote:
> >> Hi,
> >>
> >> Well, thank for the answer but I didn’t understand the
> >> suggestion…you simly suggest to manually implement
> >> these macros (TdiBuildxxx)?
> >>
> >> Alon
> >>
> >>
> >> “hanzhu” wrote in message
> >> news:xxxxx@ntdev…
> >>
> >>> i think it’s Ok for you to allocate your own Irp
> >>>
> >> with the routine
> >>> IoAllocateIrp and then you should initialize the
> >>>
> >> certain
> >>
> >>> fileds in the irp and irp stack location. You’d
> >>>
> >> better follow the
> >>> TdiBuildxxx Macro when you do your job!
> >>>
> >>> Best Regards,
> >>> hanzhu
> >>> Alon wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> I’m handling async Irp’s in a Non-PnP driver,
> >>>>
> >> using
> >>
> >>>> TdiBuildxxx functions. In some very rare cases, my
> >>>> complition routines are called after my driver is
> >>>> unlaoded.
> >>>> I thought about 2 optional solutions:
> >>>> 1. Referance my driver object before sending Irp
> >>>>
> >> and
> >>
> >>>> dereferance it on complition - I think it is a
> >>>> problematic solution since when my driver is in
> >>>> UnloadPending state, when I dereferance the driver
> >>>> object, there might be a context switch right
> >>>>
> >> before
> >>
> >>>> the return and than again a crash might happen:
> >>>> NTSTATUS MyCompRoutine()
> >>>> {
> >>>> Some code
> >>>> .
> >>>> .
> >>>> .
> >>>> ObDereferenceObject(MyDriverObject)
> >>>> return STATUS_MORE_PROCESSING_REQUIRED ;
> >>>>
> >> > >>
> >>>> code>
> >>>> }
> >>>> 2. Using the IoSetCompletionRoutineEx with my
> >>>>
> >> driver’s
> >>
> >>>> device object, the problem: I’m using the
> >>>>
> >> TdiBuildxxx
> >>
> >>>> functions which are macros that using
> >>>> IoSetCompletionRoutine and not
> >>>> IoSetCompletionRoutineEx…any idea (except
> >>>>
> >> redefine
> >>
> >>>> these macros?)
> >>>>
> >>>> Thanks in advance
> >>>>
> >>>> Alon
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Yahoo! Mail - PC Magazine
> Editors’
> >>>> Choice 2005 http://mail.yahoo.com
> >>>>
> >>>>
> >>>> —
> >>>> Questions? First check the Kernel Driver FAQ at
> >>>>
> >> http://www.osronline.com/article.cfm?id=256
> >>
> >>>> You are currently subscribed to ntdev as:
> >>>>
> >> xxxxx@gmail.com
> >>
> >>>> To unsubscribe send a blank email to
> >>>>
> >> xxxxx@lists.osr.com
> >>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> Yahoo! Mail - PC Magazine Editors’
>
> >> Choice 2005 http://mail.yahoo.com
> >>
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at
> >> http://www.osronline.com/article.cfm?id=256
> >>
> >> You are currently subscribed to ntdev as: xxxxx@gmail.com
> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>
> >>
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>