There are two reasons that can cause GetQueuedCompletionStatus() to fail (return FALSE), the first is because the completion port handle associated with it is closed while the call is outstanding, this will be the case if lpOverlapped is NULL.
The second reason (which is the one I care about) is if the IO operation (for example: WSARecv()) fails. This is what the documentation says about this situation:
If *lpOverlapped is not NULL and the function dequeues a completion packet for a failed I/O operation from the completion port, the function stores information about the failed operation in the variables pointed to by lpNumberOfBytes, lpCompletionKey, and lpOverlapped. To get extended error information, call GetLastError.
I do not find this to be very clear as to what the values of lpNumberOfBytes, lpCompletionKey, and lpOverlapped will be. Will these parameters contain the same values that I supplied when calling WSARecv()? I suppose that this is more likely because how else am I suppose to know what IO operation caused the failure!
If an I/O operation fails then lpCompletionKey and lpOverlapped will be the values that were supplied when you initiated the I/O operation using whichever API was used (WSASend(), WSARecv(), etc.). This is how you identify the 'per device' data and the 'per operation' data for the I/O operation in question.
lpNumberOfBytes is likely to be zero in error situations though I tend to deal with it the same as for the non error case as I never use the resulting value (or the buffer contents) during error handling anyway.