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

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

Device not started 0x16 (CM_PROB_DISABLE)// Load fail (code39): Object Name not found.

AtefAtef Member Posts: 6

Hi guys,

I am new here and I am hoping to have some help for a better undrestand of driver development after this discussion.

I've researched this on NTDEV and elsewhere and there are multiple causes of fail load. I've gone some way down the paths, and so far gotten nowhere.

My driver is a streaming miniport for the standard Windows port class audio driver (portcls.sys). In a conjunction with the port driver, it forms an audio device filter for the Kernel Streaming (KS)

subsystem. My driver is implemented as a generic PnP WDM driver. The good news is working as expected.

Now coming to the bad news: I have a small license project ( one cpp and one header) which I use with many other project and it's works very well. The license project is just check the input

parameters with the one on the License USB stick and grant access in case have the same private key. The project is added, compiled and when install the driver I have this yellow flag

next to my virtual device (in Device manager tab) with a status : " Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39)

Object Name not found."

Here are some details, and I attach setupapi.dev.log at the end.

  1. Dev host is Windows 10 Enterprise x64 .

  2. Driver built with "build.exe" tool from the DDK/WDK.

  3. Driver targets all currently supported platforms (Windows 7-10 x32/x64).

  4. Build checking stamping (test) signing deploying are all error free.

  5. Sys components with cat and inf are included in the deployed package which looks good to me.

  6. Test signing is applied on both release and debug builds.

  7. Here's my (redacted) setupapi.dev.log...

Hi guys,

I am new here and I am hoping to have some help for a better undrestand of driver development after this discussion.

I've researched this on NTDEV and elsewhere and there are multiple causes of fail load. I've gone some way down the paths, and so far gotten nowhere.

My driver is a streaming miniport for the standard Windows port class audio driver (portcls.sys). In a conjunction with the port driver, it forms an audio device filter for the Kernel Streaming (KS)

subsystem. My driver is implemented as a generic PnP WDM driver. The good news is working as expected.

Now coming to the bad news: I have a small license project ( one cpp and one header) which I use with many other project and it's works very well. The license project is just check the input

parameters with the one on the License USB stick and grant access in case have the same private key. The project is added, compiled and when install the driver I have this yellow flag

next to my virtual device (in Device manager tab) with a status : " Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39)

Object Name not found."

Here are some details, and I attach setupapi.dev.log at the end.

  1. Dev host is Windows 10 Enterprise x64 .

  2. Driver built with "build.exe" tool from the DDK/WDK.

  3. Driver targets all currently supported platforms (Windows 7-10 x32/x64).

  4. Build checking stamping (test) signing deploying are all error free.

  5. Sys components with cat and inf are included in the deployed package which looks good to me.

  6. Test signing is applied on both release and debug builds.

  7. Here's my setupapi.dev.log...

Comments

  • AtefAtef Member Posts: 6

    I dont know why this was written. Please find the log file attached here

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,159

    Your post is a bit confusing. Are you saying that your install worked fine until you added the licensing code to the driver? That should be a strong indication. Does the driver now require an external DLL that you aren't copying? Was the licensing code designed to run in the kernel? If you send the package to me, I can scan it for unsatisfied dependencies.

    Your tools are very old; "build.exe" hasn't been used since the Windows 7 WDK, which came out 10 years ago.

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

  • AtefAtef Member Posts: 6

    Dear Tim,

    Thank you for your answer.

    *** Are you saying that your install worked fine until you added the licensing code to the driver?****
    Yeah, my install (Driver) worked fine until I added the license code.

    That should be a strong indication.
    Yeah, But I have tested my License code (independently) and it works fine. Also I used this License code in different other projects (But not a Driver project.)

    *** Does the driver now require an external DLL that you aren't copying?***
    It does (and also .lib files used during compilation) and it's copied.

    *** Was the licensing code designed to run in the kernel?***
    Mybe this is what I am missing. What a License code need to run in kernel? and How can I know if my licensing code not designed to run in kernel?

    ** * Your tools are very old; "build.exe" hasn't been used since the Windows 7 WDK, which came out 10 years ago***
    I totally agree. Sooner or later we will move to newer tool.

    !!! dvi: Device not started: Device has problem: 0x16 (CM_PROB_DISABLED), problem status: 0x00000000.
    The error is also not saying much. There is a way to know why the device is disabled?

    I hope this is now is more clear. Any other suggestion are welcome.
    Thanks again.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,159

    Mybe this is what I am missing. What a License code need to run in kernel? and How can I know if my licensing code not designed to run in kernel?

    Whoever provided the code should have told you. Remember that a kernel driver does not have access to ANY user-mode APIs. If they're doing any file I/O, or any Winsock socket calls, or any GDI drawing, or any window messages, or even calls like Sleep, then it isn't kernel code and would need to be rewritten.

    CM_PROB_DISABLED usually means that you, the user, disabled the device using Device Manager.

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

  • AtefAtef Member Posts: 6

    Dear Tim,

    Remember that a kernel driver does not have access to ANY user-mode APIs. If they're doing any file I/O, or any Winsock socket calls, or any GDI drawing, or any window messages, or even calls like Sleep, then it isn't kernel code and would need to be rewritten.

    I just checked my license code and it's using a file I/O.
    Thank you for help, I am going to rewrite the License code.

    Best Regards,

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
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE