.netinternet-explorerflashbhoieaddon

How to change my IE extension to resolve an Access Violation in another module (flash.ocx) crashing IE?

I have an Internet Explorer extension (a BHO) that works nicely on thousands of machines but in some scenarios seems to cause Flash to crash the iexplore.exe with an Access Violation. What can I try doing to avoid this clash?

More details:

In one customer's environment we have a situation where when after visiting a website with Flash and closing the IE tab the tab process crashes. This only happens if both Flash and my extension are enabled and isn't replicable so far on workstations outside this company's environment. It still happens if my extension is configured to do nothing on that page - i.e. some of my code still executes but very little.

If the website isn't in Trusted Sites then the tab is running in Protected Mode and the result of the crash is a window saying the web page wants to run dw20.exe (i.e. Dr Watson) example.

If the website is added to Trusted Sites then an error is written to the windows application event log and IE reopens the tab with a small info bar message saying IE recovered it from a crash. Either way it's frustrating! The user really doesn't care if the process crashes when they close the tab, so I'd be happy with a workaround that means no error message is shown to the user and the tab doesn't reopen.

The windows application event log doesn't say much but it does say that the iexplore.exe process crashed with faulting module flash: 

Error / Application Error / EventID=1000

Faulting application name: iexplore.exe, version 9.0.8112.16592, time stamp 0x544e95a7
Faulting module name: Flash32_13_0_0_214.ocx, version 13.0.0.214, time stamp 0x5359c422
Exception code: 0xc0000005
Fault offset: 0x00073678
Faulting application start time: 0x01d0099db319df49
Faulting application path: C:\Program Files\Internet Explorer\iexplore.exe
Faulting module path: C:\Windows\system32\Macromed\Flash\Flash32_13_0_0_214.ocx
ReportId: 0094988b-7591-11e4-93e6-6cf0492a8610

This was a fairly new version of flash but not the latest. They've tried upgrading to the latest version but that had the same symptoms.

Their workstations have Sophos antivirus running, and in some rare cases we've seen antivirus causing problems with our extension. We tested after stopping all the windows services that mentioned Sophos and the same problem occurred so I'm fairly sure it's not related to that.

My extension is built using .NET 3.5 SP1, which isn't an ideal way to do it because of potential runtime conflicts with other extensions, but that's how it is for now.

If I disable my extension the problem goes away. If I disable Flash the problem goes away. The faulting module being Flash32_13_0_0_214.ocx strongly points to it being a bug there but I suppose in theory it could be a problem in my code. No unmanaged code is being executed from my extension so it can't be that, so I can't think of anything my extension could do that could cause an AccessViolation. That leaves the possibility of a bug in Flash, which seems entirely possible, or a problem with the way I interact with the COM objects from IE. However, it's unlikely that the Flash team would investigate such a bug report unless I can point to something specific and replicable, and right now I can't replicate on any dev machines so that's not great. And even if it is a Flash bug, from the customer's point of view that's no different from it being a bug in my product: either I get it fixed or my product will be uninstalled and they'll keep Flash.

Options

What I'm hoping for are some ideas about:

It can be a while before I get time with the customer to test different options, so I'd like a few things to try. Any ideas GREATLY appreciated.

Some random ideas I've had so far. Any of them sound worth trying?

Update

The customer replicated the problem again and instead of the Flash ocx the faulting module was jscript9.dll. They also reported seeing the same with ntdll.dll although I haven't seen that myself. 

Faulting application name: iexplore.exe, version: 9.0.8112.16575, time stamp: 0x53ee1acb 
Faulting module name: jscript9.dll, version: 9.0.8112.16575, time stamp: 0x53ee1c49 
Exception code: 0xc0000005 
Fault offset: 0x00007264 
Faulting process id: 0x1bb4 
Faulting application start time: 0x01cfec57f247cb53 
Faulting application path: C:\Program Files\Internet Explorer\iexplore.exe 
Faulting module path: C:\Windows\System32\jscript9.dll 
Report Id: 50b58f63-584b-11e4-bc66-6cf0492a8610 
Faulting package full name: %14 
Faulting package-relative application ID: %15

So I guess this opens it up to not being Flash-related...

Solution

  • Problem is, with .Net you can do nearly nothing to actively mess the memory. So, unless you are playing a lot with Api calls, it's really difficult it's something in your code causing the fault.

    Relocating the dll seems to me the most promising thing to do; not messing with GCC, too, seems a really good option (and it is ALWAYS, not only in this case).

    Another problem is that it's not your module who is faulting, and this is something to consider seriously: it's not your code who is trying to reach a memory area malloc'ed by another dll, but it's their code trying to mess with your dll's memory space.

    Probably your best bet is DW; by letting it save the dump, you can travel trough the stack trace to find the code causing the problem. Back tracing again, you can find the moment when some parameter become garbage. Finally, you can use this https://msdn.microsoft.com/en-us/windows/hardware/hh852365 to debug the crash in real time. Why all of this? Well, because if you are not doing anything strange in your dll (like manually malloc'ing), in .Net you cannot in any way mess with memory so to 'cause an 0x05 in another dll; 99% it's this specific IE with its specific configuration the cause of everything, so your fastest solution would be to debug, find the offending code, then zip every information you have and mail it to MS.