If crash happened on mobile device, how developer team can receive it?
What should be logged to restore what happened? Just actions on objects and page transitions?
If my markup will looks wrong on some devices or application will behave strange or come to weird state, I want functionality to collect screenshot and info from device and send it. What is the best practices here?
The question is about sending the crash stack trace and logs out. Not about QML app per se but about its C++ base or just about C++ app if we have one. The app should have logging enabled and collect its activity info, maybe for the period of time or until the logs get large enough. We were splitting log in chunks files and removing the oldest after we've accumulated, say, 5 of 100kb chunks.
Crash stack/minidump. Both call stack for all threads and the time of the crash plus minidump of the code with all variables visible can be collected.
How to send the log and crash stack/minidump out? There solutions like BreakPad we supposed to link with/ enable in the app code. The app will take care of sending all the crash info out when it runs again after the crash.
Quite a few things to implement, no to mention the web service that collects the crash info from client apps.
And you have to have "symbols" for the app release code kept in order to be able to trace the stack and see variable values at the time of a crash.
Related
I have an iOS app connected to Firebase Crashlytics. For some crashes the console does not show stack traces (or any other data for that matter), only an error message saying "There was an error loading your session":
This does not happen for all crash events: for some of them, crash data is properly shown. I have tried to get in touch with Firebase support, but no luck so far.
Is anyone experiencing this issue? Any hints about what might be causing it?
Alternatively is there a way to download the raw crash data from Crashlytics?
Firebase tech support has confirmed that the problem is that their backend is having trouble storing the crash data:
what appears to be happening is that the stacktraces for these crashes are too large for Crashlytics to persist to storage. Normally, Crashlytics removes extra threads and manages to store the crash, but if the frames within the threads are too large, we would encounter issues storing the crashes.
Also they say that since the problem is that they did not manage to store the crashes, they cannot provide any way to download the raw crash data either.
They further mention that they are considering implementing ways to increase our size capacity, but they don't have a specific timeline for that, and they consider this a "feature request".
Needless to say I strongly disagree on this last bit, given that:
On iOS it is not really possible to install more than one exception handler / crash reporter
So basically you need to choose WHO you will be sending your crash reports to
If the crash reporting engine then fails to persist your data, then the data is essentially lost
It's difficult to understand how "not losing your data" is considered a feature request rather than a severe bug.
I have found a workaround for this.
If you manually search for the issue title in the issues list and open it from the search tool, the stack trace appears.
I've had Application Insights set up on my ASP.NET project for a couple months with no issues. I use Custom Events for logging certain events.
Recently, I tried to add a Custom Event after a user has authenticated in order to track the login behavior. My custom event DOES log to application insights debug session. I know this because I can see it in the telemetry when paused on a breakpoint just after the event.
However, when I continue running the application, my custom event no longer shows up the telemetry. It just disappears.
I cannot understand what the issue is. Does anyone familiar have any (application) insights? I couldn't help myself ;)
There are some things to check:
are you logging to one resource (iKey) and searching on another? (a lot of people send data to one resource in dev/debug and a different resource in release/prod environments. so make sure you're sending to the place you expect, and searching the place you expect.
is the data actually going out successfully? you may need to use fiddler or some other tool to watch your outbound http for calls to dc.services.visualstudio.com. It could somehow be the case that there's something wrong with the data you're sending, or maybe you're getting capped or throttled by the service. If that's the case, the outbound requests will have responses other than 200, and will generally tell you the reason it didn't accept any items that it rejected.
if the data is getting successfully sent and is going where you expect it to go, there might just be a delay in backend processing. you can always check aka.ms/aistatus to see if there are any current issues with the service.
I am confused, however, by what you mean when you say
However, when I continue running the application, my custom event no longer shows up the telemetry. It just disappears.
What do you mean "it just disappears" ? if you see it in the output window, then the SDK saw it, and it will get sent, precluding any of the above 3 items. Where is it "disappearing" from? unless you clear the output window, it's never gone from there. If you're talking about the VS search tools that show data sent by the AI SDK during debug, that tool currently has a cap of the most recent 250 items that have occurred during the debug session.
How does stackdriver debug application which are in production?
Will the server be down during this period?
How would the latency be?
Is there a way we can debug to an incident that's 'already happened'? e.g. I have an application running in production. And there was an issue - say, I wasn't able to add an item to the shopping cart, or some other issue. Can we go back and debug the issue? Or does it debug the live application?
Stackdriver Debugger's core functionality is rapidly taking a snapshot of your running operation. This means your server is not down, but also means that you can't go back in time either.
Stackdriver Debugger has a quickstart and various other docs that can be useful in getting a basic understanding of what the product does.
Stackdriver Debugger is an always on, whole service debugger. You don't debug just a single server/VM but rather all of your servers belonging to the same service, at the same time. It captures the call stack and variables from a single server when the condition hits and then cancels the snapshot from all other servers.
Stackdriver Debugger agent doesn't stop the process, but briefly pauses the thread hitting the snapshot line and condition. Usually the thread is paused for about 3ms to capture ~64K of information, your time may vary.
Stakdriver Debugger agents are written from scratch with the purpose of optimizing for application latency. They use all sort of tricks to avoid pausing the running thread/server. (e.g., serialization of the data happens after the thread is released)
Stackdriver Debugger is a realtime interactive debugger. There is really now way to debug something that happen in the past. However, since it's a production debugger you can set your snapshot location in production and wait of the event to happen again.
One other feature of Stackdriver Debugger that might find useful are logpoints. These are log statement that you can insert dynamically to your application with a specific case/condition in mind. You don't have to make code changes or re-deploy your service. see the blogpost.
I am working on push notification in my Windows Phone App and I am having this issues.
From time to time the BackgroundTask which is responsible for push notification handling isn't wake up I know it- cause I've spread logs after each code line in my Task.
I know for sure that my token is valid and I am getting the notifications from the server.
This happens only when debugger is not attached.
I don't see any exception either in my log.
I can see in my logs, that one line before I am showing the Toast is cut at the end in a middle of writing (guess the task was terminated suddenly?)
Any ideas what can cause this behavior?
I think that the main problem was that I tried to use too many of CPU time , while writing logs and using my heavy application services (MvvmCross) such as Sqlite.
After removing logs, and heavy consuming time operations - everything worked :)
We have an ASP.Net web application on IIS7 that is used to upload Excel files and then load them into a SQL database by running jobs on the SQL server. The app will wait until the job completes then show the user a message. Due to some larger files being used the app is throwing the error below.
Network Error (tcp_error)
A communication error occurred: "" The Web Server may be down, too
busy, or experiencing other problems preventing it from responding to
requests. You may wish to try again at a later time. For assistance,
contact your network support team.
The app uses an asp:View to progress from various steps. I have tried to bump the session timeout and httpRuntime executionTimeout values to account for how long the job takes to run but it does not appear to have any effect. I know the job completes but the app isn't showing that feedback to the user. I think the error is thrown as the app hits the logic to display the user the view showing all the final messages.
I can only guess that a) there is another setting I'm not aware of for timeout, b) another config file setting is overruling my web config setting for the app, or c) the asp:View is counting all the various steps as one long process and not reseting the "clock" as each step is completed.
As I said, the file upload fine, and the job completes fine, the app just can't advance to that last step where it shows the user the view upon the end. Any ideas on what I can look for to fix this issue? My only other option would be to rewrite the app to not wait for the job to finish and handle notifying the user some other way.
Update 1
After further testing it appears the error is from the ASP.Net custom code we created that does a SQL bulk copy and not the running of the SQL job. The current test runs around 220 seconds testing locally but causes a timeout on a test server.
Update 2
After more research I'm inclinded to think user pevgeniev is correct and this is just a limiting factor of the browser. The only thing that prevents me from marking this as answered is I don't know why file uploads don't appear to have the same issue.
If you're getting this error in the browser, than the timeout is on the client side, and there isn't much you could do server side. As you've suggested, you could rewrite the app, so that it polls for the result from the client, rather than expecting to finish the task in a single request.