My winform application is failing when run outside of the IDE with a dragdrop exception. The error does not occur while being run from inside the ide (VS2008). How can I trace this. I have seen mention of using JIT in the error box that is displayed post error - will this help me trace my problem?
Don't know if this will be helpful, but...awhile ago I was getting DragDropException when my WinForms app was being run on a thumb drive, not a full system. The form generating the error had no drag-and-drop feature. I never figured out the problem, but I saw that a UserControl on that form had defaulted AllowDrop=true unnecessarily. Once I turned that off, the problem went away.
If your form is intended to support drag-and-drop, I'd look into on what thread the form generating the exception is instantiated. My understanding is that Microsoft's implementation of drag-and-drop is COM-based, which must be initialized in an STA thread. Putting the [STAThread] attribute before your program's entry point will accomplish this.
Related
Please note that I'm aware of possible solution and have read some other SO posts which will answer the question how to handle unhandled exceptions globally and I'm not asking if it is good practice or not.
What I'm asking is:
Why do WPF applications close on exceptions?
I always thought that it is the expected behaviour, however when researching how to implement the exception handling globally in WPF, I encountered this sentence on the Microsoft documentation page:
By default, Windows Presentation Foundation catches unhandled exceptions, notifies users of the exception from a dialog box (from which they can report the exception), and automatically shuts down an application.
But my experience is different, the application just exits without any warning, so any unhandled exception will be a total mystery for the user and me as a developer.
My question is really: Am I missing something, or is Microsoft wrong about their own framework?
The docs seems to be wrong.
By default, a WPF application exits without any dialog box when an unhandled exception is thrown on the dispatcher thread.
You may consider to edit the docs and submit a PR on GitHub by clicking on the "Edit" button in the top right corner of the page.
After the latest release of my application, users are experiencing application "locks" where the program just remains unresponsive. This occurs at different times and never after a specific action.
At one point I found an entry in the Windows Error Logs, but I can't figure out what's happening there.
My main questions:
anyone experienced anything like this with ReportViewer in Windows Forms application?
Can someone explain the attached error log (please excuse the Dutch)
Update
Still no idea on how to fix this issue. Application keeps randomly freezing with different users. Everytime an application-hang is preceeded by the above mentioned .NET Runtime error and event 10016 (DistributedCOM). I have tried to resolve the DCOM issue by following this answer, but that did not solve the problems.
Also, I have made sure that all the forms with reportviewers (only 4) and every method that has to do with reportviewer operations have proper errorhandling.
Further explanations: from a windows form I open another form which contains a reportviewer. I show this form as a dialog.
After long inspection I found the culprit: in a new process which was started in a backgroundworker a form with a reportviewer was opened but never disposed. Closing the form and disposing it solved my issue.
I'm looking for a little help regarding the win32 exception "error creating window handle".
From time to time our program (WinForms - C#) throws this exception and sometimes the windows even freeze, so that the users have to kick the process to be able to work again.
From the many other threads regarding this problem, I know what I should be looking for, but not extactly where as our program is quite big. So I was hoping that there might be a way to restrict the codelines I have to check... Are the any tools, which can help with this exception?
Short update: I solved the problem.
ProcDump didn't help me much, because I got pretty the same information from our logfiles. However, I was able to reproduce the error in our development environment. Thanks to debugger and displaying the user-objects count in the taskmanager I found the source of the memoryleak - an undisposed texbox which was created dynamically.
Thanks again for the tips!
If this issue happens inside the debugger, you can set the debugger (I will assume Visual Studio as you're using C#?) to break on throwing an exception. In your case you would want to set an exception breakpoint on (I think) System.ComponentModel.Win32Exception.
Again assuming Visual Studio as your IDE, on the "Debug" menu is an "Exceptions..." item. This allows you to tell the debugger to break when specific exceptions are a) thrown, or b) unhandled.
Under Common Language Runtime Exceptions, expand System.ComponentModel, and enable the checkbox in the Thrown column for System.ComponentModel.Win32Exception.
Then just carry on as normal. If during debugging the exception occurs, it should break into your program and allow you to see where it's happening.
Edit: If you can't reproduce the problem on your development machines, see if you're able to set up the target machine to produce a dump when a crash occurs. One way of doing this is to run ProcDump. Run it with the -e parameter to create a dump in the event of an exception. Then you can analyse this back at the ranch.
I had an experience the other day where an exception should have been raised in my code, but instead it just kicked out of the routine and continued running (i.e. it's a WinForms project, so by "continued" I mean control just went back to the form where it waits for further user input).
I thought it was odd, but fixed the problem and didn't worry about it. Today, I had the same thing happen in a different project where I had an XmlDocument object Load()'ing a file that didn't exist. It should have raised an exception, but instead it just kicked out of the routine and gave control back to the form.
Has anyone else experienced this behaviour or know anything about what might be causing it, or does this sound like a bug in VS 2010?
I got the same issue a will back. In my case, the problem only occur in development and not after the release. To get the errors, I found the you need to change a setting in VS. In the Debug menu, click on the Exception item. This tell when VS should break with error. You need to check the Common Language Runtime Exception Throw option. It should correct your problem. You will need to do this for each project.
Please humor me as I might be crazy.
Does viewing xaml in the Visual Studio UI designer execute the code-behind file?
For the past while whenever I try to view the main xaml file of my WPF application it throws an exception, but because I've been busy with other things I never really looked into it until today. Now I notice that in the exception's call stack it's calling many of the code-behind's methods, including methods like Window_Loaded (!). It's like it's trying to run my application while I'm designing it and obviously failing.
So I'm also wondering why it does this.
I'm also wondering how exactly I'm supposed to debug this as it's doing all this behind my back.
The actual exception comes from the fact that my application uses an unmanaged dll that it tries to use but somehow can't find it for some reason.
[Edit]
I've tried moving my unmanaged DLL to Windows/System32, but I still get the same exception.
Thanks!
Yes, there are things (like constructors) that get evaluated at design time. If your code is throwing an exception in the designer you can add this:
if (DesignerProperties.GetIsInDesignMode(this))
{
return;
}