I just run into an issue on .NET Framework, but it impacts .NET Core as well. In both cases, it causes the app to crash with an access violation.

Repro code:

static void Main(string[] args)
{
    var locks = new object[4];

    for (int i = 0; i < locks.Length; i++)
    {
        locks[i] = new object();
    }

    for (int i = 0; i < 4; i++)
    {
        var thread = new Thread(state =>
        {
            Monitor.Enter(locks[(int)state]);
        });

        thread.Start(i);
        thread.Join();
    }

    // Force the thread to be collected, orphaning the lock
    GC.Collect(2, GCCollectionMode.Forced, true, true);
    GC.WaitForPendingFinalizers();
    GC.Collect(2, GCCollectionMode.Forced, true, true);

    // Promote to a syncblock
    for (int i = 0; i < locks.Length; i++)
    {
        _ = locks[i].GetHashCode();
    }

    // Trigger the crash
    for (int i = 0; i < 4; i++)
    {
        var thread = new Thread(state =>
        {
            _ = Monitor.IsEntered(locks[(int)state]);
        });

        thread.Start(i);
        thread.Join();
    }
}

First, a thread locks an object. A thin-lock is used. The thread dies without releasing the lock.
Later, the thin-lock is promoted to a syncblock (either because of a call to GetHashCode, or because another thread tries to acquire the lock). When it does, the runtime tries to map the thin-lock id to the address of the thread: https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/syncblk.cpp#L2214
If the cleaned up thread was the last in the map, it causes the IdToThreadWithValidation method to return NULL (that's the if ((size_t)result <= m_idToThreadCapacity) check) :

If it does, then GetSyncBlock sets the thread address in the syncblock to -1:

Later, another thread tries to acquire the lock. ObjectNative::IsLockHeld is called, which in turn calls GetThreadOwningMonitorLock (https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/syncblk.cpp#L1804). The method fetches the thread address from the syncblock, checks if it's null, but omits to check if it's equal to -1. This causes the access violation when trying to dereference it to fetch the thread id: