I have the same problem. It's a small bug in Qt. It won't make much trouble, but It's annoying. The problem ist hier:

int loops = (handlesCopy.count() / MAXIMUM_WAIT_OBJECTS) + 1, offset, count;
...
int loop = 0;
do {
offset = loop * MAXIMUM_WAIT_OBJECTS;
count = qMin(handlesCopy.count() - offset, MAXIMUM_WAIT_OBJECTS);
ret = WaitForMultipleObjects(count, handlesCopy.constData() + offset, false, 100);
loop = (loop + 1) % loops;
} while (ret == WAIT_TIMEOUT);


If handlesCopy.count() % MAXIMUM_WAIT_OBJECTS == 0, then the last call to WaitForMultipleObjects will have count == 0.

For example, if you habe 64 (== MAXIMUM_WAIT_OBJECTS) Threads, then loop will be 2. The first call will habe 64 handles. And the second one will habe 0 handles.

But see MSDN for WaitForMultipleObjects:

nCount [in]

The number of object handles in the array pointed to by lpHandles. The maximum number of object handles is MAXIMUM_WAIT_OBJECTS. This parameter cannot be zero.


The nCount CAN NOT BE ZERO. That is why you get this message.

The possible work around is not to call QThread::currentThread() in threads started not over QThread. Because in this case the adopted threads are used. In my case, I used Recursive QMutex. This also leads to calling QThreadData::current().

So in my case, I will just not use QMutex classe in non-QThread threads.

Why is this bug STILL OPEN AFTER 3 YEARS ???? :-(

The fix would be


int loops = (handlesCopy.count() / MAXIMUM_WAIT_OBJECTS), offset, count;
if ( (handlesCopy.count() % MAXIMUM_WAIT_OBJECTS) > 0 )
{
loops++
}