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?
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.
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)…
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.
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?
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
