microsoft
update system DLL range logic for 64-bit OSes
Hey Detours folks,
Just a couple of suggestions for choosing the trampoline location.
The X86 range reserved for system DLLs is not up to date.
The X64 "not +/- 1GB of target" heuristic to avoid the range used by system DLLs is not entirely robust. Instead we could replace this with a "not 1GB after ntdll" heuristic.
This breaks support for Windows 7, DetourAllocateRegionWithinJumpBounds emits the message "Couldn't find available memory region!\n".
@Mauler125 Was this Windows 7 x86? The x86 logic was updated to account for Windows 8 kernel changes - but I didn't consider backwards compatibility with EOL versions at time.
https://github.com/microsoft/Detours/blob/4ed81f1036d028306b3659e976d2e57f37c4245a/src/detours.cpp#L78-L84
@jdu2600 This was on the latest version of Windows 7 x64 (SP1 with all updates), I think the ranges are different on Windows 7, and changed in Windows 8 as you mentioned. I hadn't had the chance to debug this myself yet. Some of our users host a game server on Windows 7 x64 which is where this was being reported from.
These changes however do seem to work perfectly on Windows 10 and Windows 11 for the 2 months we have it implemented and tested; not a single issue has been encountered from it yet.
@jdu2600 This was on the latest version of Windows 7 x64 (SP1 with all updates), I think the ranges are different on Windows 7, and changed in Windows 8 as you mentioned. I hadn't had the chance to debug this myself yet. Some of our users host a game server on Windows 7 x64 which is where this was being reported from.
These changes however do seem to work perfectly on Windows 10 and Windows 11 for the 2 months we have it implemented and tested; not a single issue has been encountered from it yet.
Weird, I've checked "Windows Internals 6th" (corresponding to Win7) and analyzed ntoskrnl.exe!MiInitializeRelocations, the results show the region is the same SINCE NT6.0:
32-bit process：[0x50000000 ... 0x78000000), a total of 640MB
64-bit process：[0x00007FF7FFFF0000 ... 0x00007FFFFFFF0000), a total of 32GB
(Personal conclusions, please let me know if there is any error)
In Vista and Win7 (NT6.0 and NT6.1), ASLR can be turned off by registry:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, MoveImages (REG_DWORD)
I think there's a chance this could be causing this issue.
In Win7, ASLR can be turned off by registry:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, MoveImages (REG_DWORD)
I think there's a chance this could be causing this issue.
Sorry for my later responce. Today I did some research again on this issue and it was indeed caused by having ASLR disabled system-wide using the mentioned registry value.
Your recent changes on KNSoft's SlimDetours does fix the issue as far as I've been able to test it. I will continue testing it and report any issues if I encounter them.
In Win7, ASLR can be turned off by registry:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, MoveImages (REG_DWORD)
I think there's a chance this could be causing this issue.
Sorry for my later responce. Today I did some research again on this issue and it was indeed caused by having ASLR disabled system-wide using the mentioned registry value.
Your recent changes on KNSoft's SlimDetours does fix the issue as far as I've been able to test it. I will continue testing it and report any issues if I encounter them.
Thanks, if still encounter the same problem, try to remove this block, I don't have 100% confidence in this.