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


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:

PCIe Gen 3 Device uses MSI-X, no Interrupt Resources in IRP_MN_FILTER_RESOURCE_REQUIREMENTS

painkepainke Member Posts: 4


I have an issue with our newest generation of devices which use MSI-X on Windows (verified on 7 and 10) and I'm really stuck, maybe someone can point me in the right direction?

In the INF, the HW section adds the registry keys necessary for MSI/X and the values get written in the registry correctly.
This approach worked very well with our previous generation of devices which used a single MSI.
However, in the newest generation, when I receive the IRP_MN_FILTER_RESOURCE_REQUIREMENTS from the PnP manager, only the memory resources are listed. No Interrupts.

When I check the config space, I see that MSI-X is not enabled (0x8000 is not set in the Message Control field of the MSI-X capability).

I tried an intel 10G network card, which successfully uses 18 MSI-X per function, so from this side it works.

I'm a bit at loss, because from what I understand, there's no way I have to (or even CAN) enable MSI-X from within the driver code.
Am I missing something? Are there any additional requirements?

Our device uses 6 MSI-X, the Message Control field is set accordingly to 0x0005. We have BAR 4 reserved in 64-bit mode for MSI-X Table and PBA, Table starts at offset 0, PBA starts at offset 0x50 (a bit arbitrary, I know; but we tried to change this value to no effect).

Any help?

Thanks very much in advance,


  • painkepainke Member Posts: 4

    Sorry, some additional information / clarifications ...

    By "the registry keys" I mean "HKR,Interrupt Management\MessageSignaledInterruptProperties,MSISupported,0x00010001,1" and "MessageNumberLimit".

    Of course, IRP_MN_START_DEVICE won't list the interrupts either. But IRP_MN_FILTER_RESOURCE_REQUIREMENTS is the earliest point where I should get reported all available configurations. As far as I understand, I can't just add interrupt resource descriptors here and they will magically work ...

    We have several firmwares for the device, some with legacy interrupt support, some without. If legacy interrupt is enabled, only the legacy interrupt is enabled and reported in IRP_MN_FILTER_RESOURCE_REQUIREMENTS. MSI-X is left disabled.

    The device is verified to work under Linux, including all 6 interrupts.

  • painkepainke Member Posts: 4

    To answer myself, just in case someone else might run into this problem. We found the issue.

    If things run under Linux at least you can assume that the interrupt system in itself works.
    But Linux does not do any checks on consistency of the settings, and neither do the tools of some FPGA manufacturers that you might use to setup the cores for PCIe and MSI-X.

    Windows, however, does do these consistency checks and will reject MSI-X. Albeit without telling you why.

    Our problem was that a) the vector table and the PBA had an overlap (calculate the size of the vector table and make sure the PBA offset is large enough) and b) after fixing the offset, the BAR size was not large enough anymore (make sure the BAR size setting is large enough to hold both the vector table and the PBA if you chose not to use separate BARs).

    As always, reading the Specification (PCI 3.0) calculating the sizes and double checking the settings on FPGA cores (which reflect in config space) .

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,160

    Thank you for posting the follow-up and ultimate resolution to your problem.

    Sorry we weren't able to help you more directly...


    Peter Viscarola

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online