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
Related
I built a UWP application which logs data from an internal class to a .csv file using the CSVHelper library. I am having a problem where the application stops responding when running in debug mode without any exceptions being thrown. The app also does not crash. In VS the diagnostic session timer is stopped but the code is still "running". There is no stack trace when I break, the application won't hit any breakpoints and closing the app with the "X" closes the window visually but it doesn't end the debugging session and I suspect the process remains running. I have to use the "Stop Debugging" button in visual studios to end the session. It occurs at seemingly random intervals unrelated to what the app is currently doing. The crashes are usually in the 50min+ execution time range though it has happened earlier.
How do I go about troubleshooting this issue?
I really don't know where to start without any exceptions or even a clue as to what causes the application to hit this state. I would include code but other than just linking the entire repo I am not sure which sections would actually be helpful as I don't know, nor can I seem to find a way to identify what code is running to enter this state.
I am using the Branch.io Xamarin SDK in my iOS app.
From my FinishedLaunching method on the AppDelegate, I call this code as advised in the Branch documentation (https://github.com/BranchMetrics/Branch-Xamarin-SDK)
BranchIOS.Init(BranchKey, url, true);
Branch branch = Branch.GetInstance();
branch.InitSessionAsync(this);
If I run my code using the debugger (both on iPhone and iPhoneSimulator), the app terminates shortly afterwards, without any sort of error or exception printed in the logs. (There is an exception logged by Crashlytics in a log file, but I can't read it.) It is indeterminate when exactly the app terminates.
If I start the app without the debugger, Run -> Start Without Debugging, the app runs fine and does not terminate. Of course, if I remove the above 3 lines, the app runs fine under the debugger as well.
How do I go about getting a stack trace or some other log to find out why the app is terminating, and what is causing the app to terminate only while debugging?
I've read reports that when you switch between targets or toggle debugger on/off, you need to clean and rebuild before trying to run it. Otherwise, the pre-built files aren't applicable after switching. Have you tried this?
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 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
}
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.