Looks like that on some clients our WinForms up crashes on startup. With some I mean very very rare. In one situation we found out that the Arial systemfont was corrupt and caused the crashed in the InitializeComponents on startup. Finding that our was very hard, the only clue was an event log entry that the System.Drawing module caused the crash.
Now I have again such a situation but this time the faulting module is "unknown" and I am wondering how people are handling/debugging such crashes. I tried to wrap an exception handler around the InitializeComponents but it doesn't catch anything.
Any advise how to approach these crashes?
You always catch the exception at main() and paste the exception to your error log. Only then you can debug and know for you.
For error logging tool, you can try log4net, or just write to a simple flat file.
I've used the approach detailed at http://www.wintellect.com/CS/blogs/jclark/archive/2005/03/30/simple-main.aspx with good success.
(You'll have to ignore about 3000 lines of comment spam, though.)
Related
I am stuck at a strange issue in EntityFrameworkCore 3.1.2:
That is my application logging an error Further to my checks with .NET Reflector, I see that the assembly Microsoft.Extensions.DependencyInjection, Version 3.1.2.0 indeed references 3.1.0.0 of Microsoft.Extensions.DependencyInjection.Abstractions:
My application is targetted to net48.
I tried to narrow down the issue by writing a simple application, and it still gives the same error. Any help is much appreciated!
Edit: I figured out that the issue was caused by the fact that I have code in place to create an AppDomain and the faulting code was being executed inside that. I still don't know what is causing it. My assumption is the references should still work correctly inside a cusotm AppDomain.
I am not a programmer. I have some software at work that keeps crashing on me. I used the Visual Studio debugger last time it crashed and found out it was unhandled exceptions.
The first unhandled exception is at 0x0048ADF0 in Cyclone.exe and is an Access violation writing to location 0x00000003.
My research leads me to understand that this is the program trying to write to memory that the process doesn't have permission to.
When running the debug in Visual Studio, after the access violation exception there is a long list of Unhandled exceptions similar to this "...at 0x776C016E (ntdll.dll) in Cyclone.exe: 0x00000000: The operation completed successfully." with different addresses.
Is there any way I can fix this without being a programmer? Some sort of modification to the app files or settings, or a tutorial or something.
No, there is no way. It's not different from asking if you can drive a car without knowing anything about driving.
Sounds like you need to report the problem to the person or company who provided it. What you need to do, however, is give them enough information to understand the problem and fix it. This includes:
what version of their program are you running
which computer operating system (e.g. Windows) and which version (e.g. 7)
precisely what steps you have to take to make the error occur
whether you have changed anything recently, e.g. by installing Windows Updates or changing your anti-virus protection
precise details of any error messages you see, ideally by copy/paste or by providing a screenshot of the erro
anything else you think might help them to help you
Be prepared for them to ask you additional questions, or try some tests to help figure out the cause and a way to solve it.
Your research sounds about right but I don't think there is much anyone here can do to help (unless they happen to work on the application).
Your best bet would be to look for a "Help" or an "About" screen and contact the people who wrote it with this information
(see update below)
While running within the VisualStudio 2010 environment, I can easily tell if my Winform application causes an exception. I just have to go to Debug | Exceptions and make sure that both columns of checkboxes are checked. I then run the application and if any exceptions then I get dropped straight into the offending piece of code.
How do I determine exceptions during testing, when I give test build to a tester. I do not want the tester to run within Visual Studio, just as a regular user. I still want to know if there are exceptions and the pertinent details.
Obviosualy, I should be able to control the process, so that when the code gets released normal execution happens.
Yes, I know about and use try/catch blocks, but I am talking about a method similar to Visual Studio exception catcher and reporter, just possibly compiled into the product and used for deployment to beta testers.
Maybe Visual Studio has such a feature, in which case where and how to set up, or possibly a third party component.
[Update:
I added two sub-questions, which you can find at Unhandled Exception next line or exit.
The solution mentioned below sounds great and with a tweak probably works, just not at the moment.
Inside the Visual Studio both 2010 and now 2012 works great. The exception handler gets called, okay after VS breaks at the line and I say to continue. I decided to test outside the VS2012 IDE, good thing for that. The OS traps the bug, shows the standard an "An Unhandled Exception Occurred" dialog giving the details along with a continue and quit buttons. Selecting continue, just continues the application with no trapping into my uber exception handler. Selecting quite, whites-out the application and displays the standard close window dialog. The quit button also does not call my uber handler.
The purpose is so that my exception handler gets called. I do not need an uber exception handler if I am working inside the VS2012 IDE. The purpose of the handler is for end users and beta testers, namely anyone other than myself and who will not have my development station.
So unless I am missing something, the question is still open.
There are code samples in the other question, enough to copy and paste and create a test application in a couple minutes time.
]
Thanks in advance,
Sarah
I don't know of any automagical ways to reports error in Visual Studio but here is what I do.
Hook into the UnhandledException event for the application.
Use a logging framework like nLog or Log4Net to log the exception and other data you get from that event. Or just write to a text file.
Upload that data either from within your application or have the beta-tester send it to you.
Okay, the Google Uberlord took pitty upon me and I found this wonderful article solving the problem. Praise to the almighty Google.
Here is the link:
http://www.switchonthecode.com/tutorials/csharp-tutorial-dealing-with-unhandled-exceptions
Basically, JRadness had the right idea, just slightly in error. He should have used
Application.ThreadException +=
new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
rather than
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
The author on Switch on the Code talked of three methods, the first of which is what JRadness proposed and does not work for Windows forms.
The autor even solved my other question of Continue and Abort. The OS got bypassed.
Yeah!!
I have a WinForms application in which I want to be able to provide an HTML editing feature. So I've translated Lutz Roeder's HTML Writer from C# into VB.NET, and converted it from a windows form into a Custom User Control, which is now hosted in an MDI child form.
It all works fine until I close the parent MDI, in which case it crashes, and I cannot trap the exception.
I've isolated the editor control into a little vanilla WinForms app that doesn't do anything else, and verified that the problem still occurs.
I've also switched on Unmanaged Code Debugging (I'm using VS2010, compiling for x86 and Framework 3.5), and all I get is this:
Windows has triggered a breakpoint in HtmlEditorMdi.exe.
This may be due to a corruption of the heap, which indicates a bug in HtmlEditorMdi.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while HtmlEditorMdi.exe has focus.
The output window may have more diagnostic information.
The only thing other thing I've noticed is that if I leave a long interval after opening the form containing the editor, it doesn't crash.
What I'd really appreciate is some ideas about how to go looking for this problem. It may be of course that I've made a mistake in the C# to VB conversion, but I'm struggling to know where to look.
Edit:
I've run the app with the debugger attached, and it doesn't give me anything useful.
All I get is the Windows 'Application has stopped working' message, with this in the problem details:
Problem signature:
Problem Event Name: APPCRASH
Application Name: HtmlEditorMdi.exe
Application Version: 1.0.0.0
Application Timestamp: 4cfb74c7
Fault Module Name: mscorwks.dll
Fault Module Version: 2.0.50727.4952
Fault Module Timestamp: 4bebd49a
Exception Code: c0000005
Exception Offset: 000022b5
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 2057
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
I can see that it's an access violation, but even if I go Debug > Exceptions > Win32 Exceptions, and tick c0000005, I don't get anything useful when it breaks - just 'no source available'.
The first message you quoted is produced by the Windows heap manager when it discovers that the internal heap structure is destroyed. It displays that diagnostic when it sees that a debugger is attached. The 2nd quoted block is what happens when it bypasses the diagnostic (no debugger attached), it bombs on a hardware exception when it tries to release memory in the corrupted heap anyway.
The trouble with heap corruption is that the real damage is done a long time before the diagnostic is generated. You can see a stack trace leading up to the diagnostic in the Call Stack window, you'll need to enable the Microsoft symbol server to get meaningful symbols for the Windows functions. But it won't tell you anything useful about the code that really caused the damage, that requires a time machine.
This kind of heap corruption is invariably caused by unmanaged code. The AccessViolation exception is a well known scourge to C/C++ programmers and a very large reason why managed code became popular. While Lutz' source code is all managed, it contains a lot of P/Invoke and COM interface declarations. There is no good way to debug them, you don't have the source code.
Getting one of those declarations subtly wrong when you converted them to VB.NET is certainly one way this could happen. It could also well be that the bug was always there but reared its ugly head just now. Lucky you. Btw, I don't think the code is 64-bit clean, force it to run in 32-mode for a possible quick fix. For your main EXE project: Project + Properties, Compile tab, scroll down, Advanced Compile Options, Target CPU = x86. This is only relevant if you run on a 64-bit version of Windows.
Other than that, I'd recommend you just use the C# project as-is. Mixing languages in a solution is a very well supported scenario in .NET.
The windbg debugger is the "big gun" for this sort of problem. It can frequently give you clues by telling you about handled exceptions etc. The only problem with it is that it's not easy to use and has a very high learning curve.
A WPF application. Debugging. Stop on break point.
After few seconds Visual Studio (2008) spontaneously aborts the application execution.
It is never mind what I do after stop on break point: even if I do nothing.
With very simple test WPF application everything is OK with debugging.
Any ideas?
When an application aborts that quickly without warning it's usually the result of a stack overflow in the process. This makes it difficult (if even possible) to do tear downs operations like bringing up Dr Watson.
One thing I didn't quite understand is if the application or VS is suddenly stopping.
If it's the application there is likely a StackOverflow occurring in such a way that VS can't trap the exception. Try disabling Just My Code debugging, turn off implicit function evaluation and break on first chance exceptions. That should hopefully help reveal the problem.
The problem was solved.
To solve the problem the debug settings must be changed:debug->exceptions: and check on exceptions boxes (I checked on C++ and CLR).
(source: ggpht.com)
Result: I can see exception that I didn't see before and I can normally debug my application.
The reason was incorrect vcshost.config file name (my fault).