Hi there,
About one week ago I got a letter from one my old customer who is working on Internet Explorer add-in (I can’t add more details, I’m sorry).
He told me that 32 bit version of Internet Explorer 8 on Win7 x64 doesn’t start well if BoxedApp is injected there.
Things are very simple: using CreateRemoteThread we inject a little code to initialize all hooks and then execute entry points of an application.
I tried to debug the IE process to locate a reason of the quit.
Aha, CreateWindowEx(“IEFrame”) fails. Let’s check WM_CREATE handler. Yeah, it fails, but why… Stop. It unable to create some COM object, HRESULT is 0x80040002. I know this code, it means: Interface not supported. What’s the…
Firstly I thought hooks are the issue. I removed all of them, but IE still exits at some points even before displaying a windows.
Just exits.
I told myself: “OK, that’s not hooks, but what”. And I commented out and commented out new and new parts of code, checked and checked how IE works. To be precisely, does that call fail or not.
One detail. At some point BoxedApp launches several threads to support interprocess communications between processes attached to virtual environment.
At last I found that if these threads are not started, that call returns S_OK and IE startups well. Even one this thread is enough to prevent IE from starting well!
The first call of the thread is: CoInitializeEx(NULL, COINIT_MULTITHREADED).
I removed it and IE starts well. But what’s funny, other versions of IE on other versions of Windows could start well even with this call of CoInitializeEx. But it was absolutely important for IE8 on Win7 x64.
It’s not the first time I run into issues with COM subsystem on WIndows. But before this case I’ve been thinking that COM “things” are located within its thread and they don’t interfere. Or I’ve forgotten (had I know that?) that the very first call of CoInitialize / CoInitializeEx is so important.
A man who develops and sells his software. 