This sounds awfully similar to something I hit when proving out the llgs work and testing vs. OS X. At the time last year, OS X was not guaranteeing thread state info reliability at the SB level, which I think I had working for Linux, but was then getting diverging results on tests that checked thread state at certain points.

What I'm not remembering is if it really was a OS-related issue or a propagation issue on the lldb infrastructure side. (I seem to think Linux could get it right because we were moving to a thread state coordinator state machine that always knew the state of threads, whereas on OS X I think it was query based and the state wasn't automatically known? Something like that). If we end up having multiple OSes (possibly Windows) that have trouble with that, we might want to rethink how (if?) we expose it, or if we can just fix it, do that.

Yea I've seen a lot of tests that are xfailed with comments saying "thread states are not properly maintained". So it sounds like, even if we can get this working on Windows, there's some underlying issue that would be great to fix on the LLDB side. I didn't investigate this long enough to come to a conclusion about what the problem might be on the Windows side, because right now I'm just trying to get down to a clean run of the test suite. I suspect there's at least some improvements we could make on the Windows side, but it's very possible that a more comprehensive fix is needed.