none
Missing DWMAPI.dll causes problem with COM interop in c#

    Question

  • I have recently installed IE7, and am now experiencing a problem with COM interop in one of my c# projects. It seems that there is a dependency on a dll called DWMAPI.dll from the COM dll. I have read a bunch of posts about similar problems, and it seems this dll comes with Vista, but is missing on XP machines. For some reason, installing IE7 makes it become a dependency for things like .NET interop.

    The only solution I have been able to find in the forums and posts is to uninstall IE7. Microsoft has not yet posted anything that I could find in regards to this issue.

    Does anyone know something I don't? Any help is greatly appreciated.

    Thanks,
    Dan

    Tuesday, November 21, 2006 7:46 PM

Answers

  • DWMAPI.DLL is a load on demand DLL.  It doesn't get loaded unless it is needed.  I appears to have one entry point that is called in WXP code but may never be called on an XP platform.  On place it is registered to is SHDOCVW.DLL.  It looks to be referenced by other "shel" code but is never called on XP.

    If you link to libraries that are older than the currently installed it might be that the libs are being linked explicitly.  Load on demand DLLs, I believe,  should not be linked explicitly .

     YOu need to set the linker up to ignore this DLL or create  dummy DLL in your project that will satisfy this need to the linker.  YOu can also download and install teh newest SDK as it will probably have the updated project modules that will help the linker/loader to resolve these items correctly.

     

    I also suspect that installing NET 3.0 might provide the missing DLL but this is only a guess.

    Here is a thread with a similar issue with DWMAPI.  An MVP posts some more info.

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=974226&SiteID=1

    It is not unusual for a program to be buitl to support multiple platform versions and go looking for a praticular feature at runtime.  In this case the DLL would be "on-demand" and would only ever be called when needed.

    Your project should resolve this if it has teh right setup for the target environments.  This would allow a UI to support featues of both XP and "Glass".  IE7 appears to be built this way but it is also clear that other subsystems may also be affected on XP.  It's no broken.  My XP system with IE7 show DWMAPI as "load-on-demand" and "missing".  The system has no issues running although I haven't tried any builds that might reference a DLL that references DWMAPI such as SHDOCVW.

    I checked DLLHELP but it isn't listed.  Checking the SDK it shows "Windows Vista Oly" so it shouldn't be installed on XP platform. 

    This should probably be reported to the VS2005 support site as a possible bug but I suspect the answer will be to install the newest platform SDK.

     Added - 12/16 17:17

    I did a little more checking and found that the DLLs that are calling into DWMAPI are all (so far) XPSP2 DLLs so clearly this entry point was defined as SP2 or as a result of a patch to SP2.

    These calls will show up all over the system whenever you try to link a COM module.

    VB.NET and C#.NET do not support building of COM DLLs.  Tis is probably where some of the issues arise.  If you ae using other NET languages then you will probably have similar issues.  If you are calling into COM then you need to be sure to reference the COM DLL in the project and have an Interop assembly created.  If you are trying to run a COM object then try using "late-binding" as early binding will cause the linker to try to resolve all references - which it can't.

    This issue is appearing all over the web since the release of IE7.  Not sure why.  I suspect the DLLs were updated with IE7 on XP.  Hopefully MS will generate a KB on this and similar issues.

    Bottom line: Expected behavior. (until VS 2005 Team kicks in a better explanation )

     

     

     

     

     

    Saturday, December 16, 2006 10:12 PM

All replies

  • This thread suggests that the real problem is with access rights to registry keys.  That certainly rings true, I've seen problems on my own XP box before where administrators lost the right to read keys in the HKCR\CLSID key.  No hints what caused it, nasty problem.

    Tuesday, November 21, 2006 9:06 PM
    Moderator
  • No, the problem isn't with access rights to the registry. The problem is that IE7, or some component related to IE7, is trying to load DWMAPI.dll, which does not physically exist on XP machines.
    Tuesday, November 21, 2006 11:09 PM
  • Well, as long as you know what's going on.  There's a bunch of people, including me, that are running IE7 on XP.  Come to think of it, Vista is not yet for sale.  Everybody!
    Tuesday, November 21, 2006 11:18 PM
    Moderator
  • The thing is IE7 runs perfectly fine, but other apps are broken because for some reason they are trying to access the dll that is not even on the box. I ran a tool called Dependency Walker, and it tells me that my COM component is indirectly dependent on DWMAPI.dll. However, as I said, the DLL does not exist on XP machines.

    So once again, the problem is not with IE7. It is fine.

    Maybe I should just get a copy of the dll and register it on my box? Maybe someone can send me that file and I can try that?

    Warning: At least one delay-load dependency module was not found.

    Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

    Tuesday, November 21, 2006 11:50 PM
  • Oh yeah, I know Dependency Walker well.  Wonderful tool, got me out of many pickles before, ActiveX pickles particularly.  Delay load doesn't mean anything, it just a mark of "I might use it but I haven't yet made up my mind that I'll do".  The "okay, I'll use it" decision is made by configuration.  Configuration == Registry.
    Wednesday, November 22, 2006 12:25 AM
    Moderator
  • I sure would like to understand what you saying here.

    So you are saying that there is some way I can configure my C# environment to not recognize this DLL as a dependency of my COM dll??? Or change the registry somehow to accomplish this???

    If this is true, please explain how in detail.

    Thanks

    Wednesday, November 22, 2006 12:37 AM
  • I'm trying to tell you that you're having a problem because your PC is messed up.  In particular, because your registry is messed up.  I can see how it got messed up because it happened to me before.  The feedback from other web pages that talk about this problem confirm this.  There isn't a whole heck-of-a-lot you can do about it unless you are a registry black-belt.  Nobody is.  The original thread I linked offers a solution, it looks only mildly dangerous, give it a shot.  You'd have to uninstall IE7, fix it, reinstall IE7.  If it still doesn't work, you'd still have the "re-install Windows" option...
    Wednesday, November 22, 2006 1:24 AM
    Moderator
  • I read the other thread and it said to uninstall IE7 and fix the registry. It didn't say anything about reinstalling IE7. Thanks for your input, but I think you are wrong and simply confusing the issue. Unless you actually know a fix, please stop guessing.
    Wednesday, November 22, 2006 5:04 PM
  • i think i'm having the same problem with ntwdblib.dll depending on dwmapi.dll after installing ie7. php's sql server support requires ntwdblib.dll. i would like to try dropping dwmapi.dll in system32 and see if that fixes it but i can't find it anywhere.
    Thursday, December 14, 2006 7:18 PM
  • DWMAPI.DLL is a load on demand DLL.  It doesn't get loaded unless it is needed.  I appears to have one entry point that is called in WXP code but may never be called on an XP platform.  On place it is registered to is SHDOCVW.DLL.  It looks to be referenced by other "shel" code but is never called on XP.

    If you link to libraries that are older than the currently installed it might be that the libs are being linked explicitly.  Load on demand DLLs, I believe,  should not be linked explicitly .

     YOu need to set the linker up to ignore this DLL or create  dummy DLL in your project that will satisfy this need to the linker.  YOu can also download and install teh newest SDK as it will probably have the updated project modules that will help the linker/loader to resolve these items correctly.

     

    I also suspect that installing NET 3.0 might provide the missing DLL but this is only a guess.

    Here is a thread with a similar issue with DWMAPI.  An MVP posts some more info.

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=974226&SiteID=1

    It is not unusual for a program to be buitl to support multiple platform versions and go looking for a praticular feature at runtime.  In this case the DLL would be "on-demand" and would only ever be called when needed.

    Your project should resolve this if it has teh right setup for the target environments.  This would allow a UI to support featues of both XP and "Glass".  IE7 appears to be built this way but it is also clear that other subsystems may also be affected on XP.  It's no broken.  My XP system with IE7 show DWMAPI as "load-on-demand" and "missing".  The system has no issues running although I haven't tried any builds that might reference a DLL that references DWMAPI such as SHDOCVW.

    I checked DLLHELP but it isn't listed.  Checking the SDK it shows "Windows Vista Oly" so it shouldn't be installed on XP platform. 

    This should probably be reported to the VS2005 support site as a possible bug but I suspect the answer will be to install the newest platform SDK.

     Added - 12/16 17:17

    I did a little more checking and found that the DLLs that are calling into DWMAPI are all (so far) XPSP2 DLLs so clearly this entry point was defined as SP2 or as a result of a patch to SP2.

    These calls will show up all over the system whenever you try to link a COM module.

    VB.NET and C#.NET do not support building of COM DLLs.  Tis is probably where some of the issues arise.  If you ae using other NET languages then you will probably have similar issues.  If you are calling into COM then you need to be sure to reference the COM DLL in the project and have an Interop assembly created.  If you are trying to run a COM object then try using "late-binding" as early binding will cause the linker to try to resolve all references - which it can't.

    This issue is appearing all over the web since the release of IE7.  Not sure why.  I suspect the DLLs were updated with IE7 on XP.  Hopefully MS will generate a KB on this and similar issues.

    Bottom line: Expected behavior. (until VS 2005 Team kicks in a better explanation )

     

     

     

     

     

    Saturday, December 16, 2006 10:12 PM