Missing Dependencies for C++/CLI Custom Debugger: IESHIMS.DLL & WER.DLL

Question

Hi,

I have a VS Package for VS 2005 & 2008 written in C# / MPF that includes a custom debugger . One of the DLLs for the custom debugger is written in VC++/CLI (much like the MPF debugger example code).

Some time in the last two weeks the custom debugger has started to fail to load with a dependency problem, depend.exe shows that the missing DLLs are IESHIMS.DLL & WER.DLL:

MyDebug.DLL

--> MSVCM80.DLL

    --> OLE32.DLL

      --> ADVAPI32.DLL

        --> SECUR32.DLL

          --> NETAPI32.DLL

            --> DNSAPI.DLL

              --> IPHLPAPI.DLL

                --> MPRAPI.DLL

                  --> SETUPAPI.DLL

                    --> SHELL32.DLL

                       --> SHDOCVW.DLL

                          --> MSHTML.DLL

                             --> IEFRAME.DLL

                                --> IESHIMS.DLL *

                                --> WER.DLL       *

In between it previously running, and it not today I have mostly been working on UI issues with the VSPackage itself, and anyway, rolling back these changes does not make any difference.

Before I start rolling back the various Windows updates that have happened recently (about half the DLLs in the list have been changed in the last two weeks, and "SHDOCVW.DLL" did not previously have these dependencies), is there anything I could have done to change what the DLL depends on that would cause it to try and include the two missing DLLs (they really are nowhere on my system)?

Thanks,

Simon.

Answer 1

These dependencies were introduced by upgrading to Internet Explorer 8 (new version of MSHTML and IEFRAME).

But as these dependencies are delayloaded it's most likely unrelated to your real issue. It's usually easier to detect this kind of package loading errors using the unmanaged debugging mode of Visual Studio on another Visual Studio instance.

Answer 2

These dependencies were introduced by upgrading to Internet Explorer 8 (new version of MSHTML and IEFRAME).

But as these dependencies are delayloaded it's most likely unrelated to your real issue. It's usually easier to detect this kind of package loading errors using the unmanaged debugging mode of Visual Studio on another Visual Studio instance.

That's what I've been doing.

However, yet another set of WindowsXP updates and a reboot later, and it's all working again.

Thanks,

Simon.

Answer 3

Hello,

i was missing these dll's:
EFSADU.DLL
IESHIMS.DLL
VSANSI.DLL
WER.DLL

and only didnt find.

IESHIMS.DLL
VSANSI.DLL

just like the TS.

except the problem is not solved after reboot and update.
what should i do?


Thanks.

PS
ofcourse i dont have Vista but XP SP3

sorry i think i need to make my own post ;)

admin you can delete this if you want.

Answer 4

EFSADU.DLL
IESHIMS.DLL
WER.DLL

Are the ones reported when I distribute a very simple VB.Net COM Class to XP machines with IE8.

On XP machines without IE8, only IESHIMS and WER are reported as missing, but the class works fine anyway. So it seems that the missing EFSADU.dll (part of microsoft's Encrypting File System) is the issue, at least for my simple COM Class deployment.

If I add EFSADU to the deployment, then other dependency problems prevent the class from functioning on XP machines with IE8.

I've experimented with various service packs and even vcredist_x86 as one person suggested. Nothing makes a dent.

I'm working with an ultra-simple project, so there is nothing wrong with the code. The class has one function that returns True. I reference it from VBA in Excel and it returns True, as long as the machine doesn't have IE8... but it could be something else, that's just the only consistency I've found. In almost every other way, the machines are identical.

There are lots of posts that touch on this topic, but I've found no concrete answers. This is so mind-bogglingly simple... Wow! Can't believe I am having trouble distributing a basic com class, but it is not like I do this every day. Maybe one of you experts can help us with this problem that IE8 seems to have introduced.

Thanks!

... This issue could still be IE8 related on machines without microsoft's Encrypting File System (EFS), but I've found XP Pro machines with IE8 that successfully run the deployed COM Class. (XP Pro comes with EFS.) So my focus is shifting to finding a way to deploy EFS with the COM Class or finding a way to remove that dependency. It certainly isn't necessary for the project.