CONSOLE_INFORMATION::IsConsoleLocked and CONSOLE_INFORMATION::GetCSRecursionCount inappropriately groveling into opaque CRITICAL_SECTION object internals

These two functions appear to be peering into the internal opaque CRITICAL_SECTION object. The CRITICAL_SECTION definition is opaque and shouldn't be used by apps (it can - and has - changed layout between OS versions so long as the size is the same).

The CONSOLE_INFORMATION object should track an owning thread ID and critical section entry count itself if it needs to get this information and shouldn't try to assume that it knows about the critical section implementation details (particularly for OSS'd code we'd like to avoid encouraging that sort of thing as it inevitably leads to broken apps on future OS updates etc.).

bool CONSOLE_INFORMATION::IsConsoleLocked() const
{​
// The critical section structure's OwningThread field contains the ThreadId despite having the HANDLE type.​
// This requires us to hard cast the ID to compare.​
return _csConsoleLock.OwningThread == (HANDLE)GetCurrentThreadId();​
}​
​
​
ULONG CONSOLE_INFORMATION::GetCSRecursionCount()​
{​
return _csConsoleLock.RecursionCount;​
}​

Start by locating CONSOLE_INFORMATION::IsConsoleLocked and CONSOLE_INFORMATION::GetCSRecursionCount and reading their callers. Replace the dependence on CRITICAL_SECTION internals with ownership and recursion state tracked by CONSOLE_INFORMATION, then verify that the callers still receive the required lock information without inspecting the opaque object layout.