Can invalid thread handles in C# be a sign of unmanaged memory corruption?

Question

We have a C# service that has started failing in very odd ways around thread handles. Specifically calls to EventWaitHandle.Reset, ReaderWriterLock calls, and other similar threading calls are randomly blowing up with Invalid Handle errors deep in the stack. These are calls that are definately supposed to work. Could this be a sign of memory corruption? If so we're a bit confused how this is the only symptom and not crashing. We have COM objects with C++ code where we do HeapFree's, and also have some managed code calling into FreeHGlobal so are suspicious. Has anyone experienced anything like this with problems manifesting themselves seemingly localized to thread primitives?

Answer 1

I've not seen this particular symptom. But I think it's conceivable that the cause is as you suspect - there's no rule that says that memory corruption must cause crashes.

Imagine that you had a data structure like this

     buffer[100];
     threadHandle;

And you had a simple out by one error in the code filling the buffer. Now your thread handle is defective and presumably you'd get the symptom you see.

I don't know your environment well (I'm Linux/Java these days) but could another cause be using a threadHandle after the thread has terminated? So the handle is indeed no longer valid? Some sort of race condition in your termination code?

Answer 2

Turns out this was a PInvoke issue. We were incorrectly PInvoking a Thread Handle to the C# SafeFileHandle wrapper, which under the write conditions would invalidate the the thread handle which was later re-allocated by other threads and a giant mess ensued. THus the moral of the story, be very very careful using .net Handle wrapper classes in P-Invoke.