I have a simple Winforms application.
I've added a ChromiumWebBrowser control on my Form and I'm navigating on various pages.
For unknown reasons, an exception is thrown from Chromium which causes my app to crash
CefSharp.BrowserSubprocess.exe Description: The process was terminated
due to an unhandled exception.)
Is there a way for me to somehow handle that error so my app doesn't crash?
(and maybe reload the current page)
Related
I have built the IL Rewriter to monitor any file is being opened in ASP.Net WebApp. To do so, I am rewriting IL for a private method called 'Init' in FileStream class in mscorlib. Here, I inject the epilogue/prologue to register a custom callback.
Injection is working fine. Custom callbacks are also getting called whenever a file is getting opened in Windows Application.
But, when I do the same for ASP.Net web application, it keeps crashing with the following error -
System.ExecutionEngineException was unhandled
Message: An unhandled exception of type 'System.ExecutionEngineException' occurred in System.Web.dll
I don't understand if it is working fine with .Net-based Desktop Application, then why it does not work with .Net-based web application i.e. ASP.Net. What is the difference between Web and desktop application?
Googled for above error does not yield any solution :(
I have one problem which I am not able to understand.
There are some unhandled exception in my asp.net application which I believe setting some of static variable in my class to null.
I believe this is because unhandled exception is recycling the application pool.
If I use Apllication_Error in global.asax , will that stop recycling of app pool?
If I use Application_Error in global.asax , will that stop recycling
of app pool?
No, Application_Error might or might not even be reached, if Application Pool recycles due to hard crash.
It seems that you do not have any logging framework in your application. One thing you can do at this point is to see the errors in Event Viewer.
For example,
FYI: To view friendly error messages, you might want to add error logging to your application such as NLog, Log4Net or Elmah.
I develop and debug an ASP.NET application with VS 2010. My ASP.NET application holds some connections to other applications on other machines. When I stop debugging, I want these connections to be released. If this doesn't happen, these other applications fail and I have to restart them.
In the end I will store my termination code in the Application_End method in Global.asax.cs, but this one is not called when stopping debugging.
Is there a way to terminate the debugging of my ASP.NET application so that not everything is killed at once, but so that one last method is called in which I could add my termination code?
I'm not sure what your problem is but probably...
You initialize your debug session by pressing F5 and thus debugging through cassini. This way when you end your debug session the application is terminated.
If you have a configured IIS application you could simply attach to the running process - it's usually "CTRL + ALT + P" - choosing w3wp.exe (mind the checkboxes on the bottom to be checked). This way your app won't be terminated on ending the debugging session.
Does it solve your problem?
I misunderstood how debugging an ASP.NET application works. I thought the moment I stop debugging (by pressing Shift+F5) the ASP.NET application is terminated and no further line of code is executed. It was my explanation to why the Application_End method is not called.
But in fact the ASP.NET application goes on when the debugger is detached and therefore the Application_End method is not called.
I have site that is hosted on the window server 2008 R2 with IIS7 since last 2 years now it suddenly start giving error: The compiler failed with error code -1073741502 at clicking for any page on menu bar. However before this login page is running normally.
Event log error for this shows error code 3007 i.e. External Component has thrown exception in the eventlog viewer - but this site was working fine from last few months so how it can give exception for external component now.
There may be application pool issue - with this site
Currently I am using 'local system' as application pool as database is placed on the same the server.
Please suggest how to overcome this problem. May be some tips regarding setting of application pool can help me.
Thanks
When debugging an application in Visual Studio, there are 2 options for breaking on exceptions. Break as soon as an exception is thrown, and breaking only when an exception isn't caught. This works fine when developing desktop applications. However, when developing ASP.NET applications, all exceptions are eventually caught by the code in IIS. Is it possible to disable this behavior, so that the debugger breaks when my ASP.Net application code fails to catch an exception?
Edit:
Just to be clear, I don't want to break whenever an exception is thrown, as many times they are handled just fine by my code, and I don't want to stop on every exception. I only want to stop on the exceptions that aren't handled by my code.
Edit:
This seems to not be an issue in Visual Studio 2008. In Visual Studio 2003, all exceptions were treated as user handled, because the ASP.NET runtime caught all the exceptions so as not to bring down the web server process. It seems that in Visual Studio 2008, this type of exception catching is not counted when checking for user-unhandled exceptions.
Under Debug->Exceptions, check the 'Thrown' column of Common Language Runtime Exceptions (at a minimum). Check 'Thrown' for other Exceptions you're interested in.
Now, if the debugger is attached (active debug or 'Attach to Process'), your ASP.NET app will break on a CLR Exception (or any other Exception you've selected).
[EDIT]
If you want to break only on unhandled Exceptions, under Debug->Exceptions, uncheck 'Thrown' on all Exception types and make sure 'User-unhandled' is checked for the Exceptions you're interested in.
Then, if the debugger is attached, your ASP.NET app will break on every User-unhandled Exception you've selected regardless of the fact the runtime will eventually catch the Exception. Sample: