Access Read Violation thrown on EnterCriticalSection()

Question

I am working on a multi-threaded application that uses critical sections to synchronize an array of entities. The array is held within a struct as shown below. Every member of the pe array contains its own criticalSection which is always claimed before accessing the member(I have checked them all).

struct PlayerEntity {
    DWORD state;
    BOOL onScreen;
    DWORD team;

    DWORD_PTR baseAddr;
    BOOL valid;
    CRITICAL_SECTION critSec;
};

struct EntityList {
    DWORD count;
    PlayerEntity pe[128];
};

EntityList *getStaticEntityList() {
    static EntityList entityList;
    return &entityList;
}

After starting the applications one of the two threads will throw an exception(below) seemingly at a random time when it tries to enter a critical section.

Exception thrown at 0x00007FFC8813E7C5 (ntdll.dll) in RustExp.exe:
0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

I assume this error is being thrown by the critical section objects attempting to access their DebugInfo object because every object's DebugInfo pointer points to 0xffffffffffffffff after initialization. However after the bug check they all point to 0xcdcdcdcdcdcdcdcd.

I have tried to lookup information regarding critical section objects and their members but I can't seem to find anything on them. So I ask, should an initialized critical section object point its DebugInfo to 0xffffffffffffffff and when does a critical section attempt to access its DebugInfo(and thereby throw the read error)?

NOTE: This is running on Windows 10.

Answer 1

I cancelled out my comment by error. But anyway I made a check and found that the DebugInfo pointer is initialized during the critical section initialization to a valid address that remains the same during all tests (entering and leaving the section).

If you don't have any error during critical section initialization it should be correctly initialized, ergo you can't have that 0xFFFFFFFFFFFFFFFF there.

This leads to only one conclusion, the problem have to be searched in a memory corruption occurring elsewhere in the code.