Is this really needed?

As far as I can tell, and really really don't quote me on this, but as far as I can tell, Sleep and all other "waitable" functions are all based on KiCheckWaitNext which uses QueryInterruptTimePrecise for calls like Sleep and QueryUnbiasedInterruptTime for APIs like WaitForSingleObject.

The difference between the Query*Time APIs that have unbiased in their name is:

The unbiased interrupt-time count does not include time the system spends in sleep or hibernation.

In other words, as far as I can tell, Sleep sleeps in "real time" and not in "run time", so if our CIs, which probably run on some very cheap spot instances, get suspended quite often, Sleep will effectively be skipped every time, without the OS and the apps on it really progressing at all.

I would thus try and fix it by calling this instead:

WaitForSingleObject(GetCurrentThread(), 1000);

Using exponential backoff with 5-10 retries would probably be a good idea anyways though. A good initial delay would probably be something like 10ms?, so that it doesn't throttle the tests too much on our fast developer machines. (Could you test on your own PC how many ms are enough so that it never hits retry when running locally?) Something like this:

// This will wait for up to 32s in total (from 10ms to 163840ms)
for (DWORD delay = 10; delay < 30000; delay *= 2)
{
    // ...
    if (succeeded)
    {
        return true;
    }

    WaitForSingleObject(GetCurrentThread(), delay);
}

VERIFY_FAILED(); // what's the right call again?
return false;

BTW should we really reopen the CRT handles inside the loop? Seems like we should only do that once before the loop...

Another option would be to just return true above instead of breaking. That way you can blindly VERIFY_FAIL() here.