IRQL_NOT_LESS_OR_EQUAL BSOD about ransomwatch HOT 2 CLOSED

It seems the issue lies in FsFilter::FSEntrySetFileName

hr = FltGetDiskDeviceObject(Volume, &devObject);
if (!NT_SUCCESS(hr)) {
	return hr;
}
hr = IoVolumeDeviceToDosName(devObject, &volumeData);

The ntddk doc says: Starting with Windows Vista, you must ensure that APCs are not disabled before calling this routine. The KeAreAllApcsDisabled routine can be used to verify that APCs are not disabled.

Indeed, if I check it like that, it seems to work perfectly:

hr = FltGetDiskDeviceObject(Volume, &devObject);
if (!NT_SUCCESS(hr)) {
	return hr;
}
if (KeAreAllApcsDisabled()) {
	return hr;
}
hr = IoVolumeDeviceToDosName(devObject, &volumeData);

Not sure it's the good way to do it though.

from ransomwatch.

A better solution would be to store Volume names to associate the volume from which the file was taken, that way there will be no need to check the name for every callback.
READ and WRITE FS callbacks might be called in high IRQL like you witnessed.
The solution you suggested limits the driver ability to detect file changes, some I/O might be ignored because of the high IRQL.

The issue might also occur if the driver didn't call FltDoCompletionProcessingWhenSafe on I/O which needs further validation from the driver after completing the operation (CREATE and READ).

Ensuring that Completion Processing is Performed at Safe IRQL

from ransomwatch.