I have had a few reports of a message box showing up on application launch with the following contents:
[Arg_NullReferenceException]
Arguments:
Debugging resource strings are unavailable. Often the key and arguments provide
sufficient information to diagnose the problem. See http://go.microsoft...
I understand the link provided gives me the exception detail, and I obviously have a null ref somewhere. I haven't been able to reproduce this, so I am trying to find where this message is being thrown and hopefully add some error handling.
Is this specific message box something baked into Silverlight, or is it following whatever exception handling is in place when such an exception occurs? In the app constructor, I have
this.UnhandledException += this.Application_UnhandledException;
which is:
private void Application_UnhandledException(object sender,
ApplicationUnhandledExceptionEventArgs e)
{
MessageBox.Show(e.ExceptionObject.Message + "\n" + e.ExceptionObject.StackTrace);
}
So it looks like this message box is not coming from the Application_UnhandledException or it would have a message, newline, then a stack trace. So now my two options for how this message box is being generated are: 1) Silverlight is doing it in the background, or 2) this is coming from an existing catch block, although I have found none that would display in this way.
I'm doing offline caching of XAPs in Isolated Storage using OfflineCatalog, which involves some asynchronous WebClient downloads and fall-backs to Isolated Storage when requests fail. It makes sense that a null ref might be happening somewhere in this process.
To summarize, I'm wanting to add some exception handling for this Null Reference, but cannot reproduce it locally, and cannot find where it may be coming from. If this is coming from an unhandled exception, why does it not display the message and stack trace as specified?
The error message occurs if the machine does not have Silverlight SDK installed normally.
To debug similar browser side exceptions, it is common practice to use Visual Studio. If you cannot use VS, simply use WinDbg to attach to the browser process.
Related
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.
I have "trace" on but do not get a "stack trace" for this error in my Asp.Net development project. On other errors I have seen stack traces, but my question is why don't I see one now?
This is about a DevExpress gridview. Could it be that DevExpress errors are handled differently from plain Asp.Net code?
I have set breakpoints on all sorts of interesting places but no avail. Perhaps there are errors that are not associated with stack traces?
I tried with Firefox and IE browsers.
Kind of stuck, hope this to be a silly problem.
From: ASPxGridView - Object reference not set to an instance of an object
This issue is caused by the fact that some object reference equals "null". I suggest that you determine the problematic reference in the following manner:
Disable ASPxGridView's callbacks by setting the ASPxGridView.EnableCallBacks property to "false";
Perform the required steps to reproduce the issue.
You will receive the Server Error screen with information about the exception that has been thrown (and the problematic reference/code line).
If this does not help, please provide us with a sample working project (containing only the problematic ASPxGridView bound to any portable datasource) that illustrates the issue, so that we can examine it on our side under the same conditions.
Also, the exception you see is raised in server code and to be able to
catch it, please adjust the VS as shown below:
Go to the Debug-->Exceptions dialog and check the Common Language Runtime Exceptions and check the check box in the Thrown column;
Go to the Tools-->Options-->Debugging and uncheck the Enable Just My Code (Managed Only) check box.
After doing these all stuff, you are not able to get the error then provide your markup to check what is actual problem..
In case you're using Visual Studio, have you checked Debug -> Exceptions -> Common Language Runtime Exceptions checkbox ?
you may use try catch block in your code to get the location where the code is breaking else set the Common Language runtime thrown to true in exception window(to open this window press ALT +CTRL+E)
I've created a number of Silverlight applications used in various MS systems, from CRM 2011 to SharePoint.
The applications aren't perfect, and I'll be the first to admit it, and sometimes things go wrong. All my applications already display what went wrong:
private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
{
(...)
UIDispatcher.Invoke(() => ARP.DynamicsCRM2011.Silverlight.GlobalHelper.Controls.MessageWindow.ShowMessage(e.ExceptionObject.Message));
(...)
}
HOWEVER, almost always, the end user will NOT have the Silverlight developer SDK installed, and will, subsequently, only receive a generic "Debugging Resource strings are unavailable" message.
The message will usually contain some very basic form of the exception that occurred, but it's hardly ideal. I also know I'm missing a proper stack trace from the error (this is, of course, easy to fix).
I'm thinking of rewriting that exception handling code to show a generic "something went wrong, please try again message", and an extra "show log" button to display all the exception information along with the stack trace.
My question, however, is... how should I deal with those missing resource strings? If something goes wrong, I would like to get as much information as possible, but I cannot require my users to all install developer SDKs.
What's the best course of action in this situation?
I don't know if this is an option for you but you could log those info in database or in a local file that you could retrieve in case of error. But I don't kow if this is something you can consider (ex: application are for your compagnie but not public,etc.)
While testing an ASP.NET application with perfmon, we find that the following field is non-zero:
ASP.NET Apps v2.0.50727 > Errors During Preprocessing
Documentation says that this field is "The number of errors that occurred during parsing, excluding compilation and run-time errors."
However, I have not been able to track down why this is happening.
Any clues on where these actual preprocessing errors are logged? Or how to enable logging so we can fix these errors?
One thing I would try is to precompile your application from the command line using aspnet_compiler. e.g. from a VS command window, try something like:
aspnet_compiler -v / -p c:\PathToYourAppRoot
At runtime, there is some fallback behavior which may mask some errors. But when running aspnet_compiler, it should be catching and displaying any error that it encounters.
If that doesn't help, another thing you can try to isolate the issue is figure out after what specific http request the counter goes up. e.g. does it go up as soon as you send the first request, or only after hitting specific URLs?
Check your event viewer. They should be showing up there. You may also want to look at the link below for info on how to send the event logs to other places (db, email, etc...)
http://www.asp.net/(S(sf10gzjodvrpce55el2p5cnk))/learn/hosting/tutorial-13-cs.aspx
I am using this - otherwise excellent - vb tab control in one of my c# apps. When the app using it is installed on another machine, Windows tells the user in its usual friendly and descriptive manner that "The application encountered a problem and needs to close". I guess the control has some hidden vb-related dependency, but what can that be?
Any ideas guys?
Since the tab control appears to be managed code as well, your 'crash' is most likely an unhandled .NET exception.
Looking at the error details (by expanding the error dialog using the button provided for that purpose...) should give you the exception message, which should give you an idea of what's going on. If it's a missing dependency DLL, the name should be included in the message.
To get the full exception, including the stack trace, one of the following should work:
Least effort: in the first line of your own managed code, add an unhandled exception handler which shows the full exception in a message box or logs it to a file prior to rethrowing it
Medium effort: attach a debugger to the process on the client machine. If it's on your local network, setting up remote debugging should be trivial, and should also allow you to debug exceptions that occur prior to your first line of code executing (which may very well be the case if the error is binding-related...)
Most effort: obtain the crash dump file from the client machine, and look at the managed exception using Windbg and the SOS debugging extensions. Getting productive with the tools involved will take some time, but on the plus side will teach you valuable debug ninja skills that will allow you to tackle pretty much any 'mysterious crash'...
BTW, all standard 'VB dependencies' are part of the default .NET Framework install, so that's not your problem -- only the exact exception (and possibly stack trace) will tell you what's going on.
Click the 'What data does this error report contain?' button and there will be more descriptive info. (i.e. type of the thrown exception, module etc.).
For additional info see Dr. Watson vs. CLR.
Is the dll containing the control distributed with your app? Perhaps you have a dependancy in the GAC thay you are missing?