Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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/
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 | 13-17 May 2024 | Live, Online |
Developing Minifilters | 1-5 Apr 2024 | Live, Online |
Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
Writing WDF Drivers | 26 Feb - 1 Mar 2024 | Live, Online |
Comments
Message to who? If you want to write kernel debug log messages, OutputDebugString works, although it is primitive. You'd need to add a printf wrapper.
https://community.osr.com/discussion/292213/outputdebugstring-in-umdf2-drivers
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
If you don't mind,i have another question please, now I want to communicate with the device to retrieve the version of the firmware installed at its level, is there a possibility of using fileapi if not, will I have to use hid report functions. I don't know which way I'm going to take.
If it is a HID device, then ReadFile and WriteFile just translate to HID API requests anyway. You're basically just a plain, ordinary user-mode application. Do whatever you would have done from your test applications.
Many HID devices don't need a driver at all. What kind of device is it?
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
Sort of. The tool is based on the hidapi library. They have a wrapper class called CHidIO2 that has functions called ReadFile and WriteFile, but those are just thin wrappers around hidapi. The ISPLdCMD::GetVersion function calls ISPLdCMD::WriteFIle which calls CHidIO2::WriteFile which calls hid_write in the hidapi library, which ends up calling WriteFile, which sends an output report. If you're writing your own tool, you can just call WriteFile directly -- the hidapi stuff is just there to provide platform independence.
You don't need a driver. HID devices can be used without any special drivers at all.
You get the path the same way that hidapi does -- you use the SetupDi APIs to enumerate all of the HID devices until you find the one you want.
But, hang on a moment. What kind of UMDF driver are you writing? If you are writing a driver for that device, with an INF file that claims the VID/PID, then you don't need to find the path. PnP will hand you the device object you need in order to send commands. If you not writing a driver specifically for that device, then you're not writing a driver -- you're writing a utility DLL, and you should not be using UMDF at all.
Every driver in Windows maps requests from above into requests from below. What applications are going to use your "driver"? What requests are they going to make? What services are you going to provide? I strongly suspect you are on a very wrong path here.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.