Is it allowed to use shared libs[Dll]/dynamic linking with UMDF Drivers

Hello,

I have a UMDF 2.15 driver and needed to modify it to use some functionality
that is provided by a 3rd party. This functionality is provided both as a
static lib and as a shared lib[Dll].

I modified the driver to call the appropriate functions and to link with
the said Dll. I modified the inf file to copy the Dll to
c:\windows\system32\drivers\UMDF and verified the file is getting copied
[by looking at c:\windows\INF\setupapi.dev.log and also by looking at the
destination directory]. On installing the driver, I am getting error
CM_PROB_FAILED_ADD.

Modifying to use a static lib causes the driver to works fine.

I am calling the Dll functionality from a path that services an IoCTL which
is not called at driver install/load time. Using Dependency walker, I
verified that the 3rd party Dll only depends on kernel32.lib. I also built
an extremely simple Dll just for testing and found that I hit the same
error with it if I try to call any function from it in my driver. So it
looks like whatever I am hitting is independent of the specific
functionality in the Dll that I am trying to access.

I tried to search online to see if there is some type of recommendation
about only using static linking while building a UMDF driver. One
interesting thing I found is at
https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/using-the-microsoft-c-runtime-with-user-mode-drivers-and-apps
which makes a specific recommendation for UMDF drivers and C Runtime
libraries:

For UMDF drivers:

  • Statically link your driver against the CRT to include the runtime in
    the binary. In this case, you do not need to redistribute the CRT.

The above seems to go against general recommendation against statically
linking with CRT libs and made me wonder if there is a reason for this.

Question - Is using a Dll with UMDF driver supposed to work [assuming we
follow the recommended good practices for calling a Dll from another Dll]?
Or is this something to be strictly avoided?

If you would like me to post my inf or the driver code etc. or share any
other details, I will be glad to share those.

Thanks in advance for your help.

-H

On Feb 17, 2018, at 8:02 PM, xxxxx@gmail.com wrote:
>
> I tried to search online to see if there is some type of recommendation about only using static linking while building a UMDF driver.

This should not be a problem. It’s just an ordinary user-mode DLL. You did a “link /dump /imports” to verify that the 3rd-party DLL doesn’t load anything unusual? Have you tried creating a user-mode program to call into the 3rd-party DLL to make sure that runs? You don’t have to execute the DLL code; just verifying that the app will load and start would be comforting.

> One interesting thing I found is at https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/using-the-microsoft-c-runtime-with-user-mode-drivers-and-apps https: which makes a specific recommendation for UMDF drivers and C Runtime libraries:
> For UMDF drivers:
> Statically link your driver against the CRT to include the runtime in the binary. In this case, you do not need to redistribute the CRT.
> The above seems to go against general recommendation against statically linking with CRT libs and made me wonder if there is a reason for this.

I don’t think there is a “general recommendation” against a static CRT. It’s certainly far more convenient to deploy that way. The reasoning is just what the message says: if you link to the dynamic CRT, then you must distribute the CRT DLLs with your driver… That’s a pain.

> Question - Is using a Dll with UMDF driver supposed to work [assuming we follow the recommended good practices for calling a Dll from another Dll]? Or is this something to be strictly avoided?

It shouldn’t be a problem.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</https:>

> I don’t think there is a “general recommendation” against a static CRT. It’s certainly far more convenient to deploy that way. The reasoning is just what the message says: if you link to the dynamic CRT, then you must distribute the CRT DLLs with your driver… That’s a pain.

It is more than deployment pain, it is a shared directory and there can be only one copy of the DLL. Another driver could copy a newer version and break existing drivers. Another driver could copy an older version and break existing drivers. Statically linking removes the deployment and break others problems.

Technically speaking your third party dll could suffer from the same problem if two driver packages copy over a dll with the same name, however that is extremely unlikely. A simple test is to load the umdf driver dll which has dynamically linked against the third party I dll in a test application and see if it loads properly.

d

Bent from my phone


From: xxxxx@lists.osr.com on behalf of xxxxx@probo.com
Sent: Saturday, February 17, 2018 8:36:49 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Is it allowed to use shared libs[Dll]/dynamic linking with UMDF Drivers

On Feb 17, 2018, at 8:02 PM, xxxxx@gmail.commailto:xxxxx > wrote:

I tried to search online to see if there is some type of recommendation about only using static linking while building a UMDF driver.

This should not be a problem. It’s just an ordinary user-mode DLL. You did a “link /dump /imports” to verify that the 3rd-party DLL doesn’t load anything unusual? Have you tried creating a user-mode program to call into the 3rd-party DLL to make sure that runs? You don’t have to execute the DLL code; just verifying that the app will load and start would be comforting.

One interesting thing I found is at https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/using-the-microsoft-c-runtime-with-user-mode-drivers-and-appshttps: which makes a specific recommendation for UMDF drivers and C Runtime libraries:

For UMDF drivers:

* Statically link your driver against the CRT to include the runtime in the binary. In this case, you do not need to redistribute the CRT.

The above seems to go against general recommendation against statically linking with CRT libs and made me wonder if there is a reason for this.

I don’t think there is a “general recommendation” against a static CRT. It’s certainly far more convenient to deploy that way. The reasoning is just what the message says: if you link to the dynamic CRT, then you must distribute the CRT DLLs with your driver… That’s a pain.

Question - Is using a Dll with UMDF driver supposed to work [assuming we follow the recommended good practices for calling a Dll from another Dll]? Or is this something to be strictly avoided?

It shouldn’t be a problem.
?
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></https:></mailto:xxxxx>

“Statically linking removes the deployment and break others problems” seems like an odd answer from Microsoft. Some years ago on this very list we had a debate as some of us wanted a static linked version of KMDF, for the exact reason that was just cited for a UMDF driver. The response from Microsoft was basically “we will never break KMDF drivers with a newer KMDF shared library version, so you don’t get to statically link to KMDF”.

Do we have a double standard where Microsoft kernel shared libraries will never break existing drivers, yet shared user mode shared libraries potentially have breaking updates, or has Microsoft viewpoint on this issue changed in the intervening years?

Jan

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@microsoft.com
Sent: Saturday, February 17, 2018 9:06 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Is it allowed to use shared libs[Dll]/dynamic linking with UMDF Drivers

> I don’t think there is a “general recommendation” against a static CRT. It’s certainly far more convenient to deploy that way. The reasoning is just what the message says: if you link to the dynamic CRT, then you must distribute the CRT DLLs with your driver… That’s a pain.

It is more than deployment pain, it is a shared directory and there can be only one copy of the DLL. Another driver could copy a newer version and break existing drivers. Another driver could copy an older version and break existing drivers. Statically linking removes the deployment and break others problems.

Technically speaking your third party dll could suffer from the same problem if two driver packages copy over a dll with the same name, however that is extremely unlikely. A simple test is to load the umdf driver dll which has dynamically linked against the third party I dll in a test application and see if it loads properly.

d

Bent from my phone
________________________________
From: xxxxx@lists.osr.commailto:xxxxx > on behalf of xxxxx@probo.commailto:xxxxx >
Sent: Saturday, February 17, 2018 8:36:49 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Is it allowed to use shared libs[Dll]/dynamic linking with UMDF Drivers

On Feb 17, 2018, at 8:02 PM, xxxxx@gmail.commailto:xxxxx > wrote:

I tried to search online to see if there is some type of recommendation about only using static linking while building a UMDF driver.

This should not be a problem. It’s just an ordinary user-mode DLL. You did a “link /dump /imports” to verify that the 3rd-party DLL doesn’t load anything unusual? Have you tried creating a user-mode program to call into the 3rd-party DLL to make sure that runs? You don’t have to execute the DLL code; just verifying that the app will load and start would be comforting.

One interesting thing I found is at https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/using-the-microsoft-c-runtime-with-user-mode-drivers-and-appshttps: which makes a specific recommendation for UMDF drivers and C Runtime libraries:

For UMDF drivers:
* Statically link your driver against the CRT to include the runtime in the binary. In this case, you do not need to redistribute the CRT.
The above seems to go against general recommendation against statically linking with CRT libs and made me wonder if there is a reason for this.

I don’t think there is a “general recommendation” against a static CRT. It’s certainly far more convenient to deploy that way. The reasoning is just what the message says: if you link to the dynamic CRT, then you must distribute the CRT DLLs with your driver… That’s a pain.

Question - Is using a Dll with UMDF driver supposed to work [assuming we follow the recommended good practices for calling a Dll from another Dll]? Or is this something to be strictly avoided?

It shouldn’t be a problem.
-
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></http:></mailto:xxxxx></https:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

The ancient sdk “depends” tool usually identifies exactly why your dll
won’t load.

but why bother? It works statically. One less thing to install and worry
about.

Mark Roddy

On Sun, Feb 18, 2018 at 6:15 AM, xxxxx@pmatrix.com > wrote:

> “Statically linking removes the deployment and break others problems”
> seems like an odd answer from Microsoft. Some years ago on this very list
> we had a debate as some of us wanted a static linked version of KMDF, for
> the exact reason that was just cited for a UMDF driver. The response from
> Microsoft was basically “we will never break KMDF drivers with a newer
> KMDF shared library version, so you don’t get to statically link to KMDF”.
>
>
>
> Do we have a double standard where Microsoft kernel shared libraries will
> never break existing drivers, yet shared user mode shared libraries
> potentially have breaking updates, or has Microsoft viewpoint on this issue
> changed in the intervening years?
>
>
>
> Jan
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:bounce-647150-145174@
> lists.osr.com] *On Behalf Of *xxxxx@microsoft.com
> Sent: Saturday, February 17, 2018 9:06 PM
> To: Windows System Software Devs Interest List
>
> Subject: Re: [ntdev] Is it allowed to use shared libs[Dll]/dynamic
> linking with UMDF Drivers
>
>
>
> > I don’t think there is a “general recommendation” against a static CRT.
> It’s certainly far more convenient to deploy that way. The reasoning is
> just what the message says: if you link to the dynamic CRT, then you must
> distribute the CRT DLLs with your driver… That’s a pain.
>
>
>
> It is more than deployment pain, it is a shared directory and there can be
> only one copy of the DLL. Another driver could copy a newer version and
> break existing drivers. Another driver could copy an older version and
> break existing drivers. Statically linking removes the deployment and break
> others problems.
>
>
>
> Technically speaking your third party dll could suffer from the same
> problem if two driver packages copy over a dll with the same name, however
> that is extremely unlikely. A simple test is to load the umdf driver dll
> which has dynamically linked against the third party I dll in a test
> application and see if it loads properly.
>
>
>
> d
>
>
>
> Bent from my phone
> ------------------------------
>
> From: xxxxx@lists.osr.com > osr.com> on behalf of xxxxx@probo.com
> Sent: Saturday, February 17, 2018 8:36:49 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Is it allowed to use shared libs[Dll]/dynamic
> linking with UMDF Drivers
>
>
>
> On Feb 17, 2018, at 8:02 PM, xxxxx@gmail.com
> wrote:
>
>
>
> I tried to search online to see if there is some type of recommendation
> about only using static linking while building a UMDF driver.
>
>
>
> This should not be a problem. It’s just an ordinary user-mode DLL. You
> did a “link /dump /imports” to verify that the 3rd-party DLL doesn’t load
> anything unusual? Have you tried creating a user-mode program to call into
> the 3rd-party DLL to make sure that runs? You don’t have to execute the
> DLL code; just verifying that the app will load and start would be
> comforting.
>
>
>
>
>
> One interesting thing I found is at https://docs.microsoft.com/
> en-us/windows-hardware/drivers/develop/using-the-
> microsoft-c-runtime-with-user-mode-drivers-and-apps
> https:
> which makes a specific recommendation for UMDF drivers and C Runtime
> libraries:
>
> For UMDF drivers:
>
> · Statically link your driver against the CRT to include the
> runtime in the binary. In this case, you do not need to redistribute the
> CRT.
>
> The above seems to go against general recommendation against statically
> linking with CRT libs and made me wonder if there is a reason for this.
>
>
>
> I don’t think there is a “general recommendation” against a static CRT.
> It’s certainly far more convenient to deploy that way. The reasoning is
> just what the message says: if you link to the dynamic CRT, then you must
> distribute the CRT DLLs with your driver… That’s a pain.
>
>
>
>
>
> Question - Is using a Dll with UMDF driver supposed to work [assuming we
> follow the recommended good practices for calling a Dll from another Dll]?
> Or is this something to be strictly avoided?
>
>
>
> It shouldn’t be a problem.
>
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></http:></http:></http:></http:></https:>

On Feb 18, 2018, at 3:15 AM, xxxxx@pmatrix.com wrote:
>
> Do we have a double standard where Microsoft kernel shared libraries will never break existing drivers, yet shared user mode shared libraries potentially have breaking updates, or has Microsoft viewpoint on this issue changed in the intervening years?

Well, remember that the C run-time library is not controlled by the UDMF folks. They can’t force the compiler team to make any promises.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.