none
Reflactor in UMDF driver RRS feed

  • Question

  • Hello all

    my questions are

    1-what is the role of reflactor in UMDF driver?

    2-how it used in UMDF?

    3-is this possible without reflactor UMDF will work?

    Thanks

    bipul pandey

    Friday, February 15, 2013 6:18 AM

Answers

  • When a UMDF driver creates a device object, a message is sent to the reflector (in kernel mode) to create the device object for you. Thereafter, IRPs that are sent to that device object are then bounced (or reflected) from kernel mode back up to the UMDF driver in user mode. This is a gross simplification of what happens, but it should be obvious that a UMDF driver cannot work without the reflector. Further, you do not need to interact with the reflector; the framework does all that work for you.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting.

    Friday, February 15, 2013 6:32 AM
    Moderator
  • 1) the reflector, more succinctly, the redirector is its name, is the proxy for the UMDF device stack in kernel mode.  as that proxy, it can behave as a pnp filter or as the FDO of the pnp stack.

    2) a UMDF driver can do way more than a UM process can. a umdf can enable a device interface, have a handle opened against it, have io sent to it, participate in pnp and power, etc. A normal UM process cannot do any of these things. 

    the win of a umdf driver is that if there is a bug in your UMDF driver, the host process goes away, the umdf driver is restarted and the OS continues to run. If that bug were in a KM driver, you bluescreen, lose your work and reboot.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, February 15, 2013 7:30 AM

All replies

  • When a UMDF driver creates a device object, a message is sent to the reflector (in kernel mode) to create the device object for you. Thereafter, IRPs that are sent to that device object are then bounced (or reflected) from kernel mode back up to the UMDF driver in user mode. This is a gross simplification of what happens, but it should be obvious that a UMDF driver cannot work without the reflector. Further, you do not need to interact with the reflector; the framework does all that work for you.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting.

    Friday, February 15, 2013 6:32 AM
    Moderator
  • Thanks

    Brian

     I understand your point here ... again  more question  based on your answer

    1- then some time reflector called as filter , so what does it mean,

    2- as the same context  I want to understand  UMDF vs. User Process,  what is the benefit to having UMDF driver, as user process also can do the same thing as UMDF does(UMDF driver having another headache of reflector and all), I know that UMDF runs in the host process as deferent memory context, what is the win having UMDF driver

    Thanks

    bipul  

    Friday, February 15, 2013 7:07 AM
  • OK, think about the reflector as a sort of a proxy for your UMDF driver. You may need to skim through the WDM driver documentation to see how a DevStack is built in order to understand the following. In kernel mode, there will be a WDM DevStack (stack of DEVICE_OBJECTs) that IRPs are sent to. Your UMDF driver will be participating at some level within the DevStack, usually as the FDO, but it could be a filter (Function Filter Device Object). In this case, the reflector creates a DEVICE_OBJECT at the appropriate level within the DevStack, and then as the IRP works its way down the DevStack (from top to bottom), when it reaches the reflector's DEVICE_OBJECT, the reflector will send the IRP up to the UMDF framework and eventually call your UMDF driver.

    A UMDF (User Mode Driver Framework) driver runs in user mode (hence the name), within a host process. The principle benefit of UMDF vs KMDF drivers is that if the UMDF driver has a bug, instead of crashing the system it will merely crash the host process (which will then be restarted). You can totally, and completely forget about the reflector, and write your UMDF driver as if you were in kernel mode, and it will just work. Unfortunately, UMDF wasn't designed well, and UMDF doesn't use the same APIs and calling conventions as KMDF, so there are some mechanical differences between UMDF and KMDF (UMDF uses COM; ACK! Gag! Barf!) while KMDF uses a direct-call interface.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting.

    Friday, February 15, 2013 7:27 AM
    Moderator
  • 1) the reflector, more succinctly, the redirector is its name, is the proxy for the UMDF device stack in kernel mode.  as that proxy, it can behave as a pnp filter or as the FDO of the pnp stack.

    2) a UMDF driver can do way more than a UM process can. a umdf can enable a device interface, have a handle opened against it, have io sent to it, participate in pnp and power, etc. A normal UM process cannot do any of these things. 

    the win of a umdf driver is that if there is a bug in your UMDF driver, the host process goes away, the umdf driver is restarted and the OS continues to run. If that bug were in a KM driver, you bluescreen, lose your work and reboot.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, February 15, 2013 7:30 AM