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


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:

Display trace event message in umdf

abdouabdou Member Posts: 10
I've created an UMDF driver , now i am trying to get message sending by driver via trace event function , I need to do it from my local Machine, is there any tool or method to do it. I've tried with trace log, windbg dbgview..., but without result, I've also thought to use socket, but I've not succeed. So please if anyone knows how to do it. It will be helpful for me.


  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,719

    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.

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

  • abdouabdou Member Posts: 10
    Thank you, i will try that.
  • abdouabdou Member Posts: 10
    Thnks a lot ,it's working,i can now view trace message using appverif and windbg.
    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.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,719

    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.

  • abdouabdou Member Posts: 10
    It's nuvoton device , I've tools for handle it via test application . This tool is based on readfile and write file, from my driver i tried to create handle to interface with device via createFile function, but i could not ,this function require device path to be used,this path i don't know how to get it in UMDF driver , so I've hard coded it ,when testing I had no result. For what i need to use hid command from driver at least to get version of firmware, please if you've code how to do this kind of task, it will be helpful for me.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,719

    This tool is based on readfile and write file,

    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.

    this function require device path to be used, this path I don't know how to get ...

    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.

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