none
Solution if IRP_MN_MOUNT_VOLUME is not called RRS feed

  • Question

  • Hello,
    I found a parry to bypass a windows kernel bug (only when a external storage disk is connected) about
    sending irp IRP_MN_MOUNT_VOLUME.
    If the IRP_MN_MOUNT_VOLUME is not called THEN Is it correct to modify the structure VPB-> DeviceObject directly in the deviceobject DCB ?
    I mean creating a VPB disk deviceobject with API function kernel 'IoCreateDevice' and setting DeviceObject-> VPB-> DeviceObject (in a deviceobject DCB).
    This method can this work good ???
    Frankly I have only this solution.

    Thank


    • Edited by Sizy458 Thursday, August 17, 2017 4:18 PM
    Thursday, August 17, 2017 4:16 PM

Answers

  • First you keep assuming Microsoft has a bug, any driver writer needs to assume they have a bug and it is their challenge to find it.  I've been working in Windows drivers for over 20 years, and in that time I found one bug in the Windows kernel support, and it had already been reported!

    You are complaining about 3 days, for a file system most of us estimate 9 to 18 months.

    Go back and look at how you can change your design to use the standard file system recognizer / file system model.   Right now you are just signing up for a lot of support headaches.

     


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, August 17, 2017 5:55 PM

All replies

  • This like all your questions so far seem to be about no dealing with volumes the way Microsoft intended.  I can't say whether this will work, and if it does work whether it will work with the next update of Windows or for that matter whether it works across the currently supported revisions of Windows since it is so far out of the norm. 

    As was stated before, go back and create a standard file system recognizer and file system, and don't try to hack things.  File systems are hard enough and complex enough in Windows without trying to do something with a supported solution in a different manner.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, August 17, 2017 4:44 PM
  • I can't find this problem , always finding a bug.

    3 days passed !.

    The only solution is Create VPB DISK AND SETTING VPB-> DeviceObject.

    And I intend to market my product once finished
    And that it works with me in a drinkable way.

    Thursday, August 17, 2017 5:47 PM
  • First you keep assuming Microsoft has a bug, any driver writer needs to assume they have a bug and it is their challenge to find it.  I've been working in Windows drivers for over 20 years, and in that time I found one bug in the Windows kernel support, and it had already been reported!

    You are complaining about 3 days, for a file system most of us estimate 9 to 18 months.

    Go back and look at how you can change your design to use the standard file system recognizer / file system model.   Right now you are just signing up for a lot of support headaches.

     


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Thursday, August 17, 2017 5:55 PM
  • Nothing to do I did not find anything,
    I followed the documentation:
    https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/mounting-a-volume
    Unsuccess problem not solved.

    I do not know if I hallucinate:
    So I try to mount the VPB and associate it in DeviceObject-> VPB and
    It seems to work good with out BSOD (SANS BSOD).
    Problem solved partially.

    Now i force mount and the disk filesystem work good.


    Otherwise, if a Windows update makes this method incompatible,
    Can we send me the executable link (KBXXXX) of this windows update?

    I want to be in compliance if we given solutions

    However later I will test it on another machine.

    Thanks anyways.

    Friday, August 18, 2017 5:53 PM
  • I am not saying that an update has broken your approach, I am stating that since your approach dives into the undocumented games it is likely to have some update break it.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Friday, August 18, 2017 6:12 PM
  • My driver use ntddk.h than ntifs.h with type (from ntifs.h) redefined (4 years).

    A next week i will test with replace ntddk.h by ntifs.h without redefine the type (comment).

    My driver started since four years ago and I used 'without thinking' "ntddk.h" by redefining the struct of ntifs.h .

    I do not know if this is due to that.

    I will test last week.

    Saturday, August 19, 2017 1:42 PM
  • Well for longer than your driver, ntifs.h included ntddk.h, so you should have always started with that.  Can't say that hacking types out of ntifs.h for your driver is causing problems but I have seen enough other drivers that had errors by doing that or using the piece of crap GNU ntifs.h


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Saturday, August 19, 2017 1:50 PM
  • I replaced ntddk.h by ntifs.h , same problem.

    I will force mount VPB

    Saturday, August 26, 2017 3:29 PM