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/


DeviceIoControl fails with code 87

m_nillesm_nilles Member Posts: 5
edited March 21 in NTDEV

Hello,

I have a weird issue which only occurs on some pc's. On all systems in my company and of the very most customers the issue does not exist.

There is just a little number of customer systems (Win10-64) where the problem exists. In some cases it is so that the reporter has the problem whereas his colleage with the same hardware equipment does not have the problem.

I issue an IOCTL via DeviceIoControl to a KMDF driver and it returns with the code 87, which is 'invalid parameter'.
I added a debug message in the driver to show each received IOCTL. And it shows that the driver does never see the IOCTL.

Does anyone have experienced something like this?

Any hints are very welcome.
Please ask for more details if required.

Thank you,
Michael

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,025

    Well @m_nilles ... Welcome to the forum, but... ah... you posted your first post in the Announcements and Administration category... which is not a great start.

    OK... to your question: Do you own this driver? Or is it some random third-party driver?

    Peter

    (P.S. I moved your question, and this answer, to the appropriate category which is NTDEV)

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,373

    Could they be using some very aggressive antivirus? I've seen a filter driver do this. I was doing a USB MIDI driver, and installing a USB monitor product caused some ioctls to stop working.

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

  • m_nillesm_nilles Member Posts: 5
    edited March 23

    @Peter_Viscarola_(OSR)
    Sorry for posting into the false category. This indeed is not a great start. Do you think I should re-porst the question in the correct category. So, that it gets more attention?
    On your question on the driver: Yes, we own this driver.

    @Tim_Roberts
    Thanks for the hint in the antivirus. Actually we did discuss if some kind of security software or setting could cause the issue.
    But we never really investigated this further.
    Because of the customers who explained that the issue only persists on their personal system and not on the colleagues system which should have the same configuration.
    I will check if there is any obvious symmetry in the customers software installations.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,025

    Do you think I should re-porst the question in the correct category

    I moved it to the right place for you.

    The trick to debugging this is determining WHAT is generating the error. In doing this, I generally work BACKWARDS from my driver, through the I/O Manager. If THAT doesn't work... all you can do is work FORWARDS and single-step/set breakpoints.

    Never that much fun,

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • m_nillesm_nilles Member Posts: 5

    Thank you for moving my issue, Peter.

    The problem is that none of the customers who have the issue is willing to hand out his system to us and that we did not manage to reproduce it on one of our systems yet.
    So debugging by breakpoints is not an option.

    I will have a teamviewer session with one of the customers.
    The plan is - as you suggest - to first install a driver which logs incoming ioctls. We did this already and it seemed that the driver does not see the ioctl, i.e. the callback is not called from the subsystem.
    Next step should be the investigation of the io manager. What tools do you recommend for that? If I remember correctly we already tried IRP Tracker, without any clear hint.
    I will also have a closer look on antivir and the like software which is installed on the system.

    Thanks for your attention,
    Michael

  • Nathan_KiddNathan_Kidd Member - All Emails Posts: 25
    via Email
    On 2022-03-30 8:45 a.m., m_nilles wrote:
    > I will also have a closer look on antivir and the like software which is installed on the system.

    Just to pile on to the antivirus train: I have personally debugged a
    customer issue in our filesystem driver that made absolutely no sense.
    Eventually we asked them to disable antivirus and the issue was "fixed".

    I found https://docs.microsoft.com/en-us/sysinternals/downloads/livekd
    very useful to get a non-invasive snapshot to more authoritatively see
    what AV kernel modules are running (though maybe you're getting hit in
    usermode).

    -Nathan
  • m_nillesm_nilles Member Posts: 5
    edited March 31

    Thanks for your input Nathan.

    I will have a look at livekd. But I'm not sure if I'm skilled enough to use it successfully. ;)

    Is just tried to start it. If I execute the livekd.exe a command windows shows up which immediately disappears again.
    I also executed livekd64.exe. With the same behaviour and with the special effect that livekd64.exe was removed from the folder afterwards!?

  • m_nillesm_nilles Member Posts: 5

    Problem solved.
    It turned out that a third party filter driver (dino-lite) "stole" the IRPs.
    Solution was to declare a custom device class for our devices to get the dino-lite driver out of the control flow.

  • Dan_RootDan_Root Administrator Posts: 10

    @m_nilles - thanks for reporting back and closing the loop on this.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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!
Writing WDF Drivers 12 September 2022 Live, Online
Internals & Software Drivers 23 October 2022 Live, Online
Kernel Debugging 14 November 2022 Live, Online
Developing Minifilters 5 December 2022 Live, Online