CODEWITHSUNDEEP
c++cominternet-explorer-8mshtml
egrunin
egrunin

Reputation: 25063

SHDocVw::IShellWindowsPtr fails with IE8? (Error 0x80040154)

My program is a dll that hooks into a running instance of IE. It's worked fine for years.

Recently I dusted it off and ran it, but the last line below fails with hr = 0x80040154:

#import <mshtml.tlb>     rename("value", "theValue") rename("event", "theEvent")
#import <shdocvw.dll> 

// ....

SHDocVw::IShellWindowsPtr spSHWinds;
HRESULT hr = m_spSHWinds.CreateInstance(__uuidof(SHDocVw::ShellWindows));

Could it matter that IE7 has been replaced by IE8? Where else should I look?

I'm using VS2008, if that matters.

Edited to add

I don't see that it could be a 32/64 bit issue - it ran fine last year on this same machine. The only thing that's changed (as far as I have noticed) is the version of IE, from 7 to 8.

Note to the bounty hunters:

I only have access to this system for a few hours a day (around 0:00 EST), so you may not get quick responses to your suggestions, but I will look into them.

If you think there are things I should be checking (registry values, for example), be specific.

Edited to add:

I now see that the first time I call CreateInstance, it returns 0x80070002, not 0x80040154.

Upvotes: 1

Views: 1191

Answers (1)

Hans Passant
Hans Passant

Reputation: 941635

That's going to be very hard to diagnose. The ShellWindows coclass is special, its CLSID registry key is HKEY_CLASSES_ROOT\CLSID\{9BA05972-F6A8-11CF-A442-00A0C90A8F39}. When you look there, you'll see nothing useful registered there. The background story is that this is a leftover of an ill-fated attempt to make the Windows shell resemble a web browser. Still visible today, enumerating the shell windows returns both Windows Explorer and Internet Explorer instances.

The SysInternals' ProcMon utility is almost always the weapon of choice to debug 0x80040154 errors but it falls flat here. You can see it probing the registry, and not finding what it is looking for, but then the program knows how to load ieframe.dll anyway. This can only work by the operating system intercepting the CoCreateInstance() call. Which makes sense in general, considering the coclass enumerates shell windows.

All you got left is the trial-and-error approach. Reinstall IE first, OS next. Or to shove the machine out of a 4th story window before it eats too much of your valuable time.

Upvotes: 4

Related Questions