need a help regarding dwmapi.dll and DwmExtendFrameIntoClientArea function

Question

Dear All,
    My compiled code asking dwmapi.dll, which is nowhere to find on my windows XP box. using dependency walker, it reports that the "c:\windows\system32\urlmon.dll" is looking for this dll, and the function name is DwmExtendFrameIntoClientArea. I searched internet, and some people say that the IE7 is making this problem. and I am kind of agree, and I have it on my machine. So I need this dll badly, or somebody can give me a way to un-install IE7 quickly?
   Thanks a lot.
    rcen

Answer 1

dwmapi.dll is a Windows Vista DLL, you can only use DwmExtendFrameIntoClientArea on Vista.

Answer 2

Hello rcen!

I have a selfsame Yours problems . The my solution was that I make a DWMAPI.DLL with the function DwmExtendFrameIntoClientArea, like stub thah do notfing.

Regards

YankoNik

 

Answer 3

I have come across this same problem working with a Microsoft partner.  I picked up one of their latest DLLs and it has a dependency to dwmapi.dll.  It appears that Beta users of Vista are inadvertently picking up this dependency in their proprietary projects.  Is there a place to download this DLL so I can move forward or must I work with your partner to get this resolved?

Answer 4

Upon further research, scratch my previous message.  The real culprit is IE7.  It appears my install of IE7 includes a version of IEFRAME.DLL that has this missing dependency.  This is throwing an exception in a 2002 dll from the development partner.

Answer 5

P VanSickel wrote:

I have come across this same problem working with a Microsoft partner.  I picked up one of their latest DLLs and it has a dependency to dwmapi.dll.  It appears that Beta users of Vista are inadvertently picking up this dependency in their proprietary projects.  Is there a place to download this DLL so I can move forward or must I work with your partner to get this resolved?

You'll have to address it with the vendor.  They're not supposed to have a load-time link to a Vista-only function.  dwmapi.dll will never be redistributed to all versions of Windows.  ...unless they only support Vista...

Answer 6

Thats fine for yourself.  The problem is this is propogating everywhere with Microsoft updates and needs to be corrected by Microsoft.  I am not going to start delivering fake dlls to all of our company PCs by hand.  That will only lead to more problems down the road.  Microsoft needs to step up and deal with this.

Answer 7

come back to this thread. Thanks for your guys reply. Sorry that I should come back earlier.
I did the following, if I remember correctly.
1) uninstall IE7. result: windows XP gave me blue screen, right after reboot.
2) go to safe mode, use system restore, go back before uninstall IE7.
3) uninstall IE7 again, this time it asked some chm file that is not in the IE7 directory. so just find an old one from the I386 directory.
4) reboot.
5) Windows XP is OK, with IE6 and my program start running.


MS should do something and apologize to Windows developers!!!

Answer 8

I also had this problem. We have a Library  (.dll) that we use to open sockets and URLs and do http transfer. All of a sudden LoadLibrary("name.dll") returns error 131. Open further review in depends walker it shows that dwmapi.dll is attempting to get linked into my dll. Strangely enough I don't get a "can't find dll message".

Anyway.... it seems that compiling anything that touches the internet and IE7 are not compatable.

Removed IE7 and everything works.

Merry Christmas from Mr. Gates. :)

Larry

Answer 9

I agree with larry E.Ramey: This problem does not just concern new programs or developments. I just tried to update my Benq DVD-writer to find that a program compiled 2004 has "a reference" to dwmapi.dll... link to the program:

http://www.benq.se/support/downloads/drivercounter.cfm?dpid=647&id=2912&size=946%20KB&type=B&filename=B7W9.zip&type=B&whereto=ftp://217.21.255.99/dvd%2drw%2ffirmware%2fdw1620a%2fb7w9%2ezip

This tools also exhibits the same problem.

http://www.benq.se/support/downloads/drivercounter.cfm?dpid=647&id=2223&size=173%20KB&type=A&filename=BookType_Management_v8.4.zip&type=A&whereto=ftp://217.21.255.99/dvd%2drw%2fsoftware%2fbook%5ftype%5fmanagement%2fbooktype%5fmanagement%5fv8%2e4%2ezip

(its long, yes)

Will remove IE7 to check if that is a "short-term" fix.

UPDATE:

Yes, without IE7 on A Windows XP Professional SP2 machine the program run perfectly... Added IE7 again (installed OK according to installer log)... suddenly the reference to dwmapi.dll is back and the program does not run anymore... only results in an Serious error has been detected...

My conclusion.... IE7 is broken in some configurations.... (and the mere presens of a reference to a Vista-file in the code is BAD news, indicates risk for code mixing).

(My machine has Visual Studio 2003 with all updates installed.) 

Best regards

pgtest70

 

Answer 10

Has anyone figured this problem out yet?  Is un-installing IE7 the only answer to solve the dwmapi.dll problem? 

My application, compiled under VC++ 2005 Express works fine on my clients Windows Server 2003 system but as soon as IE7 is installed I get the dwmapi.dll error message removing IE7 fixes the problem but isn't there a better way out there?  I can't believe Microsoft would really want developers to tell clients to un-install IE7.  Please, does someone have a fix for this issue?

Thanks, Carrie

Answer 11

I too could do with an 'official' answer/fix for applications failing to load on non Vista builds with IE7 installed due to the call to DWMAPI.dll.  Simply faking this dll as some have suggested does not seem to be a good idea.

Answer 12

Does your application have a Forms interface?  If not try adding a reference to System.Windows.Forms to your application.

I think the problem is that something gets loaded that might want to show a user interface, and uses MSHTML to render it.

I had this problem creating a service (with no UI) in Visual Studio 2005 and C#.  Adding the ProjectInstaller created this dependency -- when you install a service to use a specific User account, it displays a Form requesting the name and password.

So I guess I would call this a bug, or maybe an unintended consequence, of updating IE7 libraries that are in heavy use by other .NET modules. But I can see the argument that's it's not a bug either.

Eric

Answer 13

 

How is it that there's still no official patch for this problem yet?  This is still easily reproducible, using nothing but MS software:

 

On an XP machine, download Platform SDK (I'm using Server 2K3 R2, but I believe any release will show the same behavior), compile one of the DirectShow filters, for example, Samples/Multimedia/DirectShow/Filters/Ball.  Now try to register the DLL: regsvr32 ball.ax.  Oops!  LoadLibrary("ball.ax") fails, and if you trace the dependencies through dozens of layers, it's our old pal, dwmapi.dll!

 

So now I'm faced with a problem:  do I abandon development on DirectShow filters, thus stalling my development effort on this project indefinitely, or do I ditch IE7 and go back to IE6?  Seems like a pretty simple choice to me.

 

Note to Microsoft: this needs to be escalated and fixed already!  This problem was reported nearly a year ago and people are still getting bit by this and wasting hours trying to find a workaround.

Answer 14

dougr650 wrote:

How is it that there's still no official patch for this problem yet?  This is still easily reproducible, using nothing but MS software:   On an XP machine, download Platform SDK (I'm using Server 2K3 R2, but I believe any release will show the same behavior), compile one of the DirectShow filters, for example, Samples/Multimedia/DirectShow/Filters/Ball.  Now try to register the DLL: regsvr32 ball.ax.  Oops!  LoadLibrary("ball.ax") fails, and if you trace the dependencies through dozens of layers, it's our old pal, dwmapi.dll!   So now I'm faced with a problem:  do I abandon development on DirectShow filters, thus stalling my development effort on this project indefinitely, or do I ditch IE7 and go back to IE6?  Seems like a pretty simple choice to me.   Note to Microsoft: this needs to be escalated and fixed already!  This problem was reported nearly a year ago and people are still getting bit by this and wasting hours trying to find a workaround.

Good luck with that.  I've found the IE7 team, if there still is one; to be completely unresponsive.  IE7 have to be the lowest-quality product that Microsoft currently supports.  I have more problems with IE7 than with IE6.    The IE teams is one of the stand-offish teams that hasn't got any space on Connect.Microsoft.com--suggesting they just don't care if there are any bugs and certainly don't care about supporting their product.

 

The recommended support site is http://www.microsoft.com/windows/products/winfamily/ie/iefaq.mspx.

 

If I were you, and have and MSDN license, I would phone customer support and try to get this resolved.  I've found, barring contacting a member of a team directly, phoning PSS is the only way to get things resolved.

Answer 15

Start VS2005. Select MFC ActiveX Control and follow the wizard to create a project. Compile and it will start giving error of PRJ0050. Use depends.exe and will list dwmapi.dll as a dependency.

 

Go figure !?

Answer 16

Hoon1234 wrote:

Start VS2005. Select MFC ActiveX Control and follow the wizard to create a project. Compile and it will start giving error of PRJ0050. Use depends.exe and will list dwmapi.dll as a dependency.   Go figure !?

Try repairing your .NET installations and trying the above steps again.

Answer 17

The MFC ActivexX control creation wizard in VS2005 is broken. Try creating one using the wizard and compiling it. It should take at most a minute. I even created a dummy stub for dwmapi.dll. An entire class of creating applications is missing. Sad !

 

Answer 18

Has a fix been posted for the IE7 dwmapi.dll DwmExtendFrameIntoClientArea issue?

 

Thanks.

 

Answer 19

Craig Kilstrom wrote:

Has a fix been posted for the IE7 dwmapi.dll DwmExtendFrameIntoClientArea issue?   Thanks.

Not for IE7; but IE8 Beta is available.  I don't know if this issue has been addressed in IE8.  If you find that it has, please post back.

Answer 20

I had the same problem and implemented a small debugable dll with the same name. Here is the code.

Put the dll into your bin directory and voila, it works. At least for me.

Success

Jasper

 

#include "stdafx.h"

#include <windows.h>

typedef struct _MARGINS {

int cxLeftWidth;

int cxRightWidth;

int cyTopHeight;

int cyBottomHeight;

} MARGINS, *PMARGINS;

#define DllExport __declspec( dllexport )

extern "C" DllExport HRESULT DwmExtendFrameIntoClientArea(HWND hWnd, const MARGINS *pMarInset);

#ifdef _MANAGED

#pragma managed(push, off)

#endif

BOOL APIENTRY DllMain( HMODULE hModule,

DWORD ul_reason_for_call,

LPVOID lpReserved

)

{

return TRUE;

}

DllExport HRESULT DwmExtendFrameIntoClientArea(HWND hWnd, const MARGINS *pMarInset)

{

return (HRESULT)S_OK;

}

 

#ifdef _MANAGED

#pragma managed(pop)

#endif

 

Answer 21

Hello Everyone,

I’m writing a small ActiveX control and some time ago experienced the problem with similar symptoms. Control was built correctly but I couldn’t register it with regsvr32, the error was “The specified module could not be found”.

Dependency Walker showed only depends to SHLWAPI.dll and IEFRAME.dll, but they were in the previous “working” versions of ActiveX control too.

While searching internet, I saw a good advice to check the registry process with Process Monitor by sysinternals. Then I discovered that regsvr32.exe tries to load vcompd.dll while registration.

So, when I removed

#include <omp.h>

from one of the lib used by ActiveX control, everything worked fine.

I hope my post will safe some time for somebody… 

Best regards,

Eugene

Answer 22

You have specified early binding in the linker.  Change it to late bindng and the problem should go away.

Most applications deployed on a system with Internet Explorer 7 installed will show a dependency on DWMAPI.DLL, which may not be present on the system. 
 

When IE7 is installed IEFRAME.DLL in the System32 folder is upgraded. The new version has a dependency on DWMAPI.DLL.  Applications becomes dependent on DWMAPI.DLL because of the following chain or any subset thereof: 

 

ADVAPI32.DLL -> WINSTA.DLL -> NETAPI32.DLL -> DNSAPI.DLL ->IPHLPAPI.DLL -> MPRAPI.DLL -> ACTIVEDS.DLL -> ADSLDPC.DLL -> CREDUI.DLL -> SHELL32.DLL -> SHDOCVW.DLL -> MSHTML.DLL -> IEFRAME.DLL -> DWMAPI.DLL

 

DWMAPI.DLL doesn't exist on pre-Vista machines. The only call made into DWMAPI.DLL is DwmExtendFrameIntoClientArea() used in Aero to set which parts of a window should be rendered with glass and which should be opaque. The DwmExtendFrameIntoClientArea() function gets called by IEFRAME.DLL only if OSVERSIONINFO.dwMajorVersion as returned by GetVersionEx() is >= 6, which means it's running on Windows Server 2008 or Vista.

 

If osvi.dwMajorVersion >= 6 DWMAPI.DLL will be present.  If osvi.dwMajorVersion < 6 DWMAPI.DLL will not exist on the machine but DWMAPI.DLL is a delay load module. The Windows demand-load DLL concept means it will not normally be loaded until a call to DwmExtendFrameIntoClientArea() is made by IEFRAME.DLL. This call is never made on a non-Vista box due to the version check above.

 

However, if an application or DLL has been built to resolve everything at load time before it runs (i.e. uses early binding which negates delay-loading) it will fail in the way you describe.

Answer 23

Install VCRedist that is distributed with your specific MS Visual C++ Version and the problem will go away

Hope it helps!

Answer 24

Sorry but this does not solves the issue and BTW, it wouldn't work for debug versions anyway. As a side effect It would be impossible to run debug versions on XP due to this.

Answer 25

Bondi,  Can you tell me how to change the binding please?  In 27 years of doing development I have never heard of early/late binding.

My app is designed to run on a embedded XP machine and now because my development XP got updated with IE 7 I seem to be buggered.  I guess the only solution I have is to create a dummy dll to satisfy the problem.

If any body has any suggestions I'm more than glad to hear them.

Thanks,
Bob Pombrio