(Regression ?) Reproducible assert 'Owner != NULL' in ntoskrnl/ex/resource.c, line 1934 when loading (and writing data on NTFS partition with) MS NTFS driver

How to reproduce:

1. Download a bit modified ReactOS kernel from attachments: ntoskrnl.zip, which is based on 0.4.15-dev-2102-gfd39a29 and has ThFabba's mm-implement-mappingaddress.patch from CORE-10147 and https://github.com/reactos/reactos/pull/3400 applied (or feel free to apply the fixes and rebuild it manually ). Those patch and PR contain implementations of some CC/MM public routines required by Microsoft NTFS driver in order to be loaded properly.
2. Integrate it in ReactOS ISO and install ROS with it, or just replace it in already installed system.
3. Replace ntfs.sys driver also by the one from Win2k3.
4. Shutdown the system.
5. Connect any NTFS partiton(s). In my case, I connected 10 GB VDI drive previously formatted to NTFS, since I tested it on VirtualBox. But on real hardware it seems to be also reproducible, with physical NTFS volume(s) connected.
   Partition(s) should not contain any filesystem corruption(s), otherwise it may cause another unrelated system failures.
6. Start system again.

When the driver will try to load at booting, or, at least, if it will load successfully and you'll try to create/write any data there, at the some moment will appear the following assert:

*** Assertion failed: Owner != NULL

***   Source File: ntoskrnl/ex/resource.c, line 1934

Judging by the received backtrace, it fails due to the following ExReleaseResourceForThreadLite call: https://git.reactos.org/?p=reactos.git;a=blob;f=ntoskrnl/cc/pin.c;hb=fd39a292af70a5854f4e63f3a017f6ff3df5dacb#l588. Indeed, after disabling that call, assert is no longer appear, but random hangs still may happen when preforming any write operations on NTFS partition. So it cannot be fixed properly just by removing that call.
I made a better fix instead and will submit a PR soon. Allow me some time.

P. S.: As far as I tested earlier, this didn't happen with the early stage of section_right PR appllied, before it got merged, but probably after further improvements it regressed.
Reapllying the fixes and recompiling the kernel for each of those commits may take a long time, so I'll do it later.