From MSDN:
It is an error to call KeReleaseSpinLockFromDpcLevel if the specified spin lock was acquired by calling KeAcquireSpinLock because the caller's original IRQL is not restored, which can cause deadlocks or fatal page faults.
- Use PnP storage class drivers
- Make partmgr an upper filter driver for Disk class
- Fill upper filters in txtsetup and usetup/devinst
- Add cdrom driver to the critical device database
CORE-6264
- Pass all SRB flags which Windows scsiport passes
- Correctly reset the queue after completion
This fixes the bug when MS cdrom driver hangs after media ejection
Basic functions are implemented in order to work in PnP stack,
only legacy (non-pnp) miniport drivers are supported.
Tested mostly with uniata
CORE-17132
This driver works as complement to disk.sys/classpnp.sys from Windows 10
Manages partition PDOs and exposes them as volumes to mountmgr.sys.
The driver is almost complete, just some minor IOCTLs missing (will be
added on demand)
- ReparseFile was concatenated with itself, instead of ReparseIndex
- Meanwhile, use RtlAppendUnicodeStringToString for concatenating
strings instead of raw memory operations
- Change INIT_FUNCTION and INIT_SECTION to CODE_SEG("INIT") and DATA_SEG("INIT") respectively
- Remove INIT_FUNCTION from function prototypes
- Remove alloc_text pragma calls as they are not needed anymore
Instead of messing with global variables and the like, we introduce two target properties:
- WITH_CXX_EXCEPTIONS: if you want to use C++ exceptions
- WITH_CXX_RTTI: if you need RTTI in your module
You can use the newly introduced set_target_cpp_properties function, with WITH_EXCEPTIONS and WITH_RTTI arguments
We also introduce two libraries :
- cpprt: for C++ runtime routines
- cppstl: for the C++ standard template library
NB: On GCC, this requires to create imported libraries with the related built-in libraries:libsupc++, limingwex, libstdc++
Finally, we manage the relevant flags with the ad-hoc generator expressions
So, if you don't need exceptions, nor RTTI, nor use any runtime at all: you simply have nothing else to do than add your C++ file to your module
The source code is licensed under MS-PL license, taken from Windows Driver Samples
repository (microsoft/Windows-driver-samples@master/storage/class/cdrom/)
Synched with commit 96eb96dfb613e4c745db6bd1f53a92fe7e2290fc
The driver is written for Windows 10 and uses KMDF so we compile it with ntoskrnl_vista
and wdf01000 statically linked (for wdf01000 this will likely be changed in future)
CORE-17129
The source code is licensed under MS-PL license, taken from Windows Driver Samples
repository (https://github.com/microsoft/Windows-driver-samples/tree/master/storage/class/disk/)
Synched with commit 3428c5feaac7c1a5e2a09db0ed93392f7568f9e6
The driver is written for Windows 8+, so we compile it with ntoskrnl_vista
statically linked and with NTDDI_WIN8 defined
CORE-17129
The source code is licensed under MS-PL license, taken from Windows Driver Samples
repository (https://github.com/microsoft/Windows-driver-samples/tree/master/storage/class/classpnp/)
Synched with commit 88541f70c4273ecd30c8c7c72135bc038a00fd88
The driver is written for Windows 8+, so we compile it with ntoskrnl_vista
statically linked and with NTDDI_WIN8 defined
CORE-17129
It started to spam when more components of the MountMgr
were coded during 0.4.14dev.
According to Victor Perevertkin it is not crucial for us
to see it, as those are 'optional MountMgr features'.
Imho this points towards unimplemented stuff.
No official ros release has been affected, because I did
revert most of the new MountMgr features for 0.4.14release
earlier.
JIRA-user "Illen" reported booting from his Z170 controller worked up to
0.4.12-dev-936-g89aaf0e
and would refuse booting - beginning with uniata commit
0.4.12-dev-937-g
b546130731
For sure this workaround is just a temporary and no proper solution,
but was confirmed to be working by "Illen".
We have no clear understanding of the real bug yet.
Can be replaced by something better at any time.
It was already committed into 0.4.12, 0.4.13, 0.4.14.
We never had an affected release therefore.
Since no one took care of this bug ever,
the workaround will now be committed to master as well.
cherry picked from commit 0.4.13-RC-9-g
11178f38e4
