DeviceIoControl fails with code 87

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

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)

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.

@“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.

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

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

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

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. :wink:

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!?

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.

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

1 Like