\nInternally, a critical section is a bunch of counters and flags,\nand possibly an event.\n(Note that the internal structure of a critical section is subject\nto change at any time—in fact, it changed between\nWindows XP and Windows 2003.\nThe information provided here is therefore intended for troubleshooting\nand debugging purposes and not for production use.)\nAs long as there is no contention, the counters and flags are\nsufficient because nobody has had to wait for the critical section\n(and therefore nobody had to be woken up when the critical section\nbecame available).\n<\/p>\n
\nIf a thread needs to be blocked because the critical section it wants\nis already owned by another thread,\nthe kernel creates an event for the critical section\n(if there isn’t one already) and waits on it.\nWhen the owner of the critical section finally releases it,\nthe event is signaled, thereby alerting all the waiters that the\ncritical section is now available and they should try to enter it\nagain.\n(If there is more than one waiter, then only one will actually\nenter the critical section and the others will return to the wait\nloop.)\n<\/p>\n
\nIf you get an invalid handle exception in\n \nNow you get to use your brain to come up with reasons why this might be.\n<\/p>\n \nOne possibility is that the critical section has been corrupted,\nand the memory that normally holds the event handle has been\noverwritten with some other value that happens not to be a\nvalid handle.\n<\/p>\n \nAnother possibility is that some other piece of code passed\nan uninitialized variable to the \nOf course, the problem might be that the critical section is not\nvalid because it was never initialized in the first place.\nThe values in the fields are just uninitialized garbage,\nand when you try to leave this uninitialized critical section,\nthat garbage gets used as an event handle, raising the invalid\nhandle exception.\n<\/p>\n \nThen again, the problem might be that the critical section is\nnot valid because it has already been destroyed.\nFor example, one thread might have code that goes like this:\n<\/p>\n \nWhile that thread is busy doing stuff,\nanother thread calls\n \nAll of these are possible reasons for an invalid handle\nexception in LeaveCriticalSection<\/code>,\nit means that the critical section code thought that there\nwere other threads waiting for the critical section to become\navailable, so it tried to signal the event, but the event handle\nwas no good.\n<\/p>\nCloseHandle<\/code>\nfunction and ended up closing the critical section’s handle\nby mistake.\nThis can also happen if some other piece of code has a double-close\nbug, and the handle (now closed) just happened to be reused as the\ncritical section’s event handle.\nWhen the buggy code closes the handle the second time by mistake,\nit ends up closing the critical section’s handle instead.\n<\/p>\n\nEnterCriticalSection(&cs);\n... do stuff...\nLeaveCriticalSection(&cs);\n<\/pre>\n
DeleteCriticalSection(&cs)<\/code>.\nThis destroys the critical section while another thread\nwas still using it.\nEventually that thread finishes doing its stuff and calls\nLeaveCriticalSection<\/code>,\nwhich raises the invalid handle exception because the\nDeleteCriticalSection<\/code> already closed the handle.\n<\/p>\nLeaveCriticalSection<\/code>.\nTo determine which one you’re running into will require more\ndebugging, but at least now you know what to be looking for.\n<\/p>\n