We are seeing the same thing on Unreal version 4.22.3 and Visual Studio 15.9.16. It also occurs when using Visual Studio 15.9.17, but it doesn’t occur with Visual Studio 15.9.15.
I tracked down the issue to how the optimized code handles the constant offset that FWindowsPlatformTime::Seconds() uses. In the unoptimized code, it adds the value from static memory, but in the optimized code, it saves off that static value into an xmm register at the start of the outer while loop and adds the register value each time later. (Eg. addsd xmm8,mmword ptr [__real@4170000000000000 (07FFEE0D792B0h)] vs addsd xmm8,xmm9)
Depending on which xmm register the compiler decides to use to store the constant, at a certain point during execution, that xmm register gets set to 0. If that point in time happens to be between when InnerLoopBegin and InnerLoopEnd are calculated, InnerLoopEnd will be 16777216 too small (because the offset being used is now 0 instead) and cause the thread to sleep for practically forever.
I can get it to work or not work by adding checkf calls which cause the xmm register being used to change. My guess is that the VS version changes or TLS library changes are just enough to cause the compiler to change the register being used to something that isn’t going to get reset and so are just masking the underlying issue.
My best guesses are that this is a compiler bug and it’s not realizing that some nested function call is going to modify that register, or that somehow during a context switch, the saved off values of the registers of this thread get stomped on.