Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

OSR Seminars


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 6  
17 Feb 18 23:03
Henrika Troy
xxxxxx@gmail.com
Join Date: 16 Feb 2018
Posts To This List: 1
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-micro soft-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 --
  Message 2 of 6  
17 Feb 18 23:37
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11963
Is it allowed to use shared libs[Dll]/dynamic linking with UMDF Drivers

On Feb 17, 2018, at 8:02 PM, xxxxx@gmail.com <xxxxx@lists.osr.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-micro soft-c-runtime-with-user-mode-drivers-and-apps <https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/using-the-micr osoft-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. 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. --
  Message 3 of 6  
18 Feb 18 00:06
Doron Holan
xxxxxx@microsoft.com
Join Date: 08 Sep 2005
Posts To This List: 10209
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 <xxxxx@lists.osr.com> on behalf of xxxxx@probo.com <xxxxx@lists.osr.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<mailto:xxxxx@gmail.com> <xxxxx@lists.osr.com<mailto:xxxxx@lists.osr.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-micro soft-c-runtime-with-user-mode-drivers-and-apps<https://na01.safelinks.protection. outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdr ivers%2Fdevelop%2Fusing-the-microsoft-c-runtime-with-user-mode-drivers-and-apps&d ata=04%7C01%7CDoron.Holan%40microsoft.com%7C30d78babbbc745be8eff08d57689429a%7C72 f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636545254297179103%7CUnknown%7CTWFpbGZsb 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=3Dl8In GcH6J%2FxB7bTE9E%2FWDeHjPL7O8FdLqvjUk1v2wmw%3D&reserved=0> 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<mailto:xxxxx@probo.com> Providenza & Boekelheide, Inc. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> --
  Message 4 of 6  
18 Feb 18 06:15
Jan Bottorff
xxxxxx@pmatrix.com
Join Date: 16 Apr 2013
Posts To This List: 434
Is it allowed to use shared libs[Dll]/dynamic linking with UMDF Drivers

"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 <xxxxx@lists.osr.com> 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<mailto:xxxxx@lists.osr.com> <xxxxx@lists.osr.com<mailto:xxxxx@lists.osr.com>> on behalf of xxxxx@probo.com<mailto:xxxxx@probo.com> <xxxxx@lists.osr.com<mailto:xxxxx@lists.osr.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<mailto:xxxxx@gmail.com> <xxxxx@lists.osr.com<mailto:xxxxx@lists.osr.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-micro soft-c-runtime-with-user-mode-drivers-and-apps<https://na01.safelinks.protection. outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdr ivers%2Fdevelop%2Fusing-the-microsoft-c-runtime-with-user-mode-drivers-and-apps&d ata=04%7C01%7CDoron.Holan%40microsoft.com%7C30d78babbbc745be8eff08d57689429a%7C72 f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636545254297179103%7CUnknown%7CTWFpbGZsb 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=3Dl8In GcH6J%2FxB7bTE9E%2FWDeHjPL7O8FdLqvjUk1v2wmw%3D&reserved=0> 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<mailto:xxxxx@probo.com> Providenza & Boekelheide, Inc. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> --
  Message 5 of 6  
18 Feb 18 13:09
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4090
Is it allowed to use shared libs[Dll]/dynamic linking with UMDF Drivers

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 <xxxxx@lists.osr.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???. > > > <...excess quoted lines suppressed...> --
  Message 6 of 6  
19 Feb 18 00:12
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11963
Is it allowed to use shared libs[Dll]/dynamic linking with UMDF Drivers

On Feb 18, 2018, at 3:15 AM, xxxxx@pmatrix.com <xxxxx@lists.osr.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. --
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 17:43.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license