On Thu Aug 3 15:48:53 2023 +0000, Zebediah Figura wrote:
@zfigura I think this is unfortunately a case of the application
looking at the internal state of something that's supposed to be opaque.
The application here is specifically creating a `SRWLOCK`,
manipulating its internal state not through the APIs, then calling `ReleaseSRWLockExclusive` and inspecting the result.
And if the result is different from what it expects, it opens a
KeyedEvent for `"\KernelObjects\CritSecOutOfMemoryEvent"`, and waits on it in a loop.
I can't tell you why it's doing that.
That makes some amount of sense (not that I know why the application thinks it needs to mess with lock state manually, but, well, It Happens). In that case I suppose the answer is that we probably need to change our SRW lock implementation to match Windows'.
I feel that is a bit overkill for a single application, which is using the lock in an invalid way anyway.