Hello,
I’ve tested my stuff by using Driver Verifier on Windows 2000. A user
application sends an IOCTL request and a Dispatch routine captures an IRP.
The Dispatch routine calls MmGetSystemAddressForMdlSafe to get a virtual
address. It also checks if the returned address equals NULL. If it is, the
Dispatch routine completes the IRP.
The Driver Verifier creates a condition to return NULL pointer when the
driver calls MmGetSystemAddressForMdlSafe. When the Dispatch routine gets
NULL pointer it completes an IRP but my user application doesn’t get an
event from the I/O Manager signaling of IRP’s completion.
Does anybody get such problem?
Did you set the error code in Irp->IoStuats.Status and call
IoCompleteRequest in addition to returning an error code?
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Igor Sharovar
Sent: Thursday, April 06, 2006 6:25 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Problem of using the Driver Verifier
Hello,
I’ve tested my stuff by using Driver Verifier on Windows 2000. A user
application sends an IOCTL request and a Dispatch routine captures an
IRP.
The Dispatch routine calls MmGetSystemAddressForMdlSafe to get a virtual
address. It also checks if the returned address equals NULL. If it is,
the
Dispatch routine completes the IRP.
The Driver Verifier creates a condition to return NULL pointer when the
driver calls MmGetSystemAddressForMdlSafe. When the Dispatch routine
gets
NULL pointer it completes an IRP but my user application doesn’t get an
event from the I/O Manager signaling of IRP’s completion.
Does anybody get such problem?
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
Yes, I set up Irp->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES
and call IoCompleteRequest.
I emulate this problem without running the Device Verifier and I get the
same problem -
a Windows application doesn’t get an Event.
“Doron Holan” wrote in message
news:xxxxx@ntdev…
Did you set the error code in Irp->IoStuats.Status and call
IoCompleteRequest in addition to returning an error code?
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Igor Sharovar
Sent: Thursday, April 06, 2006 6:25 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Problem of using the Driver Verifier
Hello,
I’ve tested my stuff by using Driver Verifier on Windows 2000. A user
application sends an IOCTL request and a Dispatch routine captures an
IRP.
The Dispatch routine calls MmGetSystemAddressForMdlSafe to get a virtual
address. It also checks if the returned address equals NULL. If it is,
the
Dispatch routine completes the IRP.
The Driver Verifier creates a condition to return NULL pointer when the
driver calls MmGetSystemAddressForMdlSafe. When the Dispatch routine
gets
NULL pointer it completes an IRP but my user application doesn’t get an
event from the I/O Manager signaling of IRP’s completion.
Does anybody get such problem?
—
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
Then you have a bug in your dispatch routine Irp processing.
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Igor Sharovar
Sent: Thursday, April 06, 2006 5:10 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Problem of using the Driver VerifierYes, I set up Irp->IoStatus.Status =
STATUS_INSUFFICIENT_RESOURCES and call IoCompleteRequest.
I emulate this problem without running the Device Verifier
and I get the same problem - a Windows application doesn’t
get an Event.“Doron Holan” wrote in message
> news:xxxxx@ntdev…
> Did you set the error code in Irp->IoStuats.Status and call
> IoCompleteRequest in addition to returning an error code?
>
> d
>
> – I can spell, I just can’t type.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Igor Sharovar
> Sent: Thursday, April 06, 2006 6:25 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Problem of using the Driver Verifier
>
> Hello,
> I’ve tested my stuff by using Driver Verifier on Windows
> 2000. A user application sends an IOCTL request and a
> Dispatch routine captures an IRP.
> The Dispatch routine calls MmGetSystemAddressForMdlSafe to
> get a virtual address. It also checks if the returned address
> equals NULL. If it is, the Dispatch routine completes the IRP.
> The Driver Verifier creates a condition to return NULL
> pointer when the driver calls MmGetSystemAddressForMdlSafe.
> When the Dispatch routine gets NULL pointer it completes an
> IRP but my user application doesn’t get an event from the I/O
> Manager signaling of IRP’s completion.
> Does anybody get such problem?
>
>
>
> —
> 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
>
It works fine when I replaced a returned NTSTATUS as STATUS_SUCCESS.
Does it mean that an IRP with an error never return to a user-mode
application?
“Mark Roddy” wrote in message news:xxxxx@ntdev…
> Then you have a bug in your dispatch routine Irp processing.
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Igor Sharovar
> > Sent: Thursday, April 06, 2006 5:10 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] Problem of using the Driver Verifier
> >
> > Yes, I set up Irp->IoStatus.Status =
> > STATUS_INSUFFICIENT_RESOURCES and call IoCompleteRequest.
> > I emulate this problem without running the Device Verifier
> > and I get the same problem - a Windows application doesn’t
> > get an Event.
> >
> >
> >
> >
> > “Doron Holan” wrote in message
> > news:xxxxx@ntdev…
> > Did you set the error code in Irp->IoStuats.Status and call
> > IoCompleteRequest in addition to returning an error code?
> >
> > d
> >
> > – I can spell, I just can’t type.
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Igor Sharovar
> > Sent: Thursday, April 06, 2006 6:25 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Problem of using the Driver Verifier
> >
> > Hello,
> > I’ve tested my stuff by using Driver Verifier on Windows
> > 2000. A user application sends an IOCTL request and a
> > Dispatch routine captures an IRP.
> > The Dispatch routine calls MmGetSystemAddressForMdlSafe to
> > get a virtual address. It also checks if the returned address
> > equals NULL. If it is, the Dispatch routine completes the IRP.
> > The Driver Verifier creates a condition to return NULL
> > pointer when the driver calls MmGetSystemAddressForMdlSafe.
> > When the Dispatch routine gets NULL pointer it completes an
> > IRP but my user application doesn’t get an event from the I/O
> > Manager signaling of IRP’s completion.
> > Does anybody get such problem?
> >
> >
> >
> > —
> > 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
> >
>
>
>
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Igor Sharovar
Sent: Friday, April 07, 2006 1:38 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Problem of using the Driver VerifierIt works fine when I replaced a returned NTSTATUS as STATUS_SUCCESS.
Does it mean that an IRP with an error never return to a
user-mode application?
No, of course not. You have a bug in your code. Is your driver stand alone
or layered below other drivers? Do you have a completion handler for the
IRP? Have you called IoMarkIrpPending on the IRP? Did you set
Irp.IoStatus.Status correctly?
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
My driver stands alone. The driver doesn’t have a completion routine. When
the driver wants to postpone an IRP it calls IoMarkIrpPending not
IoCompleteRequest. The driver sets status in an IRP by
Irp.IoStatus.Status = status;
I agree the driver’s code has a bug, but I don’t really understand why just
replacing a returned status the driver behaves differently. When it
completes an IRP with an error NTSTATUS = error the IRP doesn’t go to an
application, but the IRP with NTSTATUS = STATUS_SUCCESS triggers an event
in a user-mode application.
“Mark Roddy” wrote in message news:xxxxx@ntdev…
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Igor Sharovar
> > Sent: Friday, April 07, 2006 1:38 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] Problem of using the Driver Verifier
> >
> > It works fine when I replaced a returned NTSTATUS as STATUS_SUCCESS.
> >
> > Does it mean that an IRP with an error never return to a
> > user-mode application?
> >
>
>
> No, of course not. You have a bug in your code. Is your driver stand alone
> or layered below other drivers? Do you have a completion handler for the
> IRP? Have you called IoMarkIrpPending on the IRP? Did you set
> Irp.IoStatus.Status correctly?
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
>
>
At this point, I doubt that asking questions is going to be very
fruitful (it certainly won’t be very efficient). If you post your
dispatch routine code people might be able to find the problem…
Igor Sharovar wrote:
My driver stands alone. The driver doesn’t have a completion routine. When
the driver wants to postpone an IRP it calls IoMarkIrpPending not
IoCompleteRequest. The driver sets status in an IRP byIrp.IoStatus.Status = status;
I agree the driver’s code has a bug, but I don’t really understand why just
replacing a returned status the driver behaves differently. When it
completes an IRP with an error NTSTATUS = error the IRP doesn’t go to an
application, but the IRP with NTSTATUS = STATUS_SUCCESS triggers an event
in a user-mode application.“Mark Roddy” wrote in message news:xxxxx@ntdev…
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Igor Sharovar
>>> Sent: Friday, April 07, 2006 1:38 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: Re:[ntdev] Problem of using the Driver Verifier
>>>
>>> It works fine when I replaced a returned NTSTATUS as STATUS_SUCCESS.
>>>
>>> Does it mean that an IRP with an error never return to a
>>> user-mode application?
>>>
>>
>> No, of course not. You have a bug in your code. Is your driver stand alone
>> or layered below other drivers? Do you have a completion handler for the
>> IRP? Have you called IoMarkIrpPending on the IRP? Did you set
>> Irp.IoStatus.Status correctly?
>>
>> =====================
>> Mark Roddy DDK MVP
>> Windows 2003/XP/2000 Consulting
>> Hollis Technology Solutions 603-321-1032
>> www.hollistech.com
>>
>>
>>
>
>
>
–
Ray
Igor Sharovar wrote:
My driver stands alone. The driver doesn’t have a completion routine. When
the driver wants to postpone an IRP it calls IoMarkIrpPending not
IoCompleteRequest. The driver sets status in an IRP byIrp.IoStatus.Status = status;
And then, do you do
return Irp.IoStatus.Status;
or:
return status;
Or do you make the common mistake of:
return STATUS_SUCCESS;
?
I agree the driver’s code has a bug, but I don’t really understand why just
replacing a returned status the driver behaves differently. When it
completes an IRP with an error NTSTATUS = error the IRP doesn’t go to an
application, but the IRP with NTSTATUS = STATUS_SUCCESS triggers an event
in a user-mode application.
So, the app is using overlapped I/O? Are you returning this error
immediate, in the ioctl handler, or at some later time? Is the app
handling the case where DeviceIoControl returns an error, or does it
ALWAYS WaitForSingleObject on the event?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> And then, do you do
return Irp.IoStatus.Status;
Would be bad b/c the Irp is gone b/c you would have had to previously
called IoCompleteRequest on the Irp.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, April 07, 2006 5:33 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem of using the Driver Verifier
Igor Sharovar wrote:
My driver stands alone. The driver doesn’t have a completion routine.
When
the driver wants to postpone an IRP it calls IoMarkIrpPending not
IoCompleteRequest. The driver sets status in an IRP byIrp.IoStatus.Status = status;
And then, do you do
return Irp.IoStatus.Status;
or:
return status;
Or do you make the common mistake of:
return STATUS_SUCCESS;
?
I agree the driver’s code has a bug, but I don’t really understand why
just
replacing a returned status the driver behaves differently. When it
completes an IRP with an error NTSTATUS = error the IRP doesn’t go to
an
application, but the IRP with NTSTATUS = STATUS_SUCCESS triggers an
event
in a user-mode application.
So, the app is using overlapped I/O? Are you returning this error
immediate, in the ioctl handler, or at some later time? Is the app
handling the case where DeviceIoControl returns an error, or does it
ALWAYS WaitForSingleObject on the event?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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 understand what you mean. I think the bug in Windows application.
A Windows application uses overlapped I/O and doesn’t check a returned
status of DeviceIoControl. It goes directly to WaitForSingleObject.
Doesn it mean that if an IRP returns an errors NTSTATUS DeviceIoControl
returns zero?
“Doron Holan” wrote in message
news:xxxxx@ntdev…
> And then, do you do
> return Irp.IoStatus.Status;
Would be bad b/c the Irp is gone b/c you would have had to previously
called IoCompleteRequest on the Irp.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, April 07, 2006 5:33 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem of using the Driver Verifier
Igor Sharovar wrote:
>My driver stands alone. The driver doesn’t have a completion routine.
When
>the driver wants to postpone an IRP it calls IoMarkIrpPending not
>IoCompleteRequest. The driver sets status in an IRP by
>
>Irp.IoStatus.Status = status;
>
>
And then, do you do
return Irp.IoStatus.Status;
or:
return status;
Or do you make the common mistake of:
return STATUS_SUCCESS;
?
>I agree the driver’s code has a bug, but I don’t really understand why
just
>replacing a returned status the driver behaves differently. When it
>completes an IRP with an error NTSTATUS = error the IRP doesn’t go to
an
>application, but the IRP with NTSTATUS = STATUS_SUCCESS triggers an
event
>in a user-mode application.
>
>
So, the app is using overlapped I/O? Are you returning this error
immediate, in the ioctl handler, or at some later time? Is the app
handling the case where DeviceIoControl returns an error, or does it
ALWAYS WaitForSingleObject on the event?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
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
Igor Sharovar wrote:
I understand what you mean. I think the bug in Windows application.
A Windows application uses overlapped I/O and doesn’t check a returned
status of DeviceIoControl. It goes directly to WaitForSingleObject.
Four things can happen with DeviceIoControl:
* Return success immediately
* Return an error immediately
* Pend, return success later
* Pend, return an error later
You need to handle all four cases.
if( DeviceIoControl( … ) )
{
// Immediate success, no need to wait.
}
else
{
ULONG err = GetLastError();
if( err != ERROR_IO_PENDING )
{
// Immediate error, no need to wait.
}
else
{
WaitForSingleObject( ol.hEvent, INFINITE );
if( GetOverlappedResult( handle, ol, &dwActual, TRUE ) )
{
// Deferred operation, now succeeded.
}
else
{
// Deferred operation, ended in error.
}
Doesn it mean that if an IRP returns an errors NTSTATUS DeviceIoControl
returns zero?
Yes. Note that, if you specify an OVERLAPPED structure, which you seem
to be doing, then “pending” is considered an error, and DeviceIoControl
will return zero. You need to use GetLastError to figure out whether it
was an error, or a deferral.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank a lot Tim,
Your explanation is very useful. As I expect the problem is how a Windows
application communicates with the driver. My Windows application has more
simple error checking than you described.
Thank again.
Igor
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Igor Sharovar wrote:
>
> >I understand what you mean. I think the bug in Windows application.
> >
> >A Windows application uses overlapped I/O and doesn’t check a returned
> >status of DeviceIoControl. It goes directly to WaitForSingleObject.
> >
> >
>
> Four things can happen with DeviceIoControl:
> * Return success immediately
> * Return an error immediately
> * Pend, return success later
> * Pend, return an error later
>
> You need to handle all four cases.
>
> if( DeviceIoControl( … ) )
> {
> // Immediate success, no need to wait.
> }
> else
> {
> ULONG err = GetLastError();
> if( err != ERROR_IO_PENDING )
> {
> // Immediate error, no need to wait.
> }
> else
> {
> WaitForSingleObject( ol.hEvent, INFINITE );
> if( GetOverlappedResult( handle, ol, &dwActual, TRUE ) )
> {
> // Deferred operation, now succeeded.
> }
> else
> {
> // Deferred operation, ended in error.
> }
>
> >Doesn it mean that if an IRP returns an errors NTSTATUS DeviceIoControl
> >returns zero?
> >
> >
>
> Yes. Note that, if you specify an OVERLAPPED structure, which you seem
> to be doing, then “pending” is considered an error, and DeviceIoControl
> will return zero. You need to use GetLastError to figure out whether it
> was an error, or a deferral.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
Tim,
I have a question.
Can I omit to call WaitForSingleObject( ol.hEvent, INFINITE ) because
GetOverlappedResult( ) is called
with bWait == TRUE? GetOverlappedResult() should waits until an event
trigered, doesn’t it?
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Igor Sharovar wrote:
>
> >I understand what you mean. I think the bug in Windows application.
> >
> >A Windows application uses overlapped I/O and doesn’t check a returned
> >status of DeviceIoControl. It goes directly to WaitForSingleObject.
> >
> >
>
> Four things can happen with DeviceIoControl:
> * Return success immediately
> * Return an error immediately
> * Pend, return success later
> * Pend, return an error later
>
> You need to handle all four cases.
>
> if( DeviceIoControl( … ) )
> {
> // Immediate success, no need to wait.
> }
> else
> {
> ULONG err = GetLastError();
> if( err != ERROR_IO_PENDING )
> {
> // Immediate error, no need to wait.
> }
> else
> {
> WaitForSingleObject( ol.hEvent, INFINITE );
> if( GetOverlappedResult( handle, ol, &dwActual, TRUE ) )
> {
> // Deferred operation, now succeeded.
> }
> else
> {
> // Deferred operation, ended in error.
> }
>
> >Doesn it mean that if an IRP returns an errors NTSTATUS DeviceIoControl
> >returns zero?
> >
> >
>
> Yes. Note that, if you specify an OVERLAPPED structure, which you seem
> to be doing, then “pending” is considered an error, and DeviceIoControl
> will return zero. You need to use GetLastError to figure out whether it
> was an error, or a deferral.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
Looking at GetOverlappedResult disassembly answers this - yes, you can omit
the wait in this case. It calls the wait itself.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Igor Sharovar”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, April 20, 2006 10:13 PM
Subject: Re:[ntdev] Problem of using the Driver Verifier
> Tim,
>
> I have a question.
> Can I omit to call WaitForSingleObject( ol.hEvent, INFINITE ) because
> GetOverlappedResult( ) is called
> with bWait == TRUE? GetOverlappedResult() should waits until an event
> trigered, doesn’t it?
>
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
> > Igor Sharovar wrote:
> >
> > >I understand what you mean. I think the bug in Windows application.
> > >
> > >A Windows application uses overlapped I/O and doesn’t check a returned
> > >status of DeviceIoControl. It goes directly to WaitForSingleObject.
> > >
> > >
> >
> > Four things can happen with DeviceIoControl:
> > * Return success immediately
> > * Return an error immediately
> > * Pend, return success later
> > * Pend, return an error later
> >
> > You need to handle all four cases.
> >
> > if( DeviceIoControl( … ) )
> > {
> > // Immediate success, no need to wait.
> > }
> > else
> > {
> > ULONG err = GetLastError();
> > if( err != ERROR_IO_PENDING )
> > {
> > // Immediate error, no need to wait.
> > }
> > else
> > {
> > WaitForSingleObject( ol.hEvent, INFINITE );
> > if( GetOverlappedResult( handle, ol, &dwActual, TRUE ) )
> > {
> > // Deferred operation, now succeeded.
> > }
> > else
> > {
> > // Deferred operation, ended in error.
> > }
> >
> > >Doesn it mean that if an IRP returns an errors NTSTATUS DeviceIoControl
> > >returns zero?
> > >
> > >
> >
> > Yes. Note that, if you specify an OVERLAPPED structure, which you seem
> > to be doing, then “pending” is considered an error, and DeviceIoControl
> > will return zero. You need to use GetLastError to figure out whether it
> > was an error, or a deferral.
> >
> > –
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
>
>
>
> —
> 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
Igor Sharovar wrote:
I have a question.
Can I omit to call WaitForSingleObject( ol.hEvent, INFINITE ) because
GetOverlappedResult( ) is called
with bWait == TRUE? GetOverlappedResult() should waits until an event
trigered, doesn’t it?
Yes, exactly right.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.