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.
Related
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?
I'm currently working on a cross-platform app written in C#. I have a huge problem with testing and debugging it under Linux/Mono. When my application hangs due to an error, I have to kill the process (either using stop button in MonoDevelop debugger or using kill(all) command). The problem is, that after killing I cannot start the application again. When restarted from console, it waits a second or two and exits, showing nothing as output. When started from MonoDevelop, debugger loads some assemblies and then the process exits with no error. There seems to be no Mono-related service in process table. The only way to start the application again is to log off and log in again.
What I'm doing wrong?
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 am writing a small utility application to monitor my clipboard. This at current works quite well, but a friend has told me that it randomly will stop showing alerts upon clipboard change, and that restarting fixes it.
I couldn't reproduce, but eventually I ran into it myself - the application had stopped recieving WM_DRAWCLIPBOARD events.
How can I tell when my application has been removed from the listener chain?
This is one of the hazards of the clipboard listener chain: One bad application can damage the chain. Instead of using the SetClipboardViewer function, use AddClipboardFormatListener which does not have this problem.
If you are debugging an application that uses SetClipboardViewer and the application crashes or you stop the application in the debugger, or in some other way bypass the restoration of the clipboard chain, there is performance degradation in Windows, to the point that seemingly unrelated features of Windows, such as Alt-Tab, or restoring a minimized window, stop working. They come back if you restart Windows.
An application that inserts itself into the clipboard chain this way should be calling ChangeClipboardChain during Dispose of the main form, or at another appropriate time, to avoid this issue. Dispose isn't called if you stop the app in the debugger.
I have not tried AddClipboardFormatListener; first time I've heard of it; I'm going to try it to see if I can avoid the issue in my own app while I'm debugging.
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