On a Windows 2003 server I have a pure .NET 3.5 C# app (no unmanaged code). It connects to various other remote systems via sockets and acts like a data hub. It runs for 10-15 hours fine with no problem but from time to time it just disappears. If I watch the app using task manager the memory usage remains constant.
In the Main() function I wrap the invocation of the rest of the app in a try .. catch block which it just blows completely past - the catch block which logs the exception to a file is ignored. If I manually raise an exception for testing, the catch block is invoked.
Prior to entering the try .. catch I do :
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
The system has Dr. Watson on it, but nothing gets written in the directory DRWTSN32.EXE is pointing to.
How can I catch whatever exception is causing this?
Try using the debugging tools from microsoft. You can download them from here.
Use adplus to capture the crash and then windbg to analyze it.
adplus -crash -pn your.exe -quiet
Lots of great info about debugging on windows on this blog.
If this is a Windows Forms app, then it's likely that the unhandled exception is being caught by the window message pump, which is why you never see it. To deal with this, see my answer here.
If it's a Windows service, then the exception might be appearing on a background thread and not being marshalled back to your main thread. To deal with this, you need to marshal any background thread back to your main thread, and the exception will be re-thrown there so that you can catch it.
If it's a console app, then I'm a bit mystified.
EDIT: Your comment says this is a Windows Forms app. In that case, you're probably not seeing the exception because it's being handled by the built-in Windows Forms exception handler that does the following by default:
Catches an unhandled managed exception when:
no debugger attached, and
exception occurs during window message processing, and
jitDebugging = false in App.Config.
Shows dialog to user and prevents app termination.
You can disable this behaviour by setting jitDebugging = true in App.Config. Then you should be able to see the unhandled exception by registering for the event Application.ThreadException, e.g. in C#:
Application.ThreadException += new Threading.ThreadExceptionHandler(CatchExceptions);
You could also attach WinDBG at startup and enable breakpoints on .NET exceptions. You can then do a !printexception to see what is going on.
There might be trace of the application in the EventLog.
I have had a .Net app disappear without the possibility to catch an Exception. There was an entry in the EventLog every time this happened.
To view the eventlog just type EventVwr on the command prompt, or run box.
If it's a Windows Forms application, you could try Application.ThreadException.
Related
To capture the messages written in output window in VS 2010 , trying to intercept a message leading to a bug.
the message that i'm trying to intercept :
A first chance exception of type 'System.Runtime.InteropServices.SEHException' occurred in OpenNETCF.Desktop.Communication.dll
Disconnect
after that when i connect the device the app freezes, with no exception.
How i could capture output window messages or redirect them to a string ? can i intercept when i will use this app in production mode ?
I have tried to capture console Messages but i got nothing apart the console.writeline called from the app , so i think that these messages are not console.writeline calls.
If you are debugging the application then to get the debugger to break when a specific exception is first raised (1st chance exception/thrown) you can tick just the specific exception you want, instead of the whole set of exceptions in Runtime.InteropServices.
See the screen shot below:
If your application isn't currently running in a Debugger, then you can get a debugger to attach to the already running process...by using "Attach to Process"...however, that is not normally done in a production environment.
If you want to analyze your application in a production environment i.e. you can't stop your application or run it in a debugger...then the best way to do that is when the exception occurs to get a "dump" created of the process...which you can then analyze offline in either WinDBG or Visual Studio by loading the saved .dmp file.
The best way to set things up is so that a "full dump" file is automatically created when the exception occurs by using DebugDiag.
http://blogs.msdn.com/b/kaushal/archive/2012/05/09/using-debugdiag-to-capture-a-dump-on-first-chance-exception.aspx
It's also possible to manually do a "mini-dump" of your application process by right clicking on the process in Task Manager and doing create Dump File. Doing manually however, means you are a lot slower at capturing the state close to the time of the exception, and also a "mini-dump" is less useful than a full-dump.
There's a good tutorial here on how to diagnose problems in a production environment:
http://channel9.msdn.com/Series/-NET-Debugging-Stater-Kit-for-the-Production-Environment
I have a program developed by C# and build by .net 4.0.
This program is a windows client which would read the barcode from a barcode reader (via com port) then send the barcode to back-end server via WCF.
The customer have a script in the client OS which would reboot the OS and automatically start up my program every day. The OS is Windows XP Embedded.
Now the problem is, sometimes when the system reboot, my program cannot be started and an error message box will popup to ask whether send this error report to Microsoft.
The most strange thing is, if my colleague copy the program folder and paste as "Copy of ...." in the same folder with the original one the exe under "Copy of ..." one can run without any problem. But the original one still cannot.
What my speculation is maybe the program was writing log and other record files while the system was forced to reboot. And the files get the read/write lock unreleased.
I have uploaded the error screen shots to flickr. Please click here link to visit.
Without knowing what the actual exception is, we can only guess.
You will need to catch the exception that is being thrown in your application.
The best practice is to encapsulate your code in try/catch clauses.
If you are still getting application crashes, then you can attach an event handler to AppDomain.UnhandledException, or Application.UnhandledException and log the exception(s) being received.
Make sure to output the entire exception stack trace, so you can see where it's being thrown from.
Once you've got the exception, if you can't figure out the cause, then ask another question here with that specific detail. eg: "I'm getting an FooException being thrown when I call Bar() after start-up on Windows XP Embedded"
Sometimes after a reboot, some device drivers, or some hardware, will NOT reset itself. The machine has to be power cycled (turned off and back on) or a command needs to be discovered that will force the device driver and/or hardware to reset.
Referring to image IMG_1348 you posted, the error is thrown in your form constructor.
Seems like either code you added or InitializeComponent code is throwing.
Since you are using XPe, you have some options to debug this issue:
Add message box statements around the various constructors to show initialization progress. Guard before and after.
public Form1()
{
MessageBox.Show("Before InitializeComponent");
InitializeComponent();
MessageBox.Show("After InitializeComponent");
//MessageBox.Show("Before Other");
//Other Initialization Code
//MessageBox.Show("After Other");
}
Attempt to use the remote debugger. I am not sure if this works on XPe, but if it does, and since your code is throwing in the constructor, you need to add code to wait until the debugger is connected.
public Form1()
{
while (!System.Diagnostics.Debugger.IsAttached){ System.Threading.Thread.Sleep(0); }
InitializeComponent();
//Other Initialization Code
}
I have written a windows service in c# that's designed not to stop or restart.
In the constructor, there is a log that writes something like "Starting Application".
So i left it running for more than a week and I can see that the constructor that writes the log is being executed. This leads me to believe the windows service is restarting for unknown reason. There are no errors being thrown!!
Any idea?
Cheers.
Usually you can see the reason for a service restart by looking in the event viewer. Open it from Administrative Tools under your start menu. Look underneath Windows Logs/Application. Look for anything with your program name or anything that has a Red exclamation mark.
Generally, when writing a windows service, you want ALL of your code to run within a TRY/CATCH block. You can log any error in the catch block if you want (but be careful that your logging code can't throw an exception!). You have to "swallow" the exception in order to let the service keep running.
I have a .NET 4 app running on Windows Server 2008 R2 which I use a separate running process to manage its life cycle (i.e., detect turn on / unexpected shutdown / reboot). This works fine for typical conditions. However, when the application throws an exception, Windows brings up the debug window offering to debug the application. I just want the application to crash, so the process runner can detect the crash and manage accordingly.
How do I allow an application to close on an exception?
Add a handler to the Application.ThreadException and in the handler, log the event, then exit nicely.
Also, add an event handler to AppDomain.CurrentDomain.UnhandledException as well.
Unhandled Exceptions MSDN
Edit: removed bit about Handled flag.. thanks Alex
Adding this line will prevent showing 'debug window'.
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
You should add a global exception handler or a try/catch to clean up the resources, log the error and close the app normally.
I want to get Default Windows Forms Unhandled-Exception Dialog whenever my C# application encounters U-E.
In vs 2005 when I turn off jit Debugging in app.conf like this:
<configuration>
<system.windows.forms jitDebugging="false" />
<configuration>
the application behaves correctly and shows Windows Forms U-E default dialog, with Continue, Quit, call stack and all.
However in vs 2008, on the same machine or different, even though I diable jit I still get Default .NET Unhandled-Exception Dialog, with Debug, Send Report and Don't Send buttons.
How can I make my vs 2008 app act like the one I make in vs 2005, to show Windows Forms U-E dialog box?
Please do not recommend to use
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
just because I don't use custom handler in my vs 2005 project, why would I use in vs 2008? I want to let this job do CLR.
Any help is appreciated
You are talking about different exception handling features. The ThreadExceptionDialog you see with the Quit and Continue buttons is triggered by the Application.ThreadException event. It will only ever appear if the exception happens on the UI thread, when an event handler that runs in response to a Windows message throws an exception. Any exception in a worker thread however will bomb the program through AppDomain.UnhandledException.
You cannot handle the latter, the program is dead and cannot continue. Displaying ThreadExceptionDialog is pointless.
You can make the program bomb consistently by disabling the ThreadException event by calling Application.SetUnhandledExceptionMode(). Now every unhandled exception will trigger AppDomain.UnhandledException and terminate the program. That's probably not what you want but is the wise choice.
Also note that the ThreadException event is disabled when you run the program with a debugger. Which is presumably why you see a difference in VS2008. There have otherwise not been any changes.
Answer by Hans Passant seems sensible. However, even though you say you don't want to I still recommend a handler on AppDomain.CurrentDomain.UnhandledException to make sure you determine what happens when your application crashes unexpectedly.