Add support for configuring the CM lazy-flush and delay-close variables:
`CmpLazyFlushIntervalInSeconds`, `CmpLazyFlushHiveCount`,
and `CmpDelayedCloseSize`,
using REG_DWORD values named respectively:
`RegistryLazyFlushInterval`, `RegistryLazyFlushHiveCount`,
and `DelayCloseSize`,
in the registry key
`HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager` .
Extra observations:
- While delay-close support exists in Windows 2003, configuring
the delay-close size is possible only in Windows Vista and later.
- The possibility of configuring the lazy-flush hive count has been
removed in Windows 8+.
See the comparison tables at:
https://redplait.blogspot.com/2011/07/cmcontrolvector.htmlhttps://redplait.blogspot.com/2012/06/cmcontrolvector-for-w8.htmlhttps://redplait.blogspot.com/2016/03/cmcontrolvector-from-windows-10-build.html
In addition:
Remove `CmpDelayedCloseIndex` from cm.h as it is not used anymore in our code.
This is a temporary helper for the system call entry point to store the user mode stack, before switching to the kernel mode stack. Initially it was copied to the trap frame inside KiSystemCallHandler. This has been moved to the system call entry point, but some remnants remained. The problem is that KiSystemCallHandler can be called twice in a system call (when the call is the first GUI call and the stack needs to be extended). In that scenario, when the thread was preempted, a new value could be saved in the PCR before running KiSystemCallHandler again, and then overwriting the proper value with a bogus one from a different thread. This rarely seemed to happen on UP, but happens a lot with SMP.
Its support is controlled with a REG_DWORD value named
`VolatileBoot` inside the registry key
`HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager` .
Its implementation is very trivial: when enabled, CmpShareSystemHives
is set to TRUE and doesn't change state during runtime.
In a sense this is similar to what happens in WinPE-boot, except that
ALL hives without exception (system hives and others) will be loaded
in shared mode.
This is controlled with a REG_DWORD value named
`SelfHealingEnabled` inside the registry key
`HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager` .
The `CmSelfHeal` variable is used to retrieve the data,
hence it needs to be a ULONG.
The REG_DWORD value `AutoReboot` stored in the registry key
`HKLM\SYSTEM\CurrentControlSet\Control\CrashControl`
(used as a boolean value), controls whether to automatically reboot
the operating system at the end of the crash dump, after a bugcheck.
ReactOS doesn't currently implement crash dumps, so only the auto-reboot
is done. (The reason of the apparent redundant `Reboot` variable in
KeBugCheckWithTf() is because that variable would be updated on return
by the not-yet-existing crash-dump helper routines called from there.)
- Directly call KdpGetMemorySizeInMBs() within KdpPrintBanner(),
instead of having the caller doing it.
- Use the miarm.h MiIsMemoryTypeInvisible() helper.
- Add Doxygen comments.
- Move local variables to the code blocks where they are used.
- if-s one-line bodies on their own lines.
- Massage the boot-images symbols loading, using a for-loop.
Override DbgPrint(), used by the debugger banner DPRINTs,
because KdInitSystem() can be called under the debugger lock
by KdEnableDebugger(WithLock)().
In this case, when DbgPrint() (re-)enters the debugger via an
interrupt and acquires the debugger lock, a deadlock occurs.
- The debugging banner helpers *CANNOT* be in the INIT section, because
it is possible for KdInitSystem() to enable the debugger **MUCH LATER**
after boot time. (Reverts part of commit f239ca0f0 (r72922).)
This can happen in two situations:
* When the debugger is in CRASHDEBUG mode, i.e. initialized at boot
time but not immediately enabled, and a BSOD happens later that
enables the debugger with a `KdInitSystem(0, NULL)` call.
* When the debugger was possibly manually disabled with a
KdDisableDebugger() call, then later re-enabled with a
KdEnableDebugger() call.
- In the same cases as described above, the KeLoaderBlock is freed after
boot time. Thus, KdpGetMemorySizeInMBs() cannot use it and enumerate
the MemoryDescriptors to evaluate the number of physical memory pages
available on the system. Instead, we can use what the memory manager
has already computed, since the latter is already initialized by now.
These two fixes avoid (invisible) crashes when (re-)enabling
the debugger at non-boot run time.
I.e. when LoaderBlock != NULL and we have loaded the initial hal and
ntoskrnl symbols. KdBreakAfterSymbolLoad is then checked for when the
other boot symbols have been loaded by ex/init.c!ExpLoadBootSymbols(),
invoked by ExpInitializeExecutive().
Use section object pointer with byte offset instead of using base address. This simplifies the Mm functions themselves and also the code in Cc that calls them.
Also add minor fixes for MmFlushSegment and MmPurgeSegment.
This basically avoids re-entering the debugger (via the embedded breakpoint)
while we are already running within its context.
In addition, this allows the tests for Kd/NtSystemDebugControl
(see PRs #7424 and #7426) to run without having ReactOS to crash.
Don't return before file object's resource is acquired in FsRtlAcquireFileExclusiveCommon, except some special return cases, when return is required. Based on hpoussin_filter_extra.patch by Herve Poussineau (@hpoussin) with improved comment, which matches the actual behaviour now.
This is required by fltmgr.sys driver from Windows XP/Server 2003 to work correctly, so this change fixes asserts/exceptions when releasing the file via FsRtlReleaseFile after acquiring, when using 3rd party filter drivers from several antivirus programs (e. g., Avast Free Antivirus all versions, AVG Antivirus Free 18.8, Avira AntiVir Personal 8.2, Dr. Web Security Space 8.0, Kaspersky Antivirus 2012 etc. etc.).
CORE-14157, CORE-14635, CORE-19318
MiGrabDataSection adds a refcount. There is a missing MmDereferenceSegment cleanup in case of range check error.
Fix that by moving MiGrabDataSection calling code to after range check.
* [NTOS:MM] Fix MmAllocateMappingAddress and MmFreeMappingAddress and their regression test failures.
Follow up of #7260.
This fixes kmtest:MmReservedMapping failures and hang.
Based on mm-implement-mappingaddress.patch by Thomas Faber and some changes by Oleg Dubinskiy.
kmtest:MmReservedMapping revisions and updates to Vista+ method by Timo Kreuzer.
Signed-off-by: Oleg Dubinskiy <oleg.dubinskij30@gmail.com>
Signed-off-by: Timo Kreuzer <timo.kreuzer@reactos.org>
CORE-10147, CORE-14635, CORE-17409, CORE-19318
Implement MmAllocateMappingAddress and MmFreeMappingAddress routines.
Based on mm-implement-mappingaddress.patch by Thomas Faber with some changes from me.
Required by Microsoft NTFS driver (from Windows Server 2003 SP2 only, the one from Windows XP SP3 does not need them) and by NDIS & TDI drivers (both from Windows XP SP3 and Windows Server 2003 SP2). Also they are called when using Dr. Web Security Space 8 filter drivers together with MS FltMgr & TDI.
Fortunately, this part (these two routines) are enough to get the drivers working in both cases, and others (partially incomplete) routines are not badly required, so they can be finished and committed later.
CORE-10147, CORE-14635, CORE-17409, CORE-19318
Fix warnings:
E:\3rdRepo\ReactOS_Fork4\ntoskrnl\ex\keyedevt.c(458): warning C6387: 'Timeout' could be '0': this does not adhere to the specification for the function 'ExpWaitForKeyedEvent'.
E:\3rdRepo\ReactOS_Fork4\ntoskrnl\ex\keyedevt.c(527): warning C6387: 'Timeout' could be '0': this does not adhere to the specification for the function 'ExpReleaseKeyedEvent'.
JIRA issue: None.
Proposed changes
Timeout parameter of those two functions should be optional.
KeFlushQueuedDpcs is used by some drivers, when unloading or removing a device, to be sure no DPC is still running their code. On a UP system this can be done "inline", on an SMP system, it requires to send an IPI to each processor that has DPCs queued and also synchronize it with the calling thread, which is what KeSetSystemAffinityThread does implicitly: When a queued DPC was detected on a remote processor (implying that processor is currently running at DISPATCH_LEVEL or above), KeSetSystemAffinityThread will schedule the current thread on that processor and send a DPC interrupt. The remote processor will handle that DPC interrupt once it is back below DISPATCH_LEVEL. It will only run the current thread, after all queued DPCs (including threaded DPCs) have finished running.
Addendum to commit baa47fa5e.
Similarly to what was originally done, have KdbpCliInterpretInitFile()
parse the KDBinit file by breaking back into the debugger.
But contrary to before, replace the deprecated call to KdbEnter() by
a standard DbgBreakPointWithStatus(DBG_STATUS_CONTROL_C) . This allows
KdbEnterDebuggerException() to do the KdbpCliInterpretInitFile() call.
Additional fixes and improvements:
- Run KdbpCliInterpretInitFile() in full KDBG environment (interrupts
disabled, modified IRQL, own stack), like the usual interactive loop.
- The KDBinit data buffer must be in non-paged pool.
- Demote the "Could not open KDBinit" error to a DPRINT, so that it
doesn't pollute the debug log when the KDBG init function is called
early (before the storage stack is initialized), or if the file
doesn't exist -- since this is an optional feature.
- Move the printing pager state reset code (setting the number of
printed rows and columns to zero, and the output aborted flag)
to KdbpDoCommand(). This allows to keep the original behaviour,
while also inheriting it whenever KdbpDoCommand() is invoked
elsewhere (for example, from KdbpCliInterpretInitFile()).
- Use KdbPuts/Printf() instead of KdbpPrint() for the entry banners,
so that they aren't subject to the current printing pager state.
Do the same for the "command unknown" error in KdbpDoCommand().
- Add a "Type 'help' for a list of commands" banner, for the users.
- Replace the do-while-loop with a simple while-loop.
Previously FsRtlNotifyVolumeEvent would pass a pointer to a TARGET_DEVICE_CUSTOM_NOTIFICATION structure on the stack to IoReportTargetDeviceChangeAsynchronous, which would store a pointer to it in a work-item and process that after the stack object was already out of scope. This broke x64 boot. Started happening after recent fixes to IoReportTargetDeviceChangeAsynchronous.
