VC1 Linker fills BSS.SizeOfRawData with data in IMAGE_OPTIONAL_HEADER.SizeOfUninitializedData but keeps PointerToRawData to zero.
Fixes CORE-18797 and some duplicates of that. (Apps, e.g. Doom95, compiled with Watcom-C-compilers wouldn't run otherwise.)
which regressed by
0.4.10-dev-136-g c7eb46d9fd
fix picked from
0.4.15-dev-5589-g 0d4a8d0ea6
----------
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
----------
Port back also
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)
The main motivation to port all that back is to get rid of Win32K-BSODs 0x50 like CORE-13907
that could be triggered by user-mode-applications.
Technical reason was CORE-14857 "RtlImageNtHeaderEx needs SEH" and issues with hooks+callbacks.
All other tickets mentioned in here were regressions that we experienced on the long
journey towards perfecting the fixes on master head, and those were not happening yet in the older builds,
so they are mentioned in here only to allow tracking where that code went into.
Thanks to Jim Tabor, Mark Jansen & Thomas Faber
By squashed backmerge of the following commits:
0.4.15-dev-3440-g a89844f740
0.4.15-dev-3430-g 9cff384c22
0.4.14-dev-1287-g 568b6d0558
0.4.14-dev-1255-g 177ae91bf6
0.4.14-dev-1241-g 915a5764a9
0.4.14-dev-1240-g d8add40e89
0.4.14-dev-1002-g feb7df42b4
JIRA-tickets: CORE-13907, CORE-16769, CORE-14857, CORE-17856, CORE-17857, partially CORE-13019.
We also had some more dupes of CORE-13907 in JIRA, but I linked all of them (transitively)
towards the initial report, and resolved them without setting a fixVer for them.
In more detail:
--------------
[USER32] Fix BSOD 0x50 in 'WineVDM + Castle Of Winds' CORE-17856 CORE-17857
CORE-17856 BSOD 0x50 when starting Castle of the Winds second time, with WineVDM
CORE-17857 BSOD 0x50 on shutdown after closing Castle of the Winds with WineVDM
0.4.15-dev-3430-g 9cff384c22
0.4.15-dev-3440-g a89844f740
--------------
[NTUSER] Fix Strings and Format to Hooks
Allocate heap instead of data segment to be used for callbacks on user side.
Move and correct initial hook call out setup. Use it in more than one hook call.
This fixes issues with strings out of alignment and use of kernel pointers.
See CORE-13907 (HXD-portable BSOD) and CORE-16769 (HXD-portable exception)
Small wow update.
cherry picked from commit 0.4.14-dev-1287-g 568b6d0558
--------------
[RTL] Introduce RtlpImageNtHeader,
which implements the required functionality.
ntdll and ntoskrnl now have a wrapper for this, with SEH.
This protects the function against malformed / bad images,
whilst still being able to use the code in freeldr et al.
Idea from Thomas.
CORE-14857
cherry picked from commit 0.4.14-dev-1255-g 177ae91bf6
--------------
[WIN32SS] Form Sanity to Hook Callbacks
Fix WH_CALLWNDPROC/RET data to user hook calls.
Helps with CORE-13907 "(HXD-portable BSOD)"
Fixes the logging of "(win32ss/user/ntuser/callback.c:748) err: Failure to make Callback! Status 0xc00000fd" within CORE-13019, but not the whole ticket.
cherry picked from commit 0.4.14-dev-1241-g 915a5764a9
--------------
[USER32] Fix null return.
See CORE-16769 "HxD 1.7.7.0 portable unhandled exception"
cherry picked from commit 0.4.14-dev-1240-g d8add40e89
--------------
[WIN32SS] Fix a typo in dbg print
cherry picked from commit 0.4.14-dev-1002-g feb7df42b4
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.
Thomas Faber thinks that it's a bit more
safe to just move "after .rsrc" instead of the proper "after .reloc".
A temporary tribute until ROSBE-154 will be fixed properly.
For now we use this just for NTOSKRNL, but not for drivers yet, see
MODULE TYPE sdk/cmake/gcc.cmake
As using also for drivers would immediately lead to BSODs like CORE-16183.
To allow installing DVDWritenow without BSOD,
we need the script at least for ntoskrnl!
The regression was introduced by SVN r55835 == git
6ebf8c2537
This patch (after .rsrc) was already committed into 0.4.15-dev-220-g
d28677795e
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
Short: The code was suffering from an off-by-one bug (inconsistency between inclusive end exclusive end address), which could lead to freeing one page above the initialization code. This led to freeing part of the kernel import section on x64. Now it is consistently using the aligned/exclusive end address.
Long:
* Initialization sections are freed both for the boot loaded images as well as for drivers that are loaded later. Obviously the second mechanism needs to be able to run at any time, so it is not initialization code itself. For some reason someone decided though, it would be a smart idea to implement the code twice, once for the boot loaded images, once for drivers and concluding that the former was initialization code itself and had to be freed.
* Since freeing the code that frees the initialization sections, while it is doing that is not possible, it uses a "smart trick", initially skipping that range, returning its start and end to the caller and have the caller free it afterwards.
* The code was using the end address in an inconsistent way, partly aligning it to the start of the following section, sometimes pointing to the last byte that should be freed. The function that freed each chunk was assuming the latter (i.e. that the end was included in the range) and thus freed the page that contained the end address. The end address for the range that was returned to the caller was aligned to the start of the next section, and the caller used it to free the range including the following page. On x64 this was the start of the import section of ntoskrnl. How that worked on x86 I don't even want to know.
The PROCESS_DEVICEMAP_INFORMATION union has 2 fields, one is a handle, the other one is a structure of 36 bytes (independent of architecture). The handle forces 64 bit alignment on 64 bit builds, making the structure 4 bytes bigger than on 32 bit builds. The site is checked in NtQueryInformationProcess (case ProcessDeviceMap). The expected size on x64 is the size of the Query structure without alignment. autocheck correctly passes the site of the Query union member, while smss passes the full size of PROCESS_DEVICEMAP_INFORMATION. Packing the structure is not an option, since it is defined in public headers without packing. Using the original headers sizeof(PROCESS_DEVICEMAP_INFORMATION) is 0x28, sizeof(PROCESS_DEVICEMAP_INFORMATION::Query) is 0x24.
- Rename ObDirectoryType to ObpDirectoryObjectType and remove it from NDK (this is not exported!)
- Rename ObSymbolicLinkType to ObpSymbolicLinkObjectType
- Remove duplicated ObpTypeObjectType from ob.h
Kernel stacks that re freed, can be placed on an SLIST for quick reuse. The old code was using a member of the PFN of the last stack page as the SLIST_ENTRY. This relies on the following (non-portable) assumptions:
- A stack always has a PTE associated with it.
- This PTE has a PFN associated with it.
- The PFN has an empty field that can be re-used as an SLIST_ENTRY.
- The PFN has another field that points back to the PTE, which then can be used to get the stack base.
Specifically: On x64 the PFN field is not 16 bytes aligned, so it cannot be used as an SLIST_ENTRY. (In a "usermode kernel" the other assumptions are also invalid).
The new code does what Windows does (and which seems absolutely obvious to do): Place the SLIST_ENTRY directly on the stack.
It's hardly understandable and doesn't really makes sense.
Furthermore, it breaks compatibility with 3rd party FSD that
don't implement such FSCTL.
Obviously, Windows doesn't do this.
