GetQueuedCompletionStatus error 998

NTFSD
1

Hi,
I found an old topic on the list about this error but without a real solution or an explanation of the problem (http://www.osronline.com/showThread.cfm?link=108500). My problem is exactly the same. I hope since that time some of you could know something new.
I am testing the same communication design of the scanner sample and GetQueuedCompletionStatus is failing with last error 998 when the system is stressed.
Any new ideas???
Thanks in advance,
Yohamnes

2

We see the same problem. The interesting thing is that GetQueuedCompletionStatus returns FALSE but the overlapped structure is valid.

So, we just requeue the request associated with the overlapped structure (FilterGetMessage) and everything appears to work.

Alnoor

3

If the lpOverlapped out parameter to GetQueuedCompletionStatus is non-NULL when GetQueuedCompletionStatus returns FALSE that means that an I/O completion packet was dequeued, but the I/O operation resulted in an error. GetLastError() in that case returns the Winerror equivalent to the value that the I/O operation’s IO_STATUS_BLOCK.Status field had. If lpOverlapped is NULL when GetQueuedCompletionStatus returns FALSE that means no completion packet was dequeued and typically means there was an error processing the parameters or the CompletionPort handle was invalid in some way.

I imagine this explains why Alnoor sees a retry succeed when lpOverlapped is non-NULL; under heavy stress the first I/O request failed, but it succeeds when retried.

– Christian [MSFT]

4

Thanks to both of you for your reply.
So, summarizing what you must not do in this case is finish the thread ( the completion port handle is still valid) .
My solution was ignore this error and continue waiting in GetQueuedCompletionStatus(). I think the full solution is to check also for the overlapped structure and if it is not null requeue again the packet like Alnoor already does.
Best regards,
Yohamnes

5

This error generally indicates you have passed in a bad address. Can you
show the actual code you are using?
joe

Thanks to both of you for your reply.
So, summarizing what you must not do in this case is finish the thread (
the completion port handle is still valid) .
My solution was ignore this error and continue waiting in
GetQueuedCompletionStatus(). I think the full solution is to check also
for the overlapped structure and if it is not null requeue again the
packet like Alnoor already does.
Best regards,
Yohamnes

NTFSD is sponsored by OSR

For our schedule of debugging and file system 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

6

I am only testing the scanner sample under a big stress. Testing with the sample you should got the same results. Others peoples in the foro refer the same exact problem with that function.
Thanks,
Yohamnes