When I create a new project, I get a strange behavior for unhandled exceptions. This is how I can reproduce the problem:
1) create a new Windows Forms Application (C#, .NET Framework 4, VS2010)
2) add the following code to the Form1_Load handler:
int vara = 5, varb = 0;
int varc = vara / varb;
int vard = 7;
I would expect that VS breaks and shows an unhandled exception message at the second line. However, what happens is that the third line is just skipped without any message and the application keeps running.
I don't have this problem with my existing C# projects. So I guess that my new projects are created with some strange default settings.
Does anyone have an idea what's wrong with my project???
I tried checking the boxes in Debug->Exceptions. But then executions breaks even if I handle the exception in a try-catch block; which is also not what I want. If I remember correctly, there was a column called "unhandled exceptions" or something like this in this dialog box, which would do excatly what I want. But in my projects there is only one column ("Thrown").
This is a nasty problem induced by the wow64 emulation layer that allows 32-bit code to run on the 64-bit version of Windows 7. It swallows exceptions in the code that runs in response to a notification generated by the 64-bit window manager, like the Load event. Preventing the debugger from seeing it and stepping in. This problem is hard to fix, the Windows and DevDiv groups at Microsoft are pointing fingers back and forth. DevDiv can't do anything about it, Windows thinks it is the correct and documented behavior, mysterious as that sounds.
It is certainly documented but just about nobody understands the consequences or thinks it is reasonable behavior. Especially not when the window procedure is hidden from view of course, like it is in any project that uses wrapper classes to hide the window plumbing. Like any Winforms, WPF or MFC app. Underlying issue is Microsoft could not figure out how to flow exceptions from 32-bit code back to the 64-bit code that triggered the notification back to 32-bit code that tries to handle or debug the exception.
It is only a problem with a debugger attached, your code will bomb as usual without one.
Project > Properties > Build tab > Platform target = AnyCPU and untick Prefer 32-bit. Your app will now run as a 64-bit process, eliminating the wow64 failure mode. Some consequences, it disables Edit + Continue for VS versions prior to VS2013 and might not always be possible when you have a dependency on 32-bit code.
Other possible workarounds:
Debug > Exceptions > tick the Thrown box for CLR exceptions to force the debugger to stop at the line of code that throws the exception.
Write try/catch in the Load event handler and failfast in the catch block.
Use Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException) in the Main() method so that the exception trap in the message loop isn't disabled in debug mode. This however makes all unhandled exceptions hard to debug, the ThreadException event is pretty useless.
Consider if your code really belongs in the Load event handler. It is very rare to need it, it is however very popular in VB.NET and a swan song because it is the default event and a double-click trivially adds the event handler. You only ever really need Load when you are interested in the actual window size after user preferences and autoscaling is applied. Everything else belongs in the constructor.
Update to Windows 8 or later, they have this wow64 problem solved.
In my experience, I only see this issue when I'm running with a debugger attached. The application behaves the same when run standalone: the exception is not swallowed.
With the introduction of KB976038, you can make this work as you'd expect again. I never installed the hotfix, so I'm assuming it came as part of Win7 SP1.
This was mentioned in this post:
The case of the disappearing OnLoad exception – user-mode callback exceptions in x64
Here's some code that will enable the hotfix:
public static class Kernel32
{
public const uint PROCESS_CALLBACK_FILTER_ENABLED = 0x1;
[DllImport("Kernel32.dll")]
public static extern bool SetProcessUserModeExceptionPolicy(UInt32 dwFlags);
[DllImport("Kernel32.dll")]
public static extern bool GetProcessUserModeExceptionPolicy(out UInt32 lpFlags);
public static void DisableUMCallbackFilter() {
uint flags;
GetProcessUserModeExceptionPolicy(out flags);
flags &= ~PROCESS_CALLBACK_FILTER_ENABLED;
SetProcessUserModeExceptionPolicy(flags);
}
}
Call it at the beginning of your application:
[STAThread]
static void Main()
{
Kernel32.DisableUMCallbackFilter();
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
I've confirmed (with the the simple example shown below) that this works, just as you'd expect.
protected override void OnLoad(EventArgs e) {
throw new Exception("BOOM"); // This will now get caught.
}
So, what I don't understand, is why it was previously impossible for the debugger to handle crossing kernel-mode stack frames, but with this hotfix, they somehow figured it out.
As Hans mentions, compile the application and run the exe without a debugger attached.
For me the problem was changing a Class property name that a BindingSource control was bound to. Running without the IDE I was able to see the error:
Cannot bind to the property or column SendWithoutProofReading on the
DataSource. Parameter name: dataMember
Fixing the BindingSource control to bind to the updated property name resolved the problem:
I'm using WPF and ran into this same problem. I had tried Hans 1-3 suggestions already, but didn't like them because studio wouldn't stop at where the error was (so I couldn't view my variables and see what was the problem).
So I tried Hans' 4th suggestion. I was suprised at how much of my code could be moved to the MainWindow constructor without any issue. Not sure why I got in the habit of putting so much logic in the Load event, but apparently much of it can be done in the ctor.
However, this had the same problem as 1-3. Errors that occur during the ctor for WPF get wrapped into a generic Xaml exception. (an inner exception has the real error, but again I wanted studio to just break at the actual trouble spot).
What ended up working for me was to create a thread, sleep 50ms, dispatch back to main thread and do what I need...
void Window_Loaded(object sender, RoutedEventArgs e)
{
new Thread(() =>
{
Thread.Sleep(50);
CrossThread(() => { OnWindowLoaded(); });
}).Start();
}
void CrossThread(Action a)
{
this.Dispatcher.BeginInvoke(a);
}
void OnWindowLoaded()
{
...do my thing...
This way studio would break right where an uncaught exception occurs.
A simple work-around could be if you can move your init code to another event like as Form_Shown which called later than Form_Load, and use a flag to run startup code at first form shown:
bool firstLoad = true; //flag to detect first form_shown
private void Form1_Load(object sender, EventArgs e)
{
//firstLoad = true;
//dowork(); //not execute initialization code here (postpone it to form_shown)
}
private void Form1_Shown(object sender, EventArgs e)
{
if (firstLoad) //simulate Form-Load
{
firstLoad = false;
dowork();
}
}
void dowork()
{
var f = File.OpenRead(#"D:\NoSuchFile756.123"); //this cause an exception!
}
Related
I am writing a UWP app with extensive use of Win2D APIs.
Sometimes, with no defined pattern, nor possibility to reproduce the behavior systematically, an un-caught exception of type System.Exception {System.Runtime.InteropServices.COMException} is raised by the framework, with no stack trace and only the following message:
Error HRESULT E_FAIL has been returned from a call to a COM component.
and a slightly more useful description
Objects used together must be created from the same factory instance.
Since there is no stack trace, I am not able to understand what is the cause of such exception, nor the piece of code that produces it.
According to the description, I tried to use a single factory for every Win2D operation, and specifically, I collected into 3 public static variables the factories I use:
public static class Win2DUtils
{
public static readonly Compositor Compositor = Window.Current.Compositor;
public static readonly CanvasDevice CanvasDev = CanvasDevice.GetSharedDevice();
public static readonly CompositionGraphicsDevice GraphicsDevice = CanvasComposition.CreateCompositionGraphicsDevice(Compositor, CanvasDev);
}
Even with this escamotage, I am still experiencing the issue.
I also tried in Visual Studio to flag all the possible Exception to stop the execution when they are raised, but if with this setting the Exception is completely un-caught, and can only be perceived thanks to the builtin exception handling of Visual Studio in Debug mode (the code in App.g.i.cs that is automatically added by the scaffolding of Visual Studio in every UWP project, something like:
#if DEBUG && !DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION
UnhandledException += (sender, e) =>
{
if (global::System.Diagnostics.Debugger.IsAttached) global::System.Diagnostics.Debugger.Break();
};
#endif
Is anybody aware of what could be the possible cause and at least how to catch the source of the exception?
Thank you very much
cghersi
I had similar error, but it crash only on some devices(all of them was with Intel HD Graphics). The reason was I forgot to remove CanvasDevice.DebugLevel = CanvasDebugLevel.Information;
if (CanvasDevice != null)
{
CanvasDevice.DeviceLost -= CanvasDeviceOnDeviceLost;
}
CanvasDevice.DebugLevel = CanvasDebugLevel.Information;//Remove this on release. On some devices cause app crash
CanvasDevice = CanvasDevice.GetSharedDevice();
//error:Canvas.GetSharedDevice Error HRESULT E_FAIL has been returned from a call to a COM component.
I finally solved the issue (apparently) so I post for anybody else that hits the same problem.
In our code we are instantiating a CanvasAnimatedControl to draw some ink.
By default, the public parameter-less constructor of CanvasAnimatedControl sets the flag UseSharedDevice to false, which allows the CanvasAnimatedControl to create its own CanvasDevice.
Creating the canvas as:
aniCanvas = new CanvasAnimatedControl()
{
UseSharedDevice = true
};
solved the problem and the exception doesn't show up anymore.
In LINQPad, Debug.Assert() and Trace.Assert() from the System.Diagnostics namespace don't work as expected.
Instead of breaking - i.e. popping up a message box or whatever else happens to be configured for <trace> - they simply print "Fail:" or "Fehler:" to the output window and let the program continue on its merry way. In other words, instead of a noisy, unignorable explosion there are only near invisible micro-farts that intersperse "Fail:" into the textual output.
Is there any way of getting Assert() to revert to the default behaviour under LINQPad?
Alternatively, is there a simple way of mocking a Trace.Assert() so that failure results in a noisy explosion (i.e. exception, message box, whatever) and the source of the failure is pinpointed in the form of a line number or similar?
My unit tests are based on Trace.Assert(), which makes them totally useless if the function cannot break the program at the point of failure.
In Visual Studio everything works normally but not in LINQPad. I haven't fiddled with any system-wide settings but I did install Mono at some point in time. I went through all settings in LINQPad with a fine comb but to no avail. The LINQPad version is 4.57.02 (non-free), running on Windows 7 Pro (German) and Windows 8.1 Pro (English).
I googled high and wide but the only thing I could find is the topic Trace.Assert not breaking, neither showing the message box here on Stack Overflow. Its title certainly looks promising but the answers therein don't.
P.S.: I tried mocking by adding
class Trace
{
public static void Assert (bool condition)
{
if (!condition)
throw new Exception("FAIL!");
}
}
to the LINQ script and setting a breakpoint on the throw statement. Clicking on the relevant call stack entry in LINQPad's debugger takes me to the relevant source line, so this sort of works. However, I couldn't find an equivalent to FoxPro's SET DEBUG ON for invoking the debugger directly from the source code instead of having to set a breakpoint on the throw...
To answer the second half of your question, i.e., how do you get the LINQPad debugger to break when an exception is thrown, the answer is to click either of the 'Bug' icons on the toolbar.
Click Break when exception is unhandled (red bug) to make your query break whenever an unhandled exception is thrown.
Click Break when exception is thrown (blue bug) to make your query break whenever an exception is thrown, whether or not it is handled.
You can get LINQPad to make either setting the default by right-clicking and choosing Set as default. (Doing so forces the debugger to always attach to your queries, which incurs a small performance cost.)
As to why Debug.Assert(false) doesn't display a dialog, this is because this behavior hasn't been implemented in LINQPad. You could implement this easily as an extension, by adding the following code to My Extensions:
public class NoisyTracer : TextWriterTraceListener
{
public static void Install()
{
Trace.Listeners.Clear();
Trace.Listeners.Add (new NoisyTracer (Console.Out));
}
public NoisyTracer (TextWriter writer) : base (writer) { }
public override void Fail (string message, string detailMessage)
{
base.Fail (message, detailMessage);
throw new Exception ("Trace failure: " + message);
}
}
Then, to enable, write your query as follows:
NoisyTracer.Install();
Debug.Assert (false);
Here's a strange issue I'm facing with a Windows 8.1 XAML application.
A bug in DevExpress controls causes the entire application to crash, despite my implementation of exception handling. DevExpress developers have replicated this particular bug and are working on a solution - this question is about the crash despite error handling and NOT about the DevExpress bug.
The unique thing about this crash is that it breaks on this line in the auto-generated code in App.g.i.cs (as opposed to other exceptions being thrown in other places):
#if DEBUG && !DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION
UnhandledException += (sender, e) =>
{
if (global::System.Diagnostics.Debugger.IsAttached) global::System.Diagnostics.Debugger.Break();
};
#endif
It seems this is triggered when some kind of exception / crash happens in XAML-related mechanisms (but this is just a wild guess on my part)... I don't think the above code is responsible for the "crash to desktop" effect, but it does seem to be a symptom.
My own code for error handling (in App.xaml.cs):
public App()
{
//...
this.UnhandledException += App_UnhandledException;
//...
}
private async void App_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
var ex = e.Exception;
e.Handled = true;
Logger.LoggingError(ex);
await Controls.MessageDialog.Show(ex.Message, Controls.MessageDialog.DialogType.Error, Controls.MessageDialog.DialogButtons.Retry, ElementTheme.Light);
var frame = Window.Current.Content as Frame;
frame.Navigate(typeof(Views.SplashLoading));
}
The error handling attempts to:
log the error
display the error
go back to the start view
Again - this generally works very well for all other purposes. But if ever the breakpoint in App.g.i.cs gets triggered (or would get triggered, if the application is released on client machines) then my error handling fails completely.
Note, that this isn't exclusive to DevExpress controls. It's just that the DevExpress control causes this behavior in a way that can be replicated. Again - if an exception would cause the code in App.g.i.cs be fired, then it seems there's no saving the application.
What could I do to make sure the application keeps going once this unfortunate event occurs and doesn't crash to the desktop?
EDIT:
For reference, this is the error message which occurs when using the DevExpress controls:
System.ArgumentException: The parameter is incorrect.
The value cannot be infinite or Not a Number (NaN).
at Windows.UI.Xaml.Controls.ScrollViewer.ChangeView(Nullable`1 horizontalOffset, Nullable`1 verticalOffset, Nullable`1 zoomFactor, Boolean disableAnimation)
at DevExpress.Core.Native.DXVirtualizingPanel.ScrollElementIntoView(Double elementOffset, Double rowHeight)
at DevExpress.Core.Native.DXVirtualizingPanel.ScrollIntoView(Int32 visibleIndex)
at DevExpress.UI.Xaml.Grid.DataControlBas
Unfortunately that's the full message - it appears the complete stack-trace is missing.
Apparently setting e.Handled = true; does not guarantee that the application won't crash (as described on MSDN):
The Windows Runtime considers exceptions encountered during certain
operations as nonrecoverable, because the Windows Runtime itself will
be in an inconsistent state following these exceptions. For such
exceptions, even if the UnhandledException event handler sets Handled
to true, the app will still be terminated.
However, why does the DevExpress cause such an invalid state with its control is a mystery to me... But at least it solves the question of why the app closes despite the event being handled.
Extra thanks goes to the folks from DevExpress support team, who helped with the case.
I have a strange problem with Asserts being ignored. You can reproduce it with this minimal example. I am wondering why this problem occurs and how to face it:
public class TestAssert
{
public string EmptyString
{
get
{
System.Diagnostics.Debug.Assert(false);
return string.Empty;
}
}
Dictionary<string, object> dict = new Dictionary<string, object>();
public void ShowAssertIgnored()
{
var foo = dict[EmptyString];
}
}
You can see that the Debug.Assert(false) is ignored even though the property is evaluated. Just call
var test = new TestAssert();
test.ShowAssertIgnored();
and you should see what I mean (also shown on the image).
The code is compiled and run in Debug (other asserts work fine!), 32 bit, x86 + AnyCPU, VS2012 professional, .Net Framework 4
Edit:
The project is a console application and I was running it for several times in a row. Having a breakpoint before System.Diagnostics.Debug.Assert(false); most often a messagebox appears. But not always: When I just retry the same situation several times I sometimes see the result in the console.
To say it again: I can reproduce non-deterministic behaviour in the VS2012 debugger!
If you read the docs, you'll see that Debug.Assert isn't designed to throw.
Typically, the Assert(Boolean) method is used to identify logic errors during program development. Assert evaluates the condition. If the result is false, it sends a failure message to the Listeners collection. You can customize this behavior by adding a TraceListener to, or removing one from, the Listeners collection.
When the application runs in user interface mode, it displays a message box that shows the call stack with file and line numbers. The message box contains three buttons: Abort, Retry, and Ignore. Clicking the Abort button terminates the application. Clicking Retry sends you to the code in the debugger if your application is running in a debugger, or offers to open a debugger if it is not. Clicking Ignore continues with the next instruction in the code.
If running in an UI environment, it may trigger throw-like behaviour that is defined in the listeners that the UI environment/test-runner sets up.
So, in short, Debug.Assert(false) won't halt your application but its listeners might.
Assuming that there is no UI here... If you want your code to fail, then you'll need to write your own TraceListener:
public class MyTraceListener : TraceListener
{
public override void Write(string msg)
{
throw new Exception(msg);
}
public override void WriteLine(string msg)
{
throw new Exception(msg);
}
}
and add it to the listeners collection:
Debug.Listeners.Add(new MyTraceListener());
Have you checked your project settings to define the DEBUG constant? The Debug.Assert() methods have the [ConditionalAttribute("DEBUG")] attribute, which means, they will by ignored during compilation, if the "DEBUG" constant is not defined.
That's an expected behaviour, Debug.Assert() works in debug build only:
By default, the Debug.Assert method works only in debug builds. Use
the Trace.Assert method if you want to do assertions in release
builds. For more information, see Assertions in Managed Code.
https://msdn.microsoft.com/en-us/library/kssw4w7z(v=vs.110).aspx
use Trace.Assert() if you want it working in release as well.
I recently changed one of the options in the debugger and I think that is what is causing this problem but I can't seem to 'undo' it...I google and all hits come back with the opposite 'why does the debugger not stop on a breakpoint'
anyway can someone shed some light?
EDIT: when I press f5 in debug mode. Everytime. It goes into the Program.cs and stops on
Application.SetCompatibleTextRenderingDefault(false);
in the Main()
Old thread I know, But I just encountered the same problem. All I did was a Delete All Breakpoints (Ctrl+Shift+F9 for me), then a Clean on my startup project, followed by a Rebuild, then Run. After that it stopped breaking where there were no breakpoints.
I just experienced the same problem however mine isn't due to a option change. I think I have found the reason why but no resolution to fix it. I have a Solution with multiple projects, the projects involved are:
Business Logic
Data Access
Console App
In both BL and DA I have a class called Credit.cs. Both classes are in different namespaces.
When I set a breakpoint on line 235 in BL.Credit.cs then the debugger stops on line 236 in DA.Credit.cs even though there are no breakpoints set. I think this is a bug in Visual Studio.
When I remove the breakpoint in BL is subsequently does not stop in the DA either.
I have submitted a bug if you wish to vote https://connect.microsoft.com/VisualStudio/feedback/details/699804/debugger-stops-on-same-line-in-different-class-where-there-is-no-breakpoint
Here's a workaround for the behavior of breakpoints activating in each class that has the same name even if fully-qualified names are different. After you set a breakpoint, go to the Breakpoints window (Debug | Windows | Breakpoints if it isn't already up). Right-click the breakpoint that's firing in too many same-named classes (e.g. Project2.Action breaks when you only wanted Project1.Action to have a breakpoint) and selection "Condition." Set the condition value to something like this: this.GetType().FullName == "Project1.Action".
Thereafter, the condition makes it so that execution only breaks on the class with the correct fully-qualified name.
Does it stop by giving you an exception or does it just completely stop the execution of your application? If you don't have the UnHandledExceptionHandler in your code it can look like it just stops but you actually have an exception.
UPDATE:
Here is what your Main method should look like to capture unhandled exceptions as try/catch don't always work.
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
throw new NotImplementedException();
}
static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
// You should/MAY see an error right here.
throw new NotImplementedException();
}