I am developing a storport virtual miniport and developing a test suite for it at the same time. As I am slowly adding features to the miniport and attempt to test them, a constant annoyance is the partmgr which insists on sending requests thus interfering with my testing.
Is there any simple way to convince the rest of Windows to leave my miniport alone while I am testing it? I would like to be able to send it specific CDB’s via IOCTL_SCSI_PASS_THROUGH_DIRECT and thoroughly check responses for rigorous testing. Partmgr’s own requests alter the state of my virtual device and affect the testing.
I am new to the world of storport miniports so apologies if I am missing something obvious.
Well, it depends on what you want/need to do. What requests from partmgr are bothering you?
Do you need to have a recognized file system or partition on your virtual disk? If not, that would prevent interference, wouldn’t it?
If you really want JUST your own requests you might be able to put a filter below disk class and throw away any requests you don’t like, open that filter and use it to forward your pass-through requests. It’s be quick enough to whip up in WDF that it would be worth a try.
What do you think?
Peter
Peter, thank you for your response.
What I am developing is a miniport that forwards READ, WRITE, SYNCHONIZE CACHE and UNMAP requests to user mode; this is done by placing the aforementioned SRB’s in a queue and a user mode process retrieving them using DeviceIoControl.
My problem is that during testing I construct specific scenarios to test my queue, only to have these tests fail because the partmgr (or other Windows component?) sends me unexpected SRB’s (i.e. ones that my test cannot account for.) For example, if I construct a test where I send a READ SRB with specific parameters, my test expects to see that SRB in the queue, but it may instead receive one from the partmgr. To aggravate this problem it does not appear to be deterministic when this happens.
So I am looking for a way to temporarily disable the partmgr for my device during testing. I understand that developing a filter might be a solution for this problem, but it sounds excessive for my needs (and also brings to mind the “now you have two problems” aphorism).
The problem is that your child device is being presented to Windows as a disk, so Windows is going to try to use it like a disk. It seems unlikely to me that PartMgr is arbitrarily communicating with your disk, more probably something else is talking to the disk and PartMgr is just acting on orders.
You might be able to get “good enough” behavior by marking the disk as offline and hidden prior to your test (we were just talking about this in another thread). If that proves to be insufficient I would probably go the route of replacing the function driver for your device under test.
For example, you could write a custom WDF driver that just forwards SCSI passthrough requests to the PDO. You could then install it as a more specific compatible or hardware ID match to the PDO that gets enumerated from your bus driver. This is pretty much exactly what we did for a client a few years ago for creating a similar framework but for device validation (it even had a scripting language for crafting arbitrary CDBs).
brings to mind the “now you have two problems” aphorism
That’s one of my favorites, by the way.
I suggested it because WDF makes writing such a filter so damn easy. You could, quite literally, have it going in a couple of hours. This is, of course, assuming you know WDF.
Scott’s suggestion (immediately above) is even better than mine, and also dead simple (again, assuming you know WDF). To try to clarify what he’s suggesting: Look at the list of Hardware IDs that StorPort returns for your device. Choose one of those that is MORE SPECIFIC than “gendisk” – which is what causes the Disk Class driver to claim your PDO. You then write a Function Driver that claims this MORE SPECIFIC hardware ID, causing your newly written function driver to be chosen by Windows in preference to the standard Windows Disk Class driver. You write an app that opens your Function Driver’s device object, and your function driver just forwards SCSI Passthrough requests.
Peter
Scott and Peter thanks again for your responses.
Clearly there is a lot for me to learn as I admit to have an incomplete mental model of how everything fits together in this space. I will try to better understand your suggestions and see if I can put them to good use.
Scott, I have seen the other thread, but did not immediately see how it could be used in my testing. The problem (I think) is that for me to mark the device as “offline” it would have to first properly handle and respond to a number of SRB’s. But I do not fully trust my SRB handling yet; the objective of my testing is exactly to fix problems in this handling and build confidence in it.
For the record I have accidentally found that if I do not respond with a proper ProductId and ProductRevisionLevel (i.e. if I leave both fields zeroed out) from SCSI INQUIRY, then the partmgr (or whichever component is responsible) leaves my device alone. This of course smells like a hack, but may be good enough for this initial testing.
Bill