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.
- Move the GUID_DEVICE_ENUMERATED event from the TargetDeviceChangeEvent category to the DeviceInstallEvent category
- Create a new function that handles DeviceInstallEvent category events
Besides creating the PDO and device node for it, it has to set up the
necessary registry keys, and register PDO at PnP root driver properly.
CORE-18989
The root device object is in fact a PDO and a FDO at the same time. Thus
there is no need in creating two device objects here, one is enough.
This commit also removes the explicit device extension for the root DO,
because the only reason it existed is to distinguish the root driver's
FDO from its PDOs. This can easily be done by comparing with
IopRootDeviceNode.
Also collect some unused garbage while we are here.
Handling PnP root driver power IRPs requires that a device object must come up
with a device extension to determine whether it is a function driver and if so,
handle the IRP accordingly.
CORE-18989
Based on a commit by Vadim Galyant:
5ef5c11e7f
Also fix a minor type conversion warning. CORE-18963 CORE-17977
Co-authored-by: Vadim Galyant <vgal@rambler.ru>
We should compare against DeviceObject as DeviceInstance is never NULL.
Fix a resource leak as well. The bug CORE-18983 seems to lay somewhere
else though, I just stumbled upon this one while researching it.
Note there is a BSOD in the PnP manager on reboot after the driver
installation failure, but it seems it was uncovered by the fix
as opposed to caused by it.
CORE-18962
- Deduplicate a while-loop by adding one more recursive call.
- Add IopMapDetectedDeviceId() helper function with a structure
in order to reduce hardcoded constants and checks.
- Add a check for correct PDO before doing anything
- Process the request only for started devices
- Send the request synchronously during the start sequence
This makes Windows' i8042prt.sys work on ReactOS.
Addendum to cf0bc1c132
Implement the correct start-stop sequence for resource rebalancing
without the actual rebalancing. Also move IoInvalidateDeviceState
processing into the enumeration thread as it should be.
CORE-17519
We have a special file, tag.h, which serves as a place to store whatever kernel pool allocation tag yet we still have some tags sparse over the kernel code... So just re-group them in one unique place.
Only resources of HAL were checked against conflicts, not those of PnP Manager
Let IoReportResourceForDetection() make a silent conflict check.
Otherwise IopCheckResourceDescriptor() will always return 'no conflict'.
CORE-17789
Previous code did not detect equal resource ranges as conflicting.
Thanks Hervé Poussineau for pointing this out!
Meanwhile, simplify the code to make it more readable.
for manually reported devices, as it is required by the newdev.dll
for installing drivers from INF files
CORE-17212 CORE-17398
Co-authored-by: Stanislav Motylkov <x86corez@gmail.com>
This control class is triggered when a driver is being installed for a
non-critical device. The driver info should already be in the registry
so we just need to push the device through the state graph
Meanwhile, combine the code for similar control classes into
PiControlSyncDeviceAction routine
CORE-17463 CORE-17490
During the boot process, it makes possible to initalize the driver's
devices right after the driver is loaded. Moreover, this way one can be
sure that all critical devices are initialized before the
IopMarkBootPartition call (because we explicitly call the driver's
AddDevice routine now, after each driver is loaded)
CORE-7826
- Use DeviceNode->State field and its values, instead of
DeviceNode->Flags for tracking current node state
- Change DNF_* flags to the ones compatible with Windows XP+
- Simplify state changes for device nodes and encapsulate all the logic
inside the PiDevNodeStateMachine routine. This makes the ground for
future improvements in the device removal sequence and
resource management
- Now values inside DeviceNode->State and ->Flags are compatible with
the windbg !devnode macro and can be tracked using it
- BUGFIX: fixed cases where IRP_MN_START_DEVICE or
IRP_MN_QUERY_DEVICE_RELATIONS may be sent to a device after a
IRP_MN_REMOVE_DEVICE
CORE-7826