Forcing an app to close when getting error 0xc0000005 - c#

I have a C# WPF app that display an error dialog with the error code 0xc0000005. I researched this error code and found that it is a access violation error and could be caused by several things including native code errors (p/invoke and 3rd party dlls). Restarting the app seems to clear the error but I want to be able to force the app to close when that error occurs. Since it is not a managed code exception it is not caught in the try catch blocks, is there any way to force the app to close when this error occurs?

You can catch native exceptions in different way. Either using Win32Exception or SEHException exception class or using catch without any exception type specified as
try
{}
catch
{}
Refer this for details: Can you catch a native exception in C# code?
Use Environment.Exit(0); to terminate your application.

Related

LibreOffice Stopped working , while converting XLS to XHTML files using C# application

In this, my queries are,
How to handle LibreOffice Exceptions in C#.
If could not handle , how to pro-grammatically close this exception or to suppress this exception popup, while excuting console
OR any better solution, that my conversion process , should not stop because of unhandle exception caused by Libre Office.
From the image, it looks like the exception got thrown from storeToUrl() in the code at https://github.com/caolanm/unoconv/blob/master/unoconv.
unoconv is a command line tool, not a library, so it does not seem possible to catch the error with a try/catch block. Perhaps you could capture the process's error stream and parse it to see if an exception occurred.
Instead of using unoconv, it may be better to call storeToUrl() directly in C# using the UNO API, with a try/catch for com.sun.star.io.IOException.
When doing many automated conversions with LibreOffice, it is typically necessary to kill the process whenever it gets stuck: https://github.com/dagwieers/unoconv/issues/352.
Firstly, thank you all for your kind help.. :). Finally i resolved.
While bulk file conversion , my c# process, was getting interrupted , because of some exception occurred in LibreOffice process(soffice). so i started killing my c# process and its child processes and also killed soffice. So for next file, fresh soffice is getting created , as i executed unoconv command.
but still, i get the exception popup, but the c# process , keeps continue..
this code helped me

Catching missing DLL in XamlParseException

I have quite an unusual problem where if there is a missing DLL on the client machine, the application will freeze and display the standard "The application is not responding". However, as I know what the issue is, I'd like to find a way to catch this exception (Missing DLL) and display the message in a dialog displaying meaningful information to help identify which DLL is missing. This will allow the application to have a more graceful death.
Upon debugging on the client machine, I receive the error:
A first chance exception of type 'System.Windows.Markup.XamlParseException' occurred in PresentationFramework.dll
Additional information: Could not load file or assembly 'Some.DLL' or one of its dependencies. The system cannot find the file specified.
In release however, the application crashes and is not responding.
Looking at the documentation for this error, a XamlParseException usually occurs inside the InitializeComponent(); method:
For pages of an application, when the XamlParseException is thrown, it is usually in the context of the InitializeComponent call made by your page class, which is the entry point for the WPF application model's usage of the WPF XAML parser at the per-page level. Therefore another possible handling strategy is to place try/catch blocks in InitializeComponent. However, this technique does not integrate well with templates, visual design surfaces and other generated sources that hook up InitializeComponent.
So, I can do something like this:
public MyView()
{
try
{
InitializeComponent();
}
catch (XamlParseException ex)
{
//Do something useful with the error.
}
}
This is certainly possible, however it would require using this code in practically all controls, which is obviously ridiculous. Not to mention that it doesn't really solve the issue of a missing DLL.
So, my questions are:
Is it possible to trap a missing DLL and display a message containing the name of said DLL?
Is there a more elegant way of catching a XamlParseException?
Thanks.
Yes, it is certainly possible.
To do this, you will need to override what happens when the application first starts up.
Open your Application.xaml.vb, and add the following code:
protected override void OnStartup(StartupEventArgs e)
{
// add an event handler for the UnhandledException event
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(HandleException);
// start up the application
base.OnStartup(e);
}
// what to do when the exception is thrown
void HandleException(object sender, UnhandledExceptionEventArgs e)
{
// do something with the exception
MessageBox.Show(e.ExceptionObject.ToString());
}
The output from the e.ExceptionObject.ToString() contains the problem. In the case you describe, there will probably be nested exceptions, the inner one stating : System.IO.FileNotFoundException: Could not load file or assembly '{missing DLL name here}' or one of its dependencies. The system cannot find the file specified. at {Project}.{where the error was thrown}

WebDriverBackedSelenium Wait Time Out Was unhandled.

webdriverbackedselenium throwing unhandled exception when use WaitForPageToLoad(timeout);
Even i have try catch
try
{
selenium.WaitForPageToLoad(timeout);
}
catch
{
}
Catching its exception, but when it comes out of catch, showing this image
Tried many solutions but didn't succeeded , please advise what should i Do.
Thank you.
You may configure the Exception Assistant dialog in the way to receive or not receive the exception even if you have the catch block. The solution in the Exceptions configuration you have. Please see it under Debug->Exceptions menu. If the exception checkbox is checked you will receive the Exception Assistant dialog (under debug!) even you have the catch block in your code.
Please see more details and pictures here

Unhandled exception swallowed (except in debugger)

I'm maintaining a legacy C# Winform application, using .NET 4.0 framework. The application works fine, but occasionally due to bugs in the application, the application will fail to work properly when the the application creates invalid data in the database.
At certain points, we bind the (invalid/corrupt) data to a datagrid, which causes numerous errors when it attempts to map a null column to a datagrid column.
An exception of type 'System.InvalidCastException' occurred in mscorlib.dll but was not handled in user code
Additional information: Object cannot be cast from DBNull to other types.
As well as
An exception of type 'System.Reflection.TargetInvocationException' occurred in System.Windows.Forms.dll but was not handled in user code
The errors cause a nice popup to show when run under the Visual Studio debugger detailing the error as well as allowing me to see the line where the error occurred.
In this particular case, I know what the issue is, so I can easily correct it. However, this class of error occurs too-often in other parts of the application, so it's not always obvious what is happening, and my users don't always provide good error reports. To try and combat this, I'd like to add logging to the application (using log4net), which works in our situation as each user has their own copy of the application so I can obtain per-user logs after the fact.
Using hints from stackoverflow as well as various other sources, I found a lot of good information on setting up handlers for these unhandled exceptions. Unfortunately, my handlers are not being called for the majority of the 'unhandled' exceptions.
The mostly relevant parts of the application are below:
static class Program {
private static readonly ILog log = LogManager.GetLogger("Main");
static void Main() {
// Add some error handlers which log error data to the logfile
//
// For UI events (set the unhandled exception mode to force all Windows Forms
// errors to go through our handler)
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
Application.ThreadException += new ThreadExceptionEventHandler(delegate(object s, ThreadExceptionEventArgs e) {
ExceptionLogger(e.Exception);
});
// Non-UI thread exceptions
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(delegate(object sender, UnhandledExceptionEventArgs e) {
ExceptionLogger(e.ExceptionObject as Exception);
});
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
log.Debug("Starting Application");
Application.Run(mainForm = new MainForm());
}
private static void ExceptionLogger(Exception e) {
log.Error("Unhandled Error", e);
string errorMsg = "An application error occurred. Please contact the administrator with the following information:\n\n";
errorMsg = errorMsg + e.Message + "\n\nStack Trace:\n" + e.StackTrace;
if (MessageBox.Show(errorMsg, "TLMS Error", MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop) == DialogResult.Abort)
Application.Exit();
}
The Exception handler seems to work if the errors occur directly in my own code, but the handler is not called if/when the errors occur directly in the .NET libraries, and I want the handler called for all Unhandled exceptions, including those outside of code I've written.
Being able to use the debugger to track down the errors is invaluable if I can recreate the exact users steps within the debugger after the fact. However, at no point is ExceptionLogger being called, either running standalone or inside the debugger, and there is no visual indication that any error occurred. Because the exceptions are being suppressed, the users sometimes don't realize until much too late that everything they've done is completely screwed up and the data is even more corrupt.
The application platform is being built and run on x86 (apparently exceptions can be lost if run on x64), and the application has been tested on both 64-bit and 32-bit platforms with no change in behavior.
So you only see "but was not handled" when the app runs in the debugger. When it runs outside the debugger exceptions are suppressed. If I've got this correct then I still think the app handles the exceptions, because the debugger changes app behaviour sometimes.
I confirmed that InvalidCastException is one of a group of exceptions that .NET 4+ handles differently if the exception context is unmanaged code. An app can override this special handling (see All about Corrupted State Exceptions in .NET 4), but the debugger may ignore the override. There are lots of web resources on this, see also one in MSDN Magazine.
EDIT: If your app users have .NET 3.5 or below installed then the app need not apply the override described in the resources above.

Help with debugging COM errors? (.mdi to .pdf file conversions using Microsoft Office Document Imaging)

I thought I had a working solution for converting .mdi files to PDF using the Microsoft Office Document Imaging object model. The solution is in a Windows Service, but now I'm running into some errors that I'm having trouble tracking down info on.
The exception I get is:
The server threw an exception.
(Exception from HRESULT: 0x80010105
(RPC_E_SERVERFAULT))
System.Runtime.InteropServices.COMException
(0x80010105): The server threw an
exception. (Exception from HRESULT:
0x80010105 (RPC_E_SERVERFAULT))
at MODI.DocumentClass.Create(String FileOpen)
at DocumentStore.Mdi2PDF(String path, String newPath)
Then, in the Event Viewer there is the following Application error:
Faulting application
MyWindowsServiceName.exe, version
1.0.0.0, time stamp 0x4b97f185, faulting module mso.dll, version
12.0.6425.1000, time stamp 0x49d65443, exception code 0xc0000005, fault
offset 0x0000bd8e, process id 0xa5c, application start time
0x01cac08cf032914b.
Here's the method that is doing the conversion:
private int? Mdi2PDF(String path, String newPath)
{
int? pageCount = null;
string tmpTif = Path.GetTempFileName();
MODI.Document mdiDoc = new MODI.Document();
mdiDoc.Create(path);
mdiDoc.SaveAs(tmpTif,
MODI.MiFILE_FORMAT.miFILE_FORMAT_TIFF_LOSSLESS,
MODI.MiCOMP_LEVEL.miCOMP_LEVEL_HIGH);
mdiDoc.Close(false);
pageCount = Tiff2PDF(tmpTif, newPath);
if (File.Exists(tmpTif))
File.Delete(tmpTif);
return pageCount;
}
I removed all threading from the service invoking this, so that only the primary thread was initializing the MODI object, but still got the error, so it doesn't appear to be threading related.
I also built a a console apps converting hundreds of documents and DID NOT get the exception.
So, it seems to be caused by creating too many instances of the MODI object, but only instantiated within a Service? Doesn't quite make sense.
Anybody have any clues about these errors and how to debug them further?
There's something interesting here about closing the COMObject after its use or something like that. This might perhaps help, I hope it does.
COMException 0x80010105
Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))
It seems to have something related to disposing objects, either an object disposed too early, or not disposed at all.
Have your ever tried to call the Garbage Collector once in a while throughout your callings to the COM object methods?
I don't know, I'm throwing up everything that gets to my mind, perhaps will it make it end as a solution somewhere! =)
It crashed. It's a dead parrot. An AccessViolation hardware exception, in an Office DLL (mso.dll). You have few options to figure out why exactly it crashed, this is not your code. But using threading is definitely a good way to crash a COM server that's single-threaded. Any kind of Office code would qualify. Get rid of the threading first, then call Microsoft Support.

Categories

Resources