Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


When Application closes, driver again create a new device instance

remyavu10remyavu10 Member Posts: 36

Hi,

I have umdf2 virtual serial driver. Application connect to it and when application is closed the driver function EvtDeviceAdd is being called again creating new queue and everything. This is happening ONLY when i have added below code and accepted Open request in EvtFileCreate.

WDF_FILEOBJECT_CONFIG_INIT(&stFileObjectConfig,
EvtFileCreate,
EvtFileClose,
EvtFileCleanup);

WdfDeviceInitSetFileObjectConfig(DeviceInit,
                                &FileObjectConfig,
                                &DeviceAttributes);

May i know what is the reason behind this?

My aim with above code snippet was to get notified when Application open serial device.
I want to get notified up on Device open by application, but not EvtDeviceAdd is being called(second call to EvtDeviceAdd reset by underlying communication channel)

Any help would be really appreciated.

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,499
    Either the underlying bus is recreating the device due to a bus error (unlikely) or your driver is crashing in the new callbacks you are setting and the driver is being restarted (most likely root cause).
    d
  • remyavu10remyavu10 Member Posts: 36

    Thanks for reply.

    This is a virtual serial driver and hence, i think, no bus error.
    The application could successfully opened the device using CreateFile API, and does not doing anything with device.
    And after some time (say 10 secs). it just exist.

    But without below code snippet in Driver, this is not happening:
    WDF_FILEOBJECT_CONFIG_INIT(&stFileObjectConfig,
    EvtFileCreate,
    EvtFileClose,
    EvtFileCleanup);

    WdfDeviceInitSetFileObjectConfig(DeviceInit,
    &FileObjectConfig,
    &DeviceAttributes);

    Body of EvtFileCreate:
    void EvtFileCreate(stRequest)
    {
    WdfRequestComplete(stRequest, STATUS_SUCCESS);
    }

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,499
    And what does the code for EvtFileClose and EvtFileCleanup look like? If the add device call is happening when the handle is closed, the driver crash is most likely in one of these two callbacks. Have you attached a debugger to the driver process before the handle is created and step through the relevant callbacks as they run?
    d
  • remyavu10remyavu10 Member Posts: 36

    Thanks!
    Both debugging purpose, i made EvtFileClose, EvtFileCleanup to be empty.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,499
    Attach a debugger and see if the driver is crashing. A crash will cause an auto restart and you will see AddDevice run again.
    d
  • remyavu10remyavu10 Member Posts: 36

    Ok I attached debugger and found a crash. Your conclusion was right.

    The callback EvtDeviceCleanup is invoked by framework when Application closed the driver handle. Logic written there was really meant for clean-up specific to device removal. But when it was called when application closed device handle, the same function executed but with NULL pointer for Context object.

    But i would ask how to distinguish between whether clean-up is specific to application closing device handle or device removal?

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,499
    EvtDeviceCleanup Is called when the device removed, it is not called when the handle is closed. You have another bug in your driver. Perhaps it is not an explicit crash, but something the driver is doing incorrectly is causing the underlying framework to tear down the device stack.
    d
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,442

    The callback EvtDeviceCleanup is invoked by framework when Application closed the driver handle.
    Logic written there was really meant for clean-up specific to device removal.

    You have mixed up several concepts in that simple paragraph.

    There is no standard "EvtDeviceCleanup" callback. Is that your WDFDEVICE's context cleanup routine? That gets called when the device itself is removed, either through an unplug or through a restart. This is not directly related to application activity.

    Applications do not open "driver handles". They open device handles. EvtFileCleanup gets called when the application closes a device handle. That does not cause the device to be removed.

    To catch the device being removed, you can use EvtDeviceD0Exit or EvtDeviceCleanup. They happen at different stages in the shutdown.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,845

    There are two similarly named callbacks that are easy to confuse:

    There's the EvtFileCleanup, that you specify as part of your WDF_FILEOBJECT_CONFIG. This gets called (for all practical purposes) when the user calls CloseHandle.

    There's also the EvtCleanup callback that can be specified for any WDF Object, that's specified in your WDF_OBJECT_ATTRIBUTES structure prior to object instantiation. This callback is called when the last handle is closed to the object.

    Maybe that'll help??

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • remyavu10remyavu10 Member Posts: 36
    Thanks Guys! I should have used the word closing device handle, instead closing driver handle. I had some confusion with respect a to file cleanup and device cleanup. Now it is cleared. Thanks.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA