Port back
0.4.12-dev-973-g d29e216f99
[NTOSKRNL] In MmCreateImageSection, properly check whether cache was initialized
This fixes a crash that occurs if nul is typed in cmd.exe (BSOD0x1E)
----------
Port back also some unrelated formatting-improvements within section.c, e.g.: return(xyz) -> return xyz
A *partial* port of
0.4.15-dev-1793-g b7eb0fddf3
All releases/0.4.8 until and including releases/0.4.14 were affected by the following logspam
during shutdown:
(../ntoskrnl/mm/section.c:4839) SectionObject has ImageSection
triggered 2 times for bootcd, but triggered 83 times for livecd.
Today I found out by chance, that we started to trigger it with the switch from CDFS to CDFS_NEW with
0.4.8-dev-164-g ec6b3ecbe4
We 'suffered' from that logspam for many years now and it did never help us in any way.
And during 0.4.15-dev'ing with the MM rewrite, the logging was entirely removed in the NTOSKRNL.
This was part of the commits for ROSTESTS-110, but much more important:
It fixes CORE-14694 "reproducible BSOD 0x1A MEMORY_MANAGEMENT in OllyDbg v2.01"
Fix picked from 0.4.11-dev-650-g 47ac7a2b28
which also requires me to "Move up MmAlterViewAttributes() for later use in MmNotPresentFaultSectionView()"
like it was done in: 0.4.11-dev-649-g 47ac7a2b28
Ofc I moved the function up individually in each branch I do port this back to, without modifying the func.
which caused images to be loaded up to MmHighestUserAddress,
thus overwriting the shared user page.
This is now fixed by using MM_HIGHEST_VAD_ADDRESS as the margin instead.
This commit allows again to load WIN32K.sys of Win2K3SP2
which regressed by SVN 67793 == git
3565260212
fix cherry picked from commit 0.4.14-dev-143-g
56da95671c
Doing this is not only wrong because it acquires the same spinlock twice,
it also completely breaks the TLB flushing logic in MiMapPageInHyperSpace.
If the PTE with Offset 1 is still valid when a wrap-around to 0 happens,
the TLB flush on wrap-around will not clear the entry for this previous page.
After another loop around all hyperspace pages, page 1 is re-used but its
TLB entry has not been flushed, which may result into incorrect translation.
Experiment and MSDN tend to show that a dirty BCB is queued for lazy write.
This will do the job here!
Also, renamed CcRosMarkDirtyFile() which is more accurate, and added a new
function CcRosMarkDirtyVacb() which just takes a VACB as arg (expected locked)
and marks it dirty (using previous implementation). Make CcRosMarkDirtyFile()
use it.
CORE-14235
