- Use SAL2 annotations; write Doxygen documentation (based on GPT-5.4 feedback).
- Simplify some of the code.
- Add the `ObSetHandleAttributes()` prototype to `ndk/obfuncs.h`,
since it is exported by ntoskrnl.exe
- Simplify the `ObjectHandleFlagInformation` class implementation,
by directly invoking the `ObSetHandleAttributes()` routine.
Addendum to commit 02d0bb9dbd (r22228) that implemented the class,
and to commit 91105c7915 (r61037) that implemented `ObSetHandleAttributes()`.
- Use SAL2 annotations; write Doxygen documentation (based on GPT-5.4
feedback and https://ntdoc.m417z.com/ntsetinformationobject).
This is needed for PCI debugging devices whose KD modules depend
on the functions registered in HalpRegisterKdSupportFunctions().
Also it's consistent with what x86 does, and also what Win7 x64 does
(the KdInitSystem is invoked after the HalInitializeProcessor call).
Necessary for PR #9156 on AMD64. CORE-20385
FstubCreateDiskRaw is supposed to wipe the MBR when it makes a RAW disk.
Before this fix, that function only cleared the first of the 4 partition entries, so one entry (16 bytes) instead of the whole table (64).
As a consequence, the wiped MBR written back to disk still had entries 2, 3 and 4 sitting there with old data, and those came back as ghost/garbage partitions.
- Use a global structure instead of pointer
- Allocate only the GUID buffer
- Keep track of allocated size and number of GUIDs
- Grow in steps of 8 GUIDs
- Use ExAllocatePoolWithTag instead of ExAllocatePool
- Use IsEqualGUID
See CORE-12791
- Don't compile the non-conformng swprintf (it is identical to _swprinf)
- Rename swprintf to _swprintf
- Forward non-conforming exports to the underscored versions in CRT dlls
Fix KiWriteSystemTime and move it to NDK. The previous implementation of KiWriteSystemTime was broken and updated the fields in the wrong order. Before that it was right for SystemTime and wrong for InterruptTime. ExpSetTimeZoneInformation had it wrong for the TimeZoneBias.
Add KiReadSystemTime to read KSYSTEM_TIME values correctly, instead of doing it manually (and partly wrongly) all over the place.
This is the same fix for the same condition check, as the one already
applied to `IopCreateArcNamesDisk()` in commit 3fe12f1a7c.
This bug was introduced in commit 538b9e4fbf (r49212) and is identical
to the one introduced in commit 6d0861e9ed (r49131).
The idea behind the condition check, is that we consider the enumerated
disk to be a match with the currently-considered one from the ARC disk
signatures, *IF*:
- there is only one single disk listed in the ARC disk signatures,
*AND* only one single disk detected at runtime by the kernel,
*AND* this disk is MBR-partitioned;
- *OR*, there is one or more disks present and the enumerated disk's
signature match the currently-considered ARC disk signature. (This
is the more general case for when there are one or multiple disks
on the system, and/or one disk at least is GPT).
Addendum to commit 5ab1cfc553.
- Fix the drive letters assignment ordering for hard disks.
* Fix the loop that assigns letters to MBR boot and primary partitions;
* Fix the condition that finds the boot partition (or defaults to the
first primary partition) to be skipped when assigning letters to all
remaining hard-disk partitions -- after letters have been assigned
to the specific boot, primary, logical, etc. partitions.
NOTE: The drive-letter assignment algorithm is as follows:
1. For each hard disk, assign a letter to the first encountered boot
(MBR "active") partition; or if GPT disk, to all data partitions.
If no boot partition has been found on this disk, assign a letter
to all of its primary partitions.
2. Assign a letter to all (MBR) logical partitions for each hard disk.
3. Assign a letter to all remaining partitions with recognized IDs on
all disks.
****
We observe that the algorithm 1-3 is tailored for MBR-partitioned disks,
as it is inherited from the way MS-DOS did it. In addition, partitions
on GPT disks acquire their drive letters early one, during step 1.
****
4. Assign letters to floppy disks (see below), then to CD-ROMs.
5. Finally, verify that the OS boot volume has got a drive letter; if
not, get a free one (or delete the 'Z' drive letter and reassign it
to the boot volume).
(See also "Inside Storage Management, Part 1", Mark Russinovich,
https://www.digiater.nl/openvms/decus/vmslt00b/nt/storage-mgt-nt_2.htm
about the `IoAssignDriveLetters` function.)
- When assigning drive letters to floppy drives, first assign letters to
legacy (non-MountMgr-aware) devices, and then to MountMgr-aware devices.
Addendum to commit 5ab1cfc553.
- Static const-ify the `FloppyString` and `CdString` constants, that are
common to both `HalpNextDriveLetter()` and `xHalIoAssignDriveLetters()`.
- Improve code comments and variable names.
- In `xHalIoAssignDriveLetters()`:
* One of the two "generic string buffers" can be thrown away, since
we can already use the on-stack `Buffer`.
* No need to `sprintf` + `RtlInitAnsiString` + `RtlAnsiStringToUnicodeString`
with the risk of failing the conversion (that also allocates memory).
Instead, just invoke `swprintf` + `RtlInitUnicodeString` as already
done elsewhere in this function.
* Replace some '0' to 'FALSE' where applicable.
* Reduce indentation level of two for-loops.
- Compile their contents only when NDEBUG is _NOT_ defined.
- Only keep the first DPRINT in these functions in order to keep the
file path and line number, but replace the others with DbgPrint in
order to have a clearer printout.
- Fix a bug in FstubDbgPrintSetPartitionEx(), where PartitionNumber has
to be used as an indicator parameter but MUST NOT be used to index the
PartitionEntry pointer. (PartitionEntry already points to the data for
setting the partition specified by PartitionNumber.)
The bug certainly came from a copy-pasting error from FstubDbgPrintPartitionEx().
This has been forgotten since the split of `IopCreateArcNames()`
in commit 6d0861e9ed (r49131).
Also, improve comments regarding `ArcHalDeviceName` vs. `ArcBootDeviceName`.
In the `HKLM\SYSTEM\CurrentControlSet\Control` registry key,
the `FirmwareBootDevice` value specifies the firmware boot
(i.e. system partition) device in ARC format, obtained from
`LoaderBlock->ArcHalDeviceName`.
For some reason it is exposed only on Windows Vista and later.
This value is similar to the `SystemBootDevice` one, which specifies
instead the OS boot device in ARC format, obtained from
`LoaderBlock->ArcBootDeviceName`.
In addition: check the value returned by `RtlCreateUnicodeStringFromAsciiz()`
and fail if so.
Instead of mixing the paths order (ArcBoot, NtHal, ArcHal, NtBoot),
show them in a meaningful order: ArcHal, NtHal, ArcBoot, NtBoot.
- The `ArcHalDeviceName` + `NtHalPathName` is the path to the system
loader started by the firmware (and the HAL in old non-x86 Windows
versions).
- The `ArcBootDeviceName` + `NtBootPathName` is the operating system
boot partition and directory ("system root").
As implicitly implied by the MSDN description for `IoGetAttachedDevice()`:
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-iogetattacheddevice
> IoGetAttachedDevice differs from IoGetAttachedDeviceReference in the
> following respects:
>
> [...]
>
> - Callers of IoGetAttachedDevice must ensure that no device objects are
> added to or removed from the stack while IoGetAttachedDevice is executing.
> Callers that cannot do this must use IoGetAttachedDeviceReference instead.
the `IoGetAttachedDeviceReference()` has to acquire the device list lock
to ensure that no device objects get added to or removed from the device
stack during its invocation.
Similarly, `IoGetDeviceAttachmentBaseRef()` has to do the same.
This function is the internal helper for the `IoAttachDevice*()` functions,
in particular for `IoAttachDeviceToDeviceStackSafe()`.
Because the function modifies the chained list of stacked devices, it must
hold the device list lock (the I/O system database lock) while doing the
devices attachment.
In particular, modifying the `SourceDevice`'s extension `AttachedTo` field,
but also modifying its other fields and the `AttachedDevice` ones as well.
This fix is similar to the one already committed in f8cbc3e48c (r70496).
----
In MSDN [^1] it is indicated (although not as clearly as it could be) that
`IoAttachDeviceToDeviceStackSafe()` sets the returned `AttachedToDeviceObject`
pointer under the device list lock. The reason is best spelled in [^2][^3].
Indeed, when a filter attaches to a lower PDO (`PhysicalDevice`) by doing:
```c
myDeviceExtension->LowerDevice =
IoAttachDeviceToDeviceStack(myFilterDevice, PhysicalDevice);
```
there exists a time window where the function finished attaching the filter
device to the PDO, but hasn't yet returned the device at the top of the
stack to be stored in `myDeviceExtension->LowerDevice` (which gets used
later internally by the filter to pass IRPs down the device stack).
During this time, the filter device may receive some IRPs and its
dispatch routine would use a not-yet initialized `LowerDevice` member.
The IoAttachDeviceToDeviceStackSafe() allows doing:
```c
Status = IoAttachDeviceToDeviceStackSafe(
myFilterDevice, PhysicalDevice, &myDeviceExtension->LowerDevice);
```
and forbidding the IRPs to be delivered to the filter device, while the
`LowerDevice` member is being initialized with the device list lock held.
----
[^1]: "IoAttachDeviceToDeviceStackSafe function (ntddk.h)"
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-ioattachdevicetodevicestacksafe#remarks
[^2]: "IoAttachDeviceToDeviceStack gotcha" (Satya Das, Winprogger)
https://winprogger.com/ioattachdevicetodevicestack-gotcha/
[^3]: Community OSR answer (by Tony Mason)
https://community.osr.com/t/attach-filter-driver/9450/3
Re-enable in ps_i.h the stubbed probing info values for thread information
classes, that were disabled in commit 60aad33ed0 (PR #8487), and adjust
the test code in probelib.c so that the failures for these non-implemented
classes are correctly taken into account.
Detect whether we run on XBOX or PC98 (on x86 builds), or on (U)EFI or on
a BIOS-based PC, or whether a generic linear framebuffer mode is used, in
order to choose the correct bootvid module to load, based from a predefined
file names list (ideally it should be derived from txtsetup.sif...).
Supersedes PR #8701.
Use `KeFindConfiguration*Entry()` to spelunk the hardware configuration
tree in the NT loader module.
Alternatively, allow the user to override the choice with a new `BOOTVID=`
boot option. In any case, if the selected bootvid module failed to be loaded,
silently fall back to the default bootvid.dll file. The fallback is done
by just letting the PE loader resolve the necessary exports from hal.dll
and ntoskrnl.exe.
This is the same feature as the one that already exists in the
NTOS:KD!kdmain.c module used by the in-kernel KDBG debugger
(GCC builds), first introduced in commit 4ce30245de (r54473),
and documented at:
https://reactos.org/wiki/Debugging#Changing_the_serial_port_address
This feature is useful if one uses a PCI, PCIe, PCMCIA, or ExpressCard
serial card on real hardware (these cards are used e.g. with laptops
without a built-in serial port), or with AMT serial over LAN.
After determining the serial port I/O address (say, 0xCC00), specify
the debug port as follows:
/DEBUGPORT=COM:0xCC00
instead of the usual syntax: /DEBUGPORT=COMn (n an integer).
The same syntax can be used for debugging FreeLoader as well: in the
FREELDR.INI file, add a "Debug" line in the "FREELOADER" section,
as follows:
```
[FREELOADER]
Debug=/DEBUG /DEBUGPORT=COM:0xCC00 /BAUDRATE=115200
```
----
NOTE for KDCOM/KDGDB:
Since `strtoul()` is used, but isn't exported by ntoskrnl, link against
the "strtol" static library that has been introduced in commit d317d4fbcc
(r71481).
Don't loop past the end of the command-line buffer, if the command-line
terminates with a lone "DEBUGPORT" without any extra parameter following.
For example: "some things DEBUGPORT "
Support for the BAUDRATE option was erroneously removed in commit 95faf65ebf.
As a result, the in-kernel KDBG debugger was always running with the
default debug port baud rate (115200 Bd), even if the user tried to
override it with the BAUDRATE option for supporting terminals that use
a different baud rate.
- Don't hardcode constant string lengths.
- Use `_strnicmp()` -- Ideally we shouldn't have to unconditionally upcase
the global kernel command-line string to perform substrings comparisons.
- Cast `atol()` returned value to `ULONG`.
- Use DEFAULT_DEBUG_BAUD_RATE for the debug serial port.
- Use a less dramatic "Serial port not available" (without '!')
instead of "Serial port not found!" message, in case ReactOS
BSODs without a debugger attached to a serial port.
Sometimes people mistake this informational line as one of the
reasons why ReactOS BSODed or whatnot...
- Replace "Serial port found" by "Using COM..." message.
Hermès Bélusca-Maïto