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.
Related
A bit of a general question perhaps. I have an app that is quite simple, basically a wrapper app for a webpage. This app crashes on WP8, and it happens usually when you start the app, then go to the home screen and hold the back button to bring up the recent apps view and go back into the app. The app is just killed.
What I am wondering is that before when I have had problems with a WP app crashing on WP7.5 I would run the app on the phone from Visual Studio Express and when the app crashed I could see the error and stack trace in VSE. But with the error I am having now its as if VSE doesnt even know that the app has been terminated. It still shows that it is running.
One thing I tried was to add event handlers for the onNavigatedTo event and set a breakpoint in there to see if I could catch the app when I was switching back to it and then do step by step from there. But when I did that and the app crashed all I got from VSE was a message saying that it had failed to bind the breakpoint.
I also tried the emulator, hoping it would give me better insight but its the same as running the app on a phone. So now I have an app that is very unstable on WP8 (works solid as a rock on WP7.5 though) and I have no idea what exactly is going wrong.
So my question is if there is any way to get more information on how and why the app is crashing :)
You also can use the Event View of Windows.
I have a similiar problem (sometimes while running and accessing the isolated storage the app just gets killed without any notice) and the event views provides some useful information.
I'd suggest to put debug output (Debug.WriteLine) in App_Activated and App_Closing methods in the App.xaml.cs file. And also to the RootFrame_NavigationFailed and Application_UnhandledException. All those methods has a potential to run when you return to your app and it crashes. If this would not help (you'll see no output in VS Output window), try putting some other output there, like writing synchronously to a file in the isolated storage, or activate some launcher (like email compose task, see here). The point here is to perform some other activity when failure happens.
Another thing you could try is to break execution in VSE, when app is already seems to be terminated. I mean, pressing the "pause" button in the debugger. It could potentially be informative.
I have just got the wierdest problem in my Windows Froms C# application
I got a few Console.WriteLine in my code for debug, but suddenly this stopped working. For example
try{
line(of.code);
Console.WriteLine("HERE");
other.line(of.code);
}
catch (Exception e)
{
logger.logg(e.ToString());
}
I will not get to the other.line(of.code); line, and I do not get the "HERE" in the console.
There is a few places in the code, the same happens on all of them. It just stops, it does NOT get to the catch...
And the worst part, it worked earlier. I have worked on applications for a long time, and have never seen anything like it.
If you need it just for debugging, try
System.Diagnostics.Debug.WriteLine("HERE");
instead.
This will write the output into the output window of your development environment and, more important, it will work regardless of the type of application you are developing (console app, win forms, web app etc).
As soon as you change to "release", the debug information will be ignored and not compiled into the code. If you would require it there, too, you should try Trace.Writeline instead.
I can think of a few scenarios that will cause Console.WriteLine to fail:
The output stream has been set to an invalid object or something that will misbehave (in your case stop the program).
You are running in an environment that doesn't give you permission to use the console*.
It is not System.Console.WriteLine but another method with the same name that gets invoked thanks to some using directives.
*: I can't think of such environment, but may be some plug-in system?
If you are making a Windows Froms Application and not setting the output stream for your Console then Console.WriteLine should do nothing. So, if you need debugging follow Matt's recomendation.
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
}
We are in the process of setting up surround scm as our source control program. We created a trigger which will run when changing the state of a file/repository. When we run it on many files the server gets several werfault.exe processes in the process list. I realize its windows error reporting, however, there is no popup. I'm trying to determine the cause of the error... is there a specific log I can check, or a debugging technique I can use? I don't believe it will be possible to debug directly on the server it runs on.
Thanks
WER faults end up in the Event Log, so that might give you a tiny clue, though it's usually not enough info to tell what went wrong. Maybe you want to add more logging to your trigger application, or have it run userdump.exe when it's about to crash (see AppDomain.UnhandledException event) to a specific folder - that way you can open up the crash dumps later to figure out what went pear-shaped.
What was happening was that we set a trigger on certain events and the trigger calls the handling exe simultaneously, which was swamping the server. We're now using an alternate solution with a windows service so we can control the max amount of simultaneous trigger executions.
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.