Problem with the OSR Recognizer driver

Problem with the OSR recognizer driver

Hi,

My problem is as follows -

I’m using the OSR recognizer driver on Vista SP1 machines and I have a problem with card reader devices. If first I connect a card reader to the machine (via USB) and just afterwards insert a SD-card into the card reader, the Recognizer driver does not notifies the OSR Filter driver, and thus the Filter driver is not attached to the volume stack of this SD-card volume. (if I insert the SD card to the card reader, and then plug the card reader to the machine, the Recognizer notifies the Filter and the Filter attaches to the stack.)
after digging in the code I found that the Recognizer receives the IRP_MN_MOUNT_VOLUME when the SD-card is inserted to the card reader, but in its completion routine (MountFsCompletion() in fsdetect.cpp) it returns and not notifies the Filter about the new volume.

The completion routine enters the following condition -
if (realVpb != currentIrpStack->Parameters.MountVolume.Vpb)
and returns STATUS_SUCCESS, instead of continuing in the function flow and notifying the Filter about the new volume.

The following explanation exists just before the above if statement -

// Get the VPB out of the storage device. If this is different than
// what is in the current stack location we know that:
//
// 1) This is a remount
//
// 2) The VPB in the stack location is poison (i.e. freed pool)

a more detailed explanation exists in dispatch.cpp, where we set the completion routine when we get IRP_MN_MOUNT_VOLUME -

//
// It is important to note that in the case of a
// remount the underlying filesystem may free the VPB
// in the current stack location and substitute it
// with a previous VPB that we are already filtering.
//
// The way that we are going to detect this is pass the
// storage device in the VPB in the stack location as
// the context to the completion routine. Once the completion
// routine runs, we’re compare the backpointer to the
// VPB in the storage device to what is in the stack location.
// If they are different, then the VPB in the stack location
// has been freed and the VPB in the storage device points
// to the older, already filtered VPB

in my case, the completion routine enters the above if statement, and thus returns instead of notifying the Filter driver about the new volume.

From what I understood, the Parameters.MountVolume.Vpb might be changed after passing the IRP down to the file system and this is what we check in the above if statement. however, in my case, I printed the values of Parameters.MountVolume.Vpb
and storageDevice->Vpb (which is the realVpb in the if statement) and found that the last one is the one that changed by the file system underneath us! not the
currentIrpStack->Parameters.MountVolume.Vpb ! and this is what causes the completion routine to enter the above if statement and to return.

So the question is what is going on and how may I fix the issue?

Thanks!

This issue is fixed in the latest FDDK.

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntfsd…
> Problem with the OSR recognizer driver
>
> Hi,
>
> My problem is as follows -
>
> I’m using the OSR recognizer driver on Vista SP1 machines and I have a
> problem with card reader devices. If first I connect a card reader to the
> machine (via USB) and just afterwards insert a SD-card into the card
> reader, the Recognizer driver does not notifies the OSR Filter driver, and
> thus the Filter driver is not attached to the volume stack of this SD-card
> volume. (if I insert the SD card to the card reader, and then plug the
> card reader to the machine, the Recognizer notifies the Filter and the
> Filter attaches to the stack.)
> after digging in the code I found that the Recognizer receives the
> IRP_MN_MOUNT_VOLUME when the SD-card is inserted to the card reader, but
> in its completion routine (MountFsCompletion() in fsdetect.cpp) it returns
> and not notifies the Filter about the new volume.
>
> The completion routine enters the following condition -
> if (realVpb != currentIrpStack->Parameters.MountVolume.Vpb)
> and returns STATUS_SUCCESS, instead of continuing in the function flow and
> notifying the Filter about the new volume.
>
> The following explanation exists just before the above if statement -
>
> // Get the VPB out of the storage device. If this is different than
> // what is in the current stack location we know that:
> //
> // 1) This is a remount
> //
> // 2) The VPB in the stack location is poison (i.e. freed pool)
>
> a more detailed explanation exists in dispatch.cpp, where we set the
> completion routine when we get IRP_MN_MOUNT_VOLUME -
>
> //
> // It is important to note that in the case of a
> // remount the underlying filesystem may free the VPB
> // in the current stack location and substitute it
> // with a previous VPB that we are already filtering.
> //
> // The way that we are going to detect this is pass the
> // storage device in the VPB in the stack location as
> // the context to the completion routine. Once the completion
> // routine runs, we’re compare the backpointer to the
> // VPB in the storage device to what is in the stack location.
> // If they are different, then the VPB in the stack location
> // has been freed and the VPB in the storage device points
> // to the older, already filtered VPB
>
>
> in my case, the completion routine enters the above if statement, and thus
> returns instead of notifying the Filter driver about the new volume.
>
> From what I understood, the Parameters.MountVolume.Vpb might be changed
> after passing the IRP down to the file system and this is what we check in
> the above if statement. however, in my case, I printed the values of
> Parameters.MountVolume.Vpb
> and storageDevice->Vpb (which is the realVpb in the if statement) and
> found that the last one is the one that changed by the file system
> underneath us! not the
> currentIrpStack->Parameters.MountVolume.Vpb ! and this is what causes the
> completion routine to enter the above if statement and to return.
>
> So the question is what is going on and how may I fix the issue?
>
> Thanks!
>
>
>
>
>

OK, thanks, but is there an option to know what was the fix?
I don’t want to also buy the new OSR FDDK just for this specific fix…

Note that NTFSD is not the OSR Software Support mailing list.

If you’re a licensed user of an OSR product, please submit your bugs, questions, or issues to use via the OSR Bug Reporting alias provided to the technical contact at your company. We have a whole team of people who monitor the OSR Bug Report alias, as well as a system to automatically record and track problem reports and inquiries we receive from clients. None of that is engaged via NTFSD. Heck, here at OSR we don’t necessarily even READ NTFSD every day.

Thanks,

Peter
OSR

P.S. THREAD LOCKED.

The update is free as long as you’re covered under support.

Please take further discussion of this issue to the OSR support alias. Email me directly if you don’t know what that is, and I’ll hook you up with our customer support people.

Peter
OSR