Driver load order / Device load order

Hi! I found out about weird behavior of Hyper-V’s Virtual Switch Adapter which i’m trying to understand:
Basically when i’m attaching as a LowerFilter to the Network class - {4d36e972-e325-11ce-bfc1-08002be10318} on Windows Server 2019 the Network adapter is disabled in ncpa.cpl, but looks just fine in devmgmt.msc. Also using Hyper-V’s management GUI in order to remove that adapter results in the adapter being “leaked” - it is still visible in ncpa.cpl but it no longer shows in Hyper-V’s GUI.

My driver is a KMDF BOOT_START’ed driver which basically does nothing(note: it doesn’t matter if i attach or not the that stack), code:

#include <ntifs.h>
#include <wdf.h>

static __declspec(code_seg("PAGE"))
NTSTATUS DeviceAdd(WDFDRIVER Driver, PWDFDEVICE_INIT DeviceInit)
{
    NTSTATUS status = STATUS_SUCCESS;
    Driver; DeviceInit;

    WdfFdoInitSetFilter(DeviceInit);
    
    return status;
}

__declspec(code_seg("INIT")) EXTERN_C NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
    NTSTATUS status = STATUS_SUCCESS;

    PAGED_CODE();

    WDF_DRIVER_CONFIG driverConfig;
    WDF_DRIVER_CONFIG_INIT(&driverConfig, DeviceAdd);
    driverConfig.DriverPoolTag = 'abcd';

    WDF_OBJECT_ATTRIBUTES driverAttributes{};

    WDFDRIVER driver{};
    WDF_OBJECT_ATTRIBUTES_INIT(&driverAttributes);
    status = WdfDriverCreate(DriverObject, RegistryPath, &driverAttributes, &driverConfig, &driver);
    if (!NT_SUCCESS(status)) {
        __debugbreak();
    }

    return status;
}

Some other weird behaviors that occur:

  • When attaching as an UpperFilter instead the adapter is Enabled
  • The problem does not reproduce when the driver’s ImagePath is written in the “C:\Windows\System32\drivers\testKmdfFilter.sys” format, as opposed to “\SystemRoot\System32\drivers\testKmdfFilter.sys” format.

Now as far as i understand there are 2 interesting root-enumerated devices which i believe have switched their stack building sequence as a side-effect of me registering as a LowerFilter to them, though i do not understand why would that happen.

The devices hardware IDs are ROOT/VMS_MP and ROOT/VMS_VSMP, i’m not very good with NDIS so i do not understand their actual role.
I was wondering what reasons could flip those devices stack building order?

btw my KMDF filter driver does not belong to any group, it was registered using sc create and by registry tweaking so it has no special registry keys associated with it

(Moved to NTDEV)

I just want to confirm. You say it WORKS as “C:\Windows\System32…” but does NOT work as “\SystemRoot\System32…”? Because I could believe it the other way around, depending on how early you are in boot. The drive letter links are not created until later.

@Tim_Roberts yup, I believe that attaching to that particular device somehow “promotes” it to an earlier boot stage, and that by using the "C:" syntax i would accidentally delay that device’s stack building stage to the point where it would work correctly