During investigation into some of the USB stack issues we've been running into I've found that when a USB storage device is already plugged in during boot and removed before it finishes initialization we run into this assert.
The logic in this function removes the pools made for the following entries in DeviceExtension indiscriminately this makes debugging a bit more difficult. Instead of depending on this behavior of ALWAYS being filled with valid data, let's free the following pools ONLY if they're initialized. This change prevents us from bugchecking when USB flash drives are removed early during boot. This makes the debugging experience a little more sane.
At first QueryStatus call, output is written to Irp->AssociatedIrp.SystemBuffer.
Unfortunately, this is also the BattWait buffer.
At return of QueryStatus call, BattWait buffer has been modified, so
following code can't use it anymore.
Fix memory overwrite by copying BattWait buffer on the stack.
- Reimplement WriteWord using the WriteByte helper.
- Remove inline qualifiers from the bus read and write functions.
This code path is considered "cold" and using an inline for it is overkill.
- Don't apply the IRQL restrictions to our PnP state transition helpers.
They are only called at IRQL below dispatch level.
- Properly handle the case when the dependent function is placed
after fixed resources
- Initialize the version and revision fields of resource lists
- Improve validation of resource data
- Add more debug prints
CORE-18562
CORE-17200
Helps reducing debug log noise like:
```
(drivers\storage\port\scsiport\ioctl.c:542) unknown ioctl code: 0x4D0018
```
The other notifications are already implemented there.
These are handled by the volume manager, which is currently
stubbed into ReactOS' partition manager.
See commit ed27d733f7 for what the deprecated versions
of IOCTL_MOUNTDEV_LINK_[CREATED|DELETED] are all about.
CORE-18139
When a partition is created, PartMgr notifies the volume manager
(FTDisk on Windows <= 2003, VolMgr on Vista+) of its presence.
(Note that currently in ReactOS, our partmgr does the job of both
PartMgr *AND* VolMgr.)
The VolMgr then sends a `GUID_DEVINTERFACE_VOLUME` PnP notification,
which is handled by the mount manager (MountMgr) as part of a
`GUID_DEVICE_INTERFACE_ARRIVAL` notification:
```
MountMgr!MountMgrMountedDeviceNotification -> MountMgrMountedDeviceArrival
followed by
MountMgr!MountMgrTargetDeviceNotification
```
When a partition is deleted, via e.g. Disk Management or DiskPart,
it can be observed, on Windows, that the PartMgr gets notified by
the PnP manager, as part of QueryDeviceRelations. Before actually
removing the partition, it notifies the VolMgr. The latter invalidates
any volume mounted on that partition (`*PartitionRemoved*` functions
for basic volumes), then requests (`*DeleteMountPoints` function)
the MountMgr to delete all the mount points associated to the volume:
```
VolMgr!*DeleteMountPoints
-> MountMgr!MountMgrDeviceControl -> MountMgrDeletePoints
```
**** THIS is the new functionality that is implemented for ReactOS ****
**** in the present commit. ****
Following this, a subsequent PnP notification is sent, which calls
```
MountMgr!MountMgrTargetDeviceNotification
-> MountMgr!MountMgrMountedDeviceRemoval
```
(Note that this observation somewhat invalidates the modification
made in ReactOS commit 62a4f9d42b : our MountMgr placed in Windows
*WOULD* receive a `GUID_TARGET_DEVICE_REMOVE_COMPLETE` target-device
notification...)
Finally, a `GUID_DEVICE_INTERFACE_REMOVAL` PnP notification is sent
to the MountMgr:
```
MountMgr!MountMgrMountedDeviceNotification
-> MountMgr!MountMgrMountedDeviceRemoval
```
1. MountMgrMountedDeviceArrival():
Fix the conditions under which the device's online notifications
are skipped (SkipNotifications == TRUE) and fix the code comments.
Now, things make much more sense:
online notifications are skipped when the device is already offline
or is a legacy (NT <= 4) fault-tolerant volume (see point 2 below),
or is NOT mounted (doesn't have a drive letter).
Previously, we were sending an online notification if the device
was NOT mounted (why?!...) or if it was deemed as "valid" (wrongly
determined, see point 2 below).
2. QueryDeviceInformation():
* The usage of the "Valid" parameter didn't make much sense. Indeed,
when a partition/volume device is reported to the Mount Manager,
it's already valid. (Also, setting "Valid" to TRUE only in the case
of an MBR partition while ignoring GPT ones, and resetting it to
FALSE if IOCTL_STORAGE_GET_DEVICE_NUMBER returned success, pointed
to something incorrect was going on.)
Instead, what we are checking here is whether the device is a
legacy fault-tolerant volume: such volume can only reside on an
MBR disk, have the expected partition type, and does not really
reside on a specific storage device (hence the check for
IOCTL_STORAGE_GET_DEVICE_NUMBER returning failure).
* Take also the opportunity to SAL2-ify the function.
This "NoAutoMount" member was not consistently used. Sometimes it was
used correctly, some other times it was used as "not NoAutoMount" i.e.
"AutoMount" enabled.
Fix this consistently throughout the source, and fix also some comments.
Windows has all its network drivers inf files in 8.3.
This is an addendum to 0.4.15-dev-52-g 019f21ee1d
which moved us further away from our target.
The commit on its own was a good idea actually to get the inf into the drivers directory
and therefore simplifies adding and excluding drivers more locally (e.g. excluding works by
adding a single hashtag within the specific drivers CMakeLists.txt now).
But that cool feature doesn't require us to move away from our target.
For the record:
The historic netrtpnt.inf and netisa.inf (both 8.3) have been merged to
netne2000.inf (not 8.3) by 0.4.15-dev-2763-g 6924b8ff39
Unification of that was cool too,
but again: 8.3 is superior. Therefore netne.inf for that.
Worst of all: Since the .inf files did contain their filename within a comment also, that means
the historic renaming by the mentioned commit invalidated that comment.
netamd.inf fixed by restoring the ancient filename before 0.4.15-dev-52-g 019f21ee1d
netrtl.inf fixed by restoring the ancient filename before 0.4.15-dev-52-g 019f21ee1d
netne.inf I fixed the comment manually.
This is the network driver which is used for MSVPC 2007.
I spotted it during a WIP-backport-experiment of the driver, when compiling with GCC4.7.2, which warned about it.
GCC8.4.0 unfortunately is blind to that on master head, for unknown reasons. Not good.
MSVC github buildbot is also blind to that on master head, for unknown reasons. Not good.
We later found that at least Clang did also warn about it on master head.
Fix IOCTL_MOUNTDEV_LINK_CREATED, IOCTL_MOUNTDEV_LINK_DELETED,
IOCTL_MOUNTDEV_UNIQUE_ID_CHANGE_NOTIFY, to Win2k3+ compatible definitions.
The previous versions of these IOCTLs (in Win2000 and XP) were defined without any access protection.
This was noticed here:
https://community.osr.com/t/ioctl-mountdev-link-created-definition-changed/29428
CORE-15575
In addition, fix a PartitionId assignment copy-paste error in PartitionCreateDevice().
The returned standard UniqueId has the following format:
- Basic volume on MBR disk: disk Mbr.Signature + partition StartingOffset (length: 0x0C)
- Basic volume on GPT disk: "DMIO:ID:" + Gpt.PartitionGuid (length: 0x18)
- Volume on Basic disk (NT <= 4): 8-byte FTDisk identifier (length: 0x08)
- Volume on Dynamic disk (NT 5+): "DMIO:ID:" + dmio VolumeGuid (length: 0x18)
- Super-floppy (single-partition with StartingOffset == 0),
or Removable media: DiskInterfaceName.
- As fallback, we use the VolumeInterfaceName.
References:
- https://winreg-kb.readthedocs.io/en/latest/sources/system-keys/Mounted-devices.html
- https://stackoverflow.com/a/72787681/21852502
- Manual testing on Windows.
CORE-15575
Detect whether the disk is a "super-floppy", which is the name given
to partitionless disk having no MBR, with the unique partition volume
starting at sector offset zero and spanning the whole disk.
The name comes from the fact that at the partitioning level, the disk
"looks like" a large-capacity floppy disk.
This is typically how external removable (USB, ...) drives are
partitioned by default by Windows.
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq?view=windows-11#superfloppy
The kernel-mode functions IoReadPartitionTable() / IoWritePartitionTable()
report the drive layout of a "super-floppy" disk as follows:
an MBR-style disk containing only one single partition starting at the
beginning of the disk (StartingOffset == 0) without hidden sectors, and
its type being FAT16 non-bootable.
The disk NTFT signature is set to 0x00000001.
----
Additional bug fixes to make the feature work reliably:
- Make PartMgrGetDriveLayout() also update the FDO DiskData's
PartitionStyle and Signature/GPT DiskId for consistency (code moved
from PartMgrRefreshDiskData()).
- In FdoIoctlDiskSetDriveLayout[Ex](), if the disk is "super-floppy",
but the user wants to create more than one partition, fail the call.
(In the Ex call, fail also if the partition style changes.)
warning C4267: 'function': conversion from 'size_t' to 'ULONG', possible loss of data'
The OutputBufferLength member that was temporarily stored in
outBufferLength is already a ULONG, and IssueSyncIoControlRequest()
takes the length as a ULONG. So there is no need to use 'size_t' here.
- Implement IOCTL_VOLUME_QUERY_VOLUME_NUMBER:
See usage example in:
7241cebfa2/mayfield/branches/spr/src/umapps/ndassvc/service/drivematch.cpp (L627)
- Stubplement IOCTL_VOLUME_IS_PARTITION:
The only type of volume we support right now is disk partition
so we just return success. A more robust algorithm would be
to check whether the volume has only one single extent, that
covers the whole partition on which it lies upon. If this is
not the case, return STATUS_UNSUCCESSFUL instead.
Add ReactOS change to use the same Decibel (dB) sound loudness range for Master Volume control as for WaveOut Volume Control.
This fixes incompatible volume level change scaling when changing the volume in Fox Audio Player 0.10.2 from Rapps and Winamp 2.95 with WaveOut output plugin.
Now it is identical to the one when using original AC97 driver from Windows XP/Server 2003.
CORE-14780
* [UDFS] Clang: Fix a #pragma
'warning: unknown warning group '-Wstringop-overflow', ignored [-Wunknown-warning-option]'
Follow-up to 612b1f2e6 (0.4.15-dev-1129).
* [CREATESPEC] Clang: Fix a target_compile_options()
'warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]'
Addendum to 00ed72d7e (0.4.15-dev-1169).
* [MSVCRT_WINETEST] Clang*: Fix a target_compile_options()
'warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]'
Addendum to commits 00ed72d7e (0.4.15-dev-1169) then f155b9377 (0.4.15-dev-4612).
* [TELNET] Clang*: Fix a target_compile_options()
'warning: unknown warning option '-Wno-restrict' [-Wunknown-warning-option]'
Addendum to 447ef2aa4 (0.4.15-dev-4613).
As the commit title says, the point of registering a device interface with ACPI fans is to receive incoming PnP notifications of incoming ACPI fan drivers so that the power manager can connect to them by creating a power device policies dedicated to them during power manager initialization.
CORE-18969
Implement GetWavePosition API for both Legacy and MMixer modes.
[WDMAUD.DRV]
- Fix wrong I/O control code passed to DeviceIoControl for Legacy mode. Use IOCTL_GETPOS instead of IOCTL_OPEN_WDMAUD, to use the correct routine.
- Implement WdmAudGetWavePosition for MMixer mode, as it was completely unimplemented there. Call an appropiate MMixer routine and return back resulting wave position.
[WDMAUD]
- Implement WdmAudGetPostion routine, which is used by Legacy mode, and call the same MMixer routine from it too.
- Handle it in IOCTL_GETPOS I/O control request of dispatch routine.
[MMIXER]
- Implement MMixerGetWavePosition internal routine, which is called by both Legacy and MMixer modes, and does the actual work of retrieving playback position.
- Call an apporpriate KSPROPERTY_AUDIO_POSITION property from it, and return in the output resulting KSAUDIO_POSITION.PlayOffset member, which contains the current playback position offset, to be returned to the caller.
This fixes a failure retreiving the current audio playback position snd subsequent playing the audio data by several 3rd-party applications which are using this API (for example, some Gecko based browsers by @roytam1: Basilisk (Serpent) 52.9.0 IA-32 build, NewMoon 28.10.7 IA-32 build and KMeleon 76.5.3 Goanna engine).
CORE-19542
[MMIXER] Implement hadling WAVE_FORMAT_EXTENSIBLE audio format
Fix opening audio device error when trying to open it with WAVE_FORMAT_EXTENSIBLE format tag set in wFormatTag member of WAVEFORMATEX:
- Pass additional data size from WAVEFORMATEX.cbSize to pin data format.
- Append it to the whole size of pin data format (KSDATAFORMAT.FormatSize).
- Set additional fields in WAVEFORMATEXTENSIBLE structure (data format, BPS and channel mask) when WAVE_FORMAT_EXTENSIBLE is used. They are used by our inbuilt Intel AC97 miniport driver at least. It simply fails when these members are not set.
- Fix pin connect allocation size by appending an additional data size from WAVEFORMATEX.cbSize to KSPIN_CONNECT + KSDATAFORMAT + WAVEFORMATEX. This allows to proerly initialize additional extensible data and avoids kernel memory leakage when using extensible audio format.
- Remove format tag check which allowed WAVE_FORMAT_PCM to be opened correctly. So now all possible audio formats can be opened properly at least (although it does not mean they may work correctly).
This fixes the audio playback for all apps those are supporting extensible audio data and use it by default (e. g. AIMP 5.30, QMMP 0.12.17, all Chrome/Chromium-based browsers, GameDev Tycoon Demo game etc.).
CORE-10907, CORE-14783
* [KS] Allow passing additional extensible audio data when extensible audio format is used
- Append additional data size from WAVEFORMATEX.cbSize to pin connect size passed to KsCreatePin. If the tag is WAVE_FORMAT_PCM, then this member should always be zero. So in that case, no any additional data is passed to creation request, and the passed data size is correct for PCM too (KSDATAFORMAT + WAVEFORMATEX).
This fixes audio playback in several apps those are supporting extensibble audio and use it by default (e. g. AIMP 5.30, QMMP 0.12.17, all Chrome/Chromium based browsers, GameDev Tycoon Demo game etc.).
CORE-10907, CORE-14783.
* [WDMAUD.DRV] Pass the correct additional data size to I/O control request
Store a correct size of additional data in WAVEFORMATEX.cbSize when performing open of audio device, when WAVE_FORMAT_EXTENSIBLE audio format is used.
It allows to properly open audio device with Legacy APIs enabled too.
This fixes audio playback in several apps those are using extensible audio data (e. g. AIMP 5.30, QMMP 0.12.17, all Chrome/Chromium based browsers, GameDevTycoon Demo game etc.).
CORE-10907, CORE-14783
CORE-17256
- Implement support for complex input buffers.
This will enable the IDE driver with some hack
to execute the _STM (channel timing settings) control method.
- Fix a memory leak.
- Fix returned status code.
- Correctly calculate the output buffer size.
- Improve buffer validation.
- Implement support for async control requests.
- Implement local reference conversion.
- Implement support for subpackage argument conversion.
- Place some code into INIT section.
