none
UDMF Driver Deployment FAIL when linking w/ Static Lib RRS feed

  • Question

  • I was bashing my head against the wall for about an hour w/ this.

    UMDF Deployment will fail ( providing no clear indication of the real cause ) for drivers linked w/ a static lib that was compiled using any platform toolset other than "WindowsApplicationForDrivers*.*" eg. the "Visual Studio 2013 (v120)" platform toolset.

    1. Why can't I simply use my pre-built static libs w/ my [U]MDF driver project ( emphasizing 'U' ), why do I need to re-compile it using "WindowsApplicationForDrivers*.*", what if I don't have the source code for the lib ?
    2. Why a propper warning / notification is not provided while compiling/deploying?





    • Edited by Nadav Rub Tuesday, August 26, 2014 2:04 PM
    Tuesday, August 26, 2014 7:41 AM

Answers

  • 1. Maybe normal (not WindowsApplicationForDrivers) code generation options are not compatible with UMDF environment. Use Dependency viewer to see if a "bad" image refers to some extra DLLs that a "good" image does not, such as VC++ debug runtime.

    2. The Murphy Law says that if something can be ever done in a wrong way, someone will eventually do it.  So congratulations, you've just found another proof to this law.

    -- pa

    • Marked as answer by Nadav Rub Tuesday, August 26, 2014 6:19 PM
    Tuesday, August 26, 2014 5:07 PM

All replies

  • You can check c:\windows\inf\setupapi.dev.log on the target machine to find out why the deployment wasn't successful.  I usually delete the log file first, then run the install, then read the file - this makes it easier to know which entries are just related to the install I did.

    I assume that if you don't link the static library in, that the driver deploys just fine? 

    With the static library linked in, are you sure that the driver is compiling?

    Tuesday, August 26, 2014 4:44 PM
  • 1. Maybe normal (not WindowsApplicationForDrivers) code generation options are not compatible with UMDF environment. Use Dependency viewer to see if a "bad" image refers to some extra DLLs that a "good" image does not, such as VC++ debug runtime.

    2. The Murphy Law says that if something can be ever done in a wrong way, someone will eventually do it.  So congratulations, you've just found another proof to this law.

    -- pa

    • Marked as answer by Nadav Rub Tuesday, August 26, 2014 6:19 PM
    Tuesday, August 26, 2014 5:07 PM
  • What are those "not good" DLLs, how can they be identified? why should there be any problem loading vcDebug runtime ( assuming it's avail on the machine ) in a User-Mode Driver ?

    Nadav Rubinstein, See my Blog @ http://www.sophin.com

    Tuesday, August 26, 2014 5:59 PM
  • it is a normal user mode process, the VS CRT can and does load just fine. You have to see what new imports your static libs bring. it sounds like you can build and link just fine, it is the loading of the DLL that fails. If the libs introduce a new import from a new dll you might have a dependency problem. You can easily test this by creating a small test app and calling LoadLibrary on your DLL to see if it can load successfully. if it can't, you need to debug further. Turn on loader snaps and app verifier on your test app and then retry.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, August 26, 2014 6:05 PM
  • unstablepuddle>> I assume that if you don't link the static library in, that the driver deploys just fine? 

    Nadav>> CORRECT

    unstablepuddle>> With the static library linked in, are you sure that the driver is compiling?

    Nadav>> Well, It was compiling the last time I have tested


    Nadav Rubinstein, See my Blog @ http://www.sophin.com

    Tuesday, August 26, 2014 6:10 PM
  • Just verified, the vcDebug Runtime was missing on the target machine, Indeed, as you have suggested a DLL import problem.

    Nadav Rubinstein, See my Blog @ http://www.sophin.com

    Tuesday, August 26, 2014 6:19 PM