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:

INVALID DEVICE REQUEST (Control 0x90390 (Device 0x9 Function:228 Method: 0))

blangeblange Member Posts: 18


I have written a virtual storport miniport acting as a virtual USB stick. When running applications from it, most applications run smoothly.
However, some applications get "stuck" (discontinue IO requests).

When running PROCMON it points me to a FileSystemControl Error : INVALID DEVICE REQUEST (Control 0x90390 (Device 0x9 Function:228 Method: 0))

I assume that my virtual storport is lacking a certain functionality, however, so far I was not able to translate the PROCMON result into a missing SCSI request.
Does anybody has encountered this problem and can point me in the right direction?

Best wishes


  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,845
    edited May 2019

    It seems unlikely this is the Request that's directly causing the failure. It seems to be:


    but this is a file system request, not a request to your driver...


    Post edited by Peter_Viscarola_(OSR) on

    Peter Viscarola

  • blangeblange Member Posts: 18

    Dear Peter,

    Thank you for pointing this out.
    The reason I came up with this is related, that I have identified a single problematic file. If I softlink the file to a position outside the virtual device, the application runs smootly and the File System Control Request is not visible in Procmon. Maybe my device capabilities trigger the different behavior.

    I am currently exploring if the application has DRM protections or Virtual device protections in place.
    The application runs smoothly from Microsoft VHD, though, but was reported to not run on Microsoft Storage devices.

    I am not sure how to boil this problem further down. Any thoughts are highly appreciated.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,845

    Well, procmon seems to me to be a rather unusual place to be monitoring your virtual storport driver.

    Are you completing any requests at your Miniport with errors?

    If no, it has to be some capability that your Miniport is returning/not supporting.

    I’ve posted this before, and I know it’s a lot of money, but our experience is that the software tool named “busTrace” can be a very helpful tool in diagnosing virtual storport drivers. For the record, we have no interest in or relationship with the company that makes this tool (other than the fact that they’ve comp’ed up licenses from time to time over the years... but not recently... and found it very helpful in finding bugs in our own code)..


    Peter Viscarola

  • blangeblange Member Posts: 18

    Hi Peter,

    Thank you for recommanding busTrace. I will have a look into this and try the busTrace Reader for an evaluation. So far I used HLK for "major debugging": HLK identifies our driver as HBA as well as disk if a virtual disk is mounted and is scheduling tests against it, which we are all passing.

    With respect to failed requests: I see some incoming SRB_IO_CONTROL requests, which we are not supporting and in general answer with SRB_INAVLID_REQUEST. So far my research did not show me mandatory IO_CONTROL requests which have to be supported. I also admit that I not fully grasp MSDN here, labeling this IO_CONTROL as private device communication. Is private intended as vendor specific IOCTL, or can (and should) any user space application be able to use them?

    With respect to the capabilities: I am so far aware of the device capabilities in the FIND_ADAPTER initialization, the plug and play capabilities in SRB_PNP_FUNCTION, the MODE_SENSE reports, where we only support the requests necessary for HLK, as well as a basic (required?) WMI support, where we also only support the HLK requests.

    Best regards

  • blangeblange Member Posts: 18

    After analyzing the behavior with busTrace on a working HDD and my virtual storport, I see that the HDD can answer the read requests with 1024 blocks at a single CDB/SRB, while my driver is only answering with 17 blocks at maximum.
    The Maximum Transfer Length in the PORT_CONFIGURATION_INFORMATION in the findAdapter routine is set to SP_UNINITIALIZED_VALUE.
    I am not aware of other possibilities to set this value, so far.

    So I guess I should focus on how to increase the maximum transfer lengths for the SRBs?

    Does anybody know how? ;-)

    Best regards

  • blangeblange Member Posts: 18

    I found the necessary switch: NumberOfPhysicalBreaks was set to 0x11 by default = 17 blocks.
    However, my target application is still not running from the drive, but at least I have a nice performance boost :-)

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