Part of our product is an IE plugin (BHO), which is running happily in lots of different environments across multiple OS versions/IE versions.
However, in a trial setup for one customer, running XP SP3 machines via citrix XenDesktop, IE 7 is crashing when the two below conditions are met:
Our plugin is loaded
The Shockwave flash object add-on is loaded (latest version - Flash11e.ocx)
Some extra info:
The crash happens when we then try and show a dialog to the user, or shortly after this. However the crash doesn't happen in our code, which is all written in C#, it happens in various places, often ole32.dll.
Our dialogs are HTML pages rendered in a webbrowser control, shown in a Form via form.ShowDialog(ownerWindow) in the BHO.
Either plugin seems to work fine independently. Disabling flash, or skipping any sites that use flash prevent the crash.
The customer is reasonably accommodating, and I was able to run IE with the MS Debugging Tools in order to capture a few dumps at the time of the crash. I'm now having some trouble interpreting the dumps. Thinking it was heap corruption I ran the debugging tools with full pageheap enabled, but that did not trigger a breakpoint.
The analysis from the Debugging tools is as follows:
In
iexplore_PID_5064_Date_12_20_2011__Time_11_19_26AM_161_Second_Chance_Exception_C0000005.dmp
the assembly instruction at ole32!HandleIncomingCall+e2 in
C:\WINDOWS\system32\ole32.dll from Microsoft Corporation has caused an
access violation exception (0xC0000005) when trying to read from
memory location 0x03ce4ff8 on thread
The stack trace at the point of crash is:
Thread 7 - System ID 1140
Entry point ieframe!CTabWindow::_TabWindowThreadProc
Create time 20/12/2011 19:18:08
Time spent in user mode 0 Days 0:0:19.828
Time spent in kernel mode 0 Days 0:0:10.468
Full Call Stack
Function Arg 1 Arg 2 Arg 3 Arg 4 Source
ole32!HandleIncomingCall+e2 0f9aafbc 00000034 00000001 07e8ab6c
ole32!STAInvoke+24 17444f80 00000001 0781efc0 077e8f10
ole32!AppInvoke+7e 17444f28 077e8f10 0781efc0 07e8ab6c
ole32!ComInvokeWithLockAndIPID+2c2 17444f28 077ec420 00000000 17444f28
ole32!ComInvoke+60 17444f28 00000400 0774ee30 07bcfe48
ole32!ThreadDispatch+23 17444f28 07bcfeb0 7752b096 00000000
ole32!ThreadWndProc+fe 005d0594 078b6ee0 0000babe 17444f2c
user32!InternalCallWinProc+28 7752b096 005d0594 00000400 0000babe
user32!UserCallWinProcCheckWow+150 00000000 7752b096 005d0594 00000400
user32!DispatchMessageWorker+306 7bcff64 00000000 07bcffb4 3e25e69b
user32!DispatchMessageW+f 07bcff64 0013e490 0013e5b8 07868ff0
ieframe!CTabWindow::_TabWindowThreadProc+189 07e03e30 0013e490 0013e5b8 07868ff0
kernel32!BaseThreadStart+37 3e25e464 07868ff0 00000000 00000000
I'm going to see what else I can get from this dump file, but I'm hoping someone here will have a great idea. I'd like to test a lot more stuff at the customer site, but we only have so many chances with them, so I need to use any time I get there very wisely.
For me a couple of next steps seem to be:
If the problem is flash messing up something in the way of us showing dialogs, I'd like to test a completely stripped down BHO that just shows dialogs, to show that the problem does not lie with our code.
There are a lot of other plugins installed on the machine, it would be nice to start with a stripped down image and build up from there, to see when the problem starts triggering.
Sometimes the crash happens in pseuoserverinproc.dll, which is part of HDX MediaStream, which runs flash content locally rather than on the server.
== update
I've had quite a bit of success with WinDbg analysing the dumps that I have. I think it makes quite a bit of sense to try and use gflags/windbg on the desktop that is having the troubles and debug it live.
That would be my recommended next step to anyone in a similar position at the moment, will know more about how good this advice is an a weeks time when I've had a chance to apply it.
There is a debugger version of the flash player which can output diagnostic information that might help you. I realise that the issue isn't necessarily flash, but it might offer some insight into possible issues.
I must admit I havn't installed it for some time, but I believe these links might help you:
Insutrctions on how to configure the debugger version to output logs:
http://kb2.adobe.com/cps/403/kb403009.html
The download link of the debugger version:
http://www.adobe.com/support/flashplayer/downloads.html
One thing you could do outside the customer site is run your code through a static analyzer, for example pclint to see if there any obvious bugs in your own code that get triggered in special situations.
We solved the problem in the end (well worked around it). If anyone is interested, this is how we did it.
Analysing the stack dumps with WinDbg (which is a great tool). We found that after the problem was isolated to showing WinForms in iexplore.exe after flash had loaded in XenDesktop deployments. Knowing this we were able to work around the problem.
The key was getting good crash dumps, working out a minimal reproduction scenario and having a good customer that let us test our theory!
Related
From a lot of our customers, we have been getting complaints that Outlook unexpectedly crashes (complete process restart) when using our plugin.
So far it has been impossible to reproduce, we can only analyze the logs after the fact and the only thing we know so far is that if we turn one specific add-in off, then the problem stops (it's a local add-in that helps sending e-mails with a configurable template). This add-in runs on .NET and is written in C#.
We have spent weeks gathering and analyzing logs. The crash always reports an Event ID 1000 in the Event Log, which points the faulting module to kernelbase.dll / olmapi32.dll / wwlib.dll / ntll.dll.... or some other dll file. The crash happens on several Outlook builds, old or new, monthly channel or semi channel, doesn't matter.
From our code we were finally able to simulate one crash after running an analysis in VisualStudio which warned us about some potential NullExceptions, when testing with that we could simulate one Outlook crash pointing to Kernelbase.dll. We now fixed this in a new patch and still awaiting results from customers, but in the meantime are there any more options to debug such a random crash? Hope anyone can help us here.
That is a widely spread problem when dealing with Office COM add-ins. The problem can be related to other add-ins, not only yours. Even to locate the source of the issue is very complicated in such cases. You can generate a dump crash and then analyze it to identify the source, but it may not help well because changes made by any add-in may not be detected following that way - the exception which could lead to the crash can be thrown by Outlook itself. For example, a badly written COM add-in may release a COM object and then finish its works, then at some point the host application detects that a required COM object is disposed and cannot continue execution, so it crashes suddenly.
To identify the source of the issue, first of all, you need to add any logging mechanisms to the add-in and see where and when the issue takes place. Then you can try to start simplifying the source code of your add-in by commenting line by line and seeing results after whether it helps or not. It also makes sense to try a newly created add-in, so it can be sure the issue comes from any other add-in, not your own code. There are a lot of helpful steps that could be made, but they depend on the specific scenario you deal with.
You can enable Outlook logs as well. Read more about that in the How to enable global and advanced logging for Microsoft Outlook article.
Try to collect a crash dump using ProcDump.exe and then open it in windbg.
Download ProcDump from
https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
and run the following from command line:
procdump.exe -e -ma -o -w outlook.exe
I have a winforms app (>75k lines of source code), I have just added some new functionality and a new form and I'm getting the 'can't create window handle' error but only when running inside VS. The app builds OK and when i run it as the executable it is using 597 handles, 94 GDI and 83 USER and the new form works just fine apart from my logic errors in it. So as far as I can tell; my app is well below the 10,000 limit where things start to break therefore the problem is in/with VS somewhere but I may have hold of entirely the wrong end of the stick or possibly completely the wrong stick.
I have cleaned, rebuilt, rebooted etc and it stills falls over.
I'm using Process Explorer (thats where the previous numbers came from) but can't seem to find VS in there to check what its total handle count is.
VS2017 on Win 11.
Yes, I have googled it and explored things to look at but I can't find a result that matches 'Studio falling over but the exe running fine', any help / pointers very much appreciated as I obviously can't debug the new form which does make things somewhat difficult.
The underlying issue was to do with a pop-up form being generated by the parent form during its load processes, I found that the parent hadn't been issued a handle before it was trying to show the pop-up. Before you ask... I'm capturing data from a network sensor via the pop-up, which, once the user has accepted the incoming value, feeds the data back to the parent form. I assume that in run-time everything runs faster and it doesn't hit that 'un-coupled' point. Changed the code in the instantiate/load/shown cycle it runs and all is well.
Thanks once again Hans, headache solved.
I made a program, which works fine on my PC without any errors, it also works fine on some office PCs, but it crashes without any describable error on customer's PC and some others.
Crashes are completely random, sometime it may crash and sometimes not.
Crashes are not related with any actions, sometimes it may crash when they just look at the program and wait for crash.
Customers send me this beautiful screens and want me to solve this.
There you see common error reporting dialog, but not info about Exception.
My program uses Unity Web Player running in WebBrowser control. It's always run in background on the hidden tab which becomes visible when needed.
Any ideas how to handle such errors?
I think you should first ensure that the environment at your place and that of your customers are identical.
Maybe there're dll or other programs installed at your place (Unity web player as you mentioned for example) or anything in your Registry that may differ.
Else there's no point in getting error on one PC and not on another.
Make sure all dll are well deployed
Check your registry,
Ensure that all related programs are well installed
I have a Silverlight project that we use internally that I wrote - and since we've not had any need to work on it, it's been a while since I've opened the project. I opened it up this morning and everything is fine in terms of building, but whenever I try to debug I get the following error:
Unable to start program "http://mymachinename/mywebsite/index.aspx"
Of course, running it in Firefox works fine but no symbols are loaded. Running without debugging still throws the same error but IE loads up anyway...
Navigating to the website in IE works fine - SL app opens up, loads data etc etc, all looks good
I've Googled this all morning (usually quite good at finding info) and been through all the questions on SO and I can't figure out what's going on - there doesn't seem to be any messages in the event log, there are no messages in any VS output window, the w3wp just terminates immediately after starting (probably due to there being an error trying to open IE). I've tried reinstalling IE, cleaning/rebuilding, using local dev server, creating a new web project, turning on/off settings in IE9 etc etc
Nothing seems to make a difference - anyone got any experiences of this and has fixed it without doing one of the things I've already done? Any other suggestions?
Thanks in advance!
UPDATE
Just to be clear in case anyone asks - I get this problem when creating a new web project - i.e. everything I said I'd tried (above) didn't change the behaviour. It showed the same error no matter what I'd done so far (that includes a NON SL web project)
I've also tried attaching the debugger to w3wp that is running (the standard IIS process) and I can't seem to get it to debug (no symbols are loading), but that might be another issue altogether. I'm going to look at that next and maybe if I figure that out it might lead to fixing this issue
UPDATE 2
Debugging in Firefox works - I attached to w3wp with no success, then realising my stupidity (SL being a client side app!) I attached to the plugin-container.exe that FF runs its plugins in. This works. I can probably do the same for IE and just attach to IE, but why won't it start up from VS?! hair pull
UPDATE 3
Just in case anyone asks, the default browser is set to IE in VS. Also I've managed to debug by attaching to IE, it just won't start IE from within VS - annoying but I can live with it for now. If anyone does have a suggestion though, feel free...
For anyone's information in case they have this same problem, it ended up being that the port I was running my site on was also running a SharePoint site!
I created a new site on port 81 and used that for dev - not sure what setting on the other site caused the issue but it ended up working on port 81.
I've never seen this issue before, and I'm not even sure if I'm posting in the correct place.
My Co-worker wrote a C# program (windows), that includes a web control. In that web control are a bunch of iFrames. Now, when the web control is populated (max 15 records), everything is fine. 99% system idle process. But once you minimize the program, boom, 99% process goes to the c# program and stays there!
If the web control is not populated. There is no issue with minimizing and maximizing the program.
There are no functions that run when the program is minimized or maximized, so there's nothing to debug...
The program is crashing on two computers, but on the rest (about 8 computers) it runs fine.
The two computers that "crash", are not very similar... so it's proving hard to find what may be causing the issue. One computer is xp, the other is windows 7, one is ie7, the other is ie8.
If anyone could point me in the right direction, or if anyone had a similar situation and has a solution, I'm all ear's and eye's!
I would attach Visual Studio to the "99% CPU" process, break all, and see what's going on in there. That's first step.
Doesn't Windows write inactive (i.e. minimised) application state to disk, to free up resources for active (non-minimised) windows?
One of the hooks / events called when you minimise the application could be causing IO hangs. You should get a diagnostics tool like Sysinternals Procmon to see if IO (or any other process) is hanging based on the minimise event.
Good luck!
Chris.
So my co-worker didn't find the thorough answer as to why it was crashing, but it was crashing due to the .net Web control. He swapped out the control for a VB6 control and it now works.