I'm having an issue with WPF's WebBrowser control. It's crashing with the titular error when I'm changing tabs - I think I know why (explained below), but I can't think of a way around it. I'm looking for either ideas on how I might reorganize the code to work correctly, or alternatives on what I'm using to achieve my goal.
The setup of the program is this: There are multiple tabs, containing Borders/Grids/etc. On one of these tabs, there is a Grid which has "Widgets", each containing a WebBrowser. These browsers are loading various locally-hosted pages with information for the user. To make the widgets look good, some code runs in the LoadCompleted event of the browser.
brow = new WebBrowser();
brow.LoadCompleted += wb_LoadCompleted;
(The wb_LoadCompleted function isn't important: the program will crash as it's being called, not during its execution.)
Also, when the user changes tabs, these Widgets have a Dispose function that's called.
brow.LoadCompleted -= wb_LoadCompleted;
brow.Source = null;
Now if the user opens the tab with these Widgets, then after the pages begin loading, but before they finish loading and call that event, the user switches tabs again, the program will crash once it attempts to call the wb_LoadCompleted event. I think this is happening because of the error described here. The handlers have been disposed because the tab changed, but the thread wants to call the handlers. In Visual Studio, if I place a break on the wb_LoadCompleted method, it'll be on that breakpoint when the error is thrown, so I think the program still knows what code it should be running, it just doesn't have permission to.
So far I've been unable to find a workaround or solution. Beyond code fix attempts, I've tried using different browser controls (Awesemonium, and a few others); while they work without this error, but they also balloon the size of our program distribution by 30 meg. That nearly doubles the size, and it's not feasible for us to do so. Any alternative browser control that works would be great, but it needs to be ~10 meg max.
I can also share some other code if you let me know what you need to see; however, I'd imagine this is more of a timing/placement/ordering issue than current code issue, if that makes sense.
e; Adding the full error text:
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in -programpath-
Additional information: The runtime has encountered a fatal error. The address of the error was at 0x6bd5e4ad, on thread 0xa54. The error code is 0x80131623. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
Related
I've got a very bizarre situation. It appears that, when I load a webpage to my browser,
multiple threads (at least 2) are starting up. The app loads and runs fine on a
Windows XP box, but when I try to run it on my Windows 8 laptop it would seem that
more than one startup event is taking place and causing all kinds of collisions. This
is happening with both Firefox and IE.
To verify this behaviour, I placed a static int within a class, checked it to see if its
value is greater than zero, throw an exception if it is, then increment the int.
Of course, the exception is thrown.
What's very weird about this is that there is no multi-threading/multi-tasking involved
within my app.
When I "touch" the DLL for the webpage (rebuild it), it renders the webpage properly,
but the source for the webpage ("right click" > "View Page Source") has the source
for the unhandled exception webpage, with the message for the exception that my code
throws when the thread count is greater than zero.
I've tried creating a new project, then linking the code to it (Add Item ... Ad As Link),
then building it. It didn't do any good.
The Win XP system has IIS 6 with .NET 4.0, and the Win 8 laptop has IIS 7 with .NET 4.0.
Language is C#.
The truth is that I'm pretty much clueless about IIS.
I hope someone smarter than I am (which isn't saying much) has an idea as to what
is going on.
It appears that, when I load a webpage to my browser, multiple threads (at least 2) are starting up
Maybe onetime initializations. I doubt that every request causes an additional two threads to stay around.
it would seem that more than one startup event is taking place
That's normal This event fires for each instance of HttpApplication being created. This is basically a design error in ASP.NET. They thought that pooling HttpApplication instances and assigning one of them for each request was a good idea. It would have been better to have a singleton per AppDomain. Write this yourself. Like that:
class MyGlobalAppState { ... }
static Lazy<MyGlobalAppState> state = new Lazy<...>(StateFactory);
Be aware, that Lazy<T> stores any exception and just rethrows it. This causes your app to be permanently broken in case StateFactory throws. It will never recover without pool restart. This is a design error in Lazy<T>. Find a way to deal with that.
but the source for the webpage ("right click" > "View Page Source") has the source for the unhandled exception webpage
Some browsers re-GET the page to view the source. This can be annoying or handy.
It is hard to tell what is causing this behavior but as others suggested try to use Fiddler or any other http tracing tool to see what requests are sent.
Also, Win XP should be running IIS5.x while Win8 should be running IIS8.
By default IIS8 AppPool should be running with the integrated pipeline, which may behave differently. I would try changing the AppPool to use the Classic pipeline to see if it makes a difference.
I am running a Coded UI test that clicks a hyperlink, for example, "Home" then goes off and does a few different things on the web page, then tries to click the exact same "Home" link and an error is thrown saying
The web page could not be accessed. If the page is refreshing, please
wait until the page refreshes and then perform actions on it.
Now I get this when I am stepping through the test, so I know at the point this link is trying to be clicked the page is not refreshing. Digging through the UITest error logs I see this line every time before the browser refresh error is thrown:
E, 6468, 13, 2013/10/18, 15:08:47.406, 271797587803, QTAgent32_40.exe,
IEDOM : EnsureValid failed for html node: A, 52
I have compared the uitest mappings for this link and the properties are all identical, also the page html is identical.
I am running in IE10, KB2879017. VS2012 4 RC.
Any idea's what's causing this to happen?
NOTE: WaitForControlReady() does nothing to stop this from happening. Also a hard coded Playback.Wait() doesn't help here either.
Failing line of code, this works the first time, but not the second time it is executed in a test.
this.UIWindow.UIDocument.UIHomeHyperlink.WaitForControlReady();
Mouse.Click(this.UIWindow.UIDocument.UIHomeHyperlink);
Remember that the search properties being used for the UIHomeHyperlink mapped control are the exact same the second time these lines are executed. Mouse.Click() execution is when the "Web page not available" error is thrown in VS2012.
After some brainstorming and trial and error testing, came to the conclusion that mapped controls are holding onto properties after being found on a page. For some reason those properties weren't matching up exactly with the page properties on the second time around.
So a "solution" to this problem was to force a new up of the entire mapped UI___Window each time we enter the page. Coded UI prevents this in the designer file by checking if the control is null every time, if it is then the control is new'ed up. If not, then Coded UI uses the same control and it's properties from when it was first defined/discovered. Hope this helps anyone else that was having problems with this error.
There also seems to be a bug in CodedUI when calling .GetParent() twice on the same object tree, which causes this exception to be thrown. We worked around it by determining the parent in another way.
On another workstation (W7) another exception was thrown when calling .GetParent() twice, something about that the IE version should be more than IE10 on 64bit versions of Windows, which was clearly nonsense, since the computer had IE11 installed.
A program I developed in Microsoft Visual Studios 2010 using c# has been generating the following error: https://dl.dropboxusercontent.com/u/19853155/code%20error%2001.jpg
I have kind of isolated the issue down to this segment of code:
if (gui.rawLogLSM.InvokeRequired)
{
gui.rawLogLSM.Invoke(new MethodInvoker(delegate
{
gui.rawLogLSM.AppendText(t.ToString());
gui.rawLogLSM.ScrollToCaret();
}));
}
else
{
gui.rawLogLSM.AppendText(t.ToString());
gui.rawLogLSM.ScrollToCaret();
}
Basically in this segment of code, I am reading raw data from a serial port, and printing it into a text box, byte by byte. (I can't read the whole buffer in at a time, as that invalidates what we're doing for the project).
I am not wholly sure how this error is actually generated or under what conditions. The error has only presented itself when a co-worker is using the application in my absence, and I've been unable to recreate the error.
The error from info from the exception comes up in form of a message box due to me having a try/catch around a larger block of code, within which the above code is apart of.
So my question is mostly, how can I solve this error or what should I be doing to force said error to show itself?
Thanks for the help!
Could it be that the invoke is on a different thread and the exception is thrown when trying to invoke the textbox while another thread has disposed the textbox(on form close maybe?)? If this is because the textbox is disposed on different thread, one solution would be to surround AppendText and ScrollToCaret inside the invoke with try/catch and swallow that specific error.
The error itself is pretty straightforward: your rich text box is being disposed before you access it. Unfortunately, these can be very nasty to track down, especially if you can't reproduce it.
Do a sanity check and make sure that the RTB is indeed created before the Append()'ing code is called, but my gut tells me you'd get constant errors if it wasn't.
To me, the first step is to reliably reproduce it. Use your coworker's machine, have them demonstrate what they were doing when the error popped up, ensure the framework and application versions are the same, etc etc.
Once you can reproduce it, you'll have to find WHERE the object is disposed. You can do it manually by right-clicking a call to the dispose and choosing "show all references". Set breakpoints on each of them, or use some other monitoring scheme (like a log, which can be used to watch programs on non-development machines). Remember that the System.Diagnostics.StackTrace class is useful for seeing what called Dispose.
There are also tools that monitor memory usage and disposal that can help you out.
I'd also recommend turning debug mode on and giving your coworker the debug-enabled executable and the symbol file (pdb) as this may help track the problem.
Other things to check are race conditions, simultaneous/cross-thread access, exceptions in other threads that may be swallowed by the CLR, only to fudge up your code later on, and make sure you end all threads before you close your form. If you don't, weird stuff can happen. At best, your program will continue to hang in memory, invisible to all but task manager. Worse, you can pop up random error dialogs "out of the blue" as something finally fails. In your case, it might be failing immediately.
I am developing a C# application in Visual Studio 2008 that uses folder browser dialog and printdialog. Lately the program is encountering an error whenever ShowDialog() Method for these two dialog boxes is called.
The error says:
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
The strange thing is that this error is specific to this project only. When I use folder browser dialog in a new C# project it works perfectly fine. Moreover this error started occurring recently in the mentioned project. Earlier it used to work perfectly fine. Also, this error does not occur when I run the program from the IDE in debugging mode.
There is a suggestion in some other question on Stack Overflow to uncheck "Suppress JIT optimization on module load" in debugging options. I have tried that too but that did not solve my problem.
Can someone please help me solve this problem?
It's difficult to say what without seeing any code. I've seen running into this issue with accessing UI on threads other than it was created. To avoid it, if you're messing with UI controls from some thread, you can create a function like the following
public static void ExecuteAction(Control myControl, Action myAction)
{
if (myControl.InvokeRequired) { myControl.Invoke(myAction); }
else { myAction(); }
}
Then you just call that from whatever thread you want with the control and the action you want to do (say, change its color or what).
I haven't seen the issue with Dialogs specifically since I haven't done anything with them in a long time, but since it's a UI issue, and it's the same error message I've seen before, I'd give it a shot.
You might also check the value of Control.CheckForIllegalCrossThreadCalls. http://msdn.microsoft.com/en-us/library/system.windows.forms.control.checkforillegalcrossthreadcalls.aspx
I have a web application I am developing that seems to crash completely at random when clicking links on any page. When this happens, I'm told 'An unhandled win32 exception occured in iexplore.exe'. When I try to debug, it says one is already attached.
What could this be relating to? I know without code it will be hard, but this seems like a very strange error to occur at random.
I have had this happen to me before and the problem usually had to do with styling on html elements that IE just couldn't handle. A good test would be to run the app in Mozilla and Chrome to see if they crash. For me, 4/5 times it had to do with the overflow attribute on a div. For some reason, ie is quirky when it comes to scrolling. To find it, after you have tested in the other browsers, start taking blocks out one piece at a time and see if you get the error. If you don't get the error, then the problem is in that block, otherwise put it back in and take the next block out. Keep going until you find it.