Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Driver load order / Device load order

yoavwinyoavwin Member Posts: 2

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

Comments

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,299

    (Moved to NTDEV)

    -scott
    OSR

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,442

    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, [email protected]
    Providenza & Boekelheide, Inc.

  • yoavwinyoavwin Member Posts: 2

    @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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA