I am getting a lot of crashes in failure report on my Dev Center account like:
XXXXXXX!{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
_Timeout_expired:_event_type_=_TargetStateChanged,_timeout_modifier_type_=_None,_server_task_currentState_=_NavigatingTo,_tar
MISSING_DUMP_EM_WATCHDOG_TIMEOUT_DEADA444_XXXXXXX!{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
_Timeout_expired:_event_type_=_TargetStateChanged,_timeout_modifier_type_=_None,_server_task_currentState_=_NavigatingTo,_tar
EM_WATCHDOG_TIMEOUT_DEADA444_XXXXXXX!{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
_Timeout_expired:_event_type_=_TargetStateChanged,_timeout_modifier_type_=_None,_server_task_currentState_=_Showing,_targetSt
MISSING_DUMP_EM_WATCHDOG_TIMEOUT_DEADA444_XXXXXXX!{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
_Timeout_expired:_event_type_=_SystemKeyPressed,_timeout_modifier_type_=_None,_server_task_currentState_=_Active,_targetState
I'm not able to fix them in my app because in Failure Log there is no stacktrace for them and this kind of crashes are not catched by Application Insights.
The EM_WATCHDOG_TIMEOUT_DEADA444 error is a big mystery to everyone.
a lot of developers have them in the dashboard and they are not reproducable, and and they suddenly came when the Dashboard got a mayor update.
The error occurs in all kind of apps; with c++ runtime components and without, in background thread and in apps that do not use background threads at all....
Finally; there is not way to get the stacktrace and there is no way to catch it yourself because UnhandledException event doesn't get hit.
Meanwhile I'm ignoring the error, up until MSFT gives a proper explanation in the dashboard what this error means.
PS: if someone magically knows to solve/get more info out of this exceptions; I would love to hear about it.
Related
I am trying to publish an appx on the Windows Store built with electron-builder.
In the repport, I get this error: Failed to extract imported API information for this application
I have no idea about what this is supposed to mean and I found no documentation about it. I contacted Microsoft Developer Support that just sent me here.
I found this link that mention the issue.
After two days of trail and error we nailed it. It looks like it has
something to do with the lenght of filepaths to contents inside the
app package.
Notice the difference between the cause and the error message. This probably means that this error is just a random generic error that is raised when something happens, and doesn't provide any meaningful information about what exactly went wrong...
The issue is that now, I have absolutely no idea about how to move forward. Any help is greatly appreciated.
The issue is that the WACK tool developed by Microsoft to test the packages sent to the store is crashing if any file complete path is longer than 255 characters, and it returns that random error giving you the impression that you did something wrong on the manifest.
The best you can do for now is to measure the full path of all the files that are going to be packaged into your app and try to rename the longest ones, or try to reach the Microsoft support. It's 300$ / request, but you can get it refunded as it's clearly their own responsibility.
I am using a SAME70 Xplained microcontroller for a project I am working on. I program it using an editor made by Microchip called MPLAB X. About a week ago, suddenly I could no longer upload any code to the board as I keep receiving the error
java.lang.RuntimeException: java.lang.RuntimeException: TransferFault
Resetting the board, uploading different code or using other features in the program to interact with it do nothing. An important note is that when I got ahold of a brand new board of the same type and tried to upload to the board, it actually succeeded the first time. But then for some reason later the same error pops up again. It seems the issue is a bit more than downloading code as the function in the program which allow for uploading code or pausing the controller throw the same error. I have been struggling with this issue for over a week now and cannot use the board because of it. I cannot find any mention of this issue on the internet. Has anyone ever encountered this? Does anyone know the specifics of what a transfer fault is and can point me in the right direction?
I am getting the below exception whenever I am putting a break-point in the script and running it. UFT throws the below exception and asks me to quit or restart the application(UFT). This is specific to a project only and I know this is because of some code changes that I did a day back. Ideally any code change should not impact the functionality of the IDE or the driving application.
We use to get those pretty consistently and it started all of sudden, so we ended up reinstalling UFT.
It was very annoying as we have to stop the development and spend time in breaking the locks in QC and restarting QTP.
So if nothing helps,try doing that.
Check your microsoft script debugger version. Upgrade it and see if the issue goes away
download link here.
https://www.microsoft.com/en-us/download/details.aspx?id=22185
Please accept if this helps.
I am searching for a nice way how to close an WinRT app after fatal error.
This should be used only in last chance error handlers TaskScheduler.UnobserveTaskExcption and App.UnhandledException where I obviously failed to handle it correctly on right places. Should never happen, but...
Desired behaviour: Application should then show 'Sorry' message, log the exception and after user clicks Ok button, app should be closed.
I searched for solutions and lot of results points me, that WinRT must not be closed programmatically. Eg. here programatically close win8 app .
When I call Exit method, app is closed, but afterwards exceptions are thrown, like could not do this and that because app is closing...etc.. Makes me kind of nervous.
How would you solve my problem? It has no sence to keep the app running after unhandled exception, and let it crash by setting Handled = false is not good solution as well I thing. Beside this UnobservedExceptions does not trigger crash. I heard that apps with crashes will be removed from store.
Thx for your ideas!
Referring to the application lifecycle provided by Microsoft, the app should terminate without any warning and return the user to the Start screen.
http://msdn.microsoft.com/en-us/library/windows/apps/hh464925.aspx#app_crash
You should not be closing apps which target the Windows Runtime at all. The app lifecycle management system built-in takes into account many factors including usage statistics and current system resources and will almost certainly make better decisions about when to close apps than you will.
We are using the google-api-client gem in our Ruby on Rails project to access the Google Drive API methods and everything has been working great. However, we are sometimes receiving the following error response from the API when calling the drive.files.update or drive.files.insert methods:
{"code"=>500, "message"=>"Unable to read application configuration information"}
This error is not documented in the list of possible errors from the SDK, so I am not sure how I should go about it. Could you please help?
Thank you!
If this error is transient, the best way is to have a retry strategy when that happens (simply retry the request 2 or 3 times before giving up).
It seems like some concurrency issue on the Drive side where a request to read your application's configuration times out. By experience with Google APIs - and web APIs in general - I can tell you that, even though the team will try to fix/improve these (btw I will repport the bug so they can investigate) errors like that will always happen once in a while even with a very low occurrence as concurrency, timeout and reliability issues on distributed, web-scale systems are extremely hard to resolve. The best to have fail-proof code on your side is to retry a few times on every single 500 and 503 errors from external web APIs.
If you really have time on your hands you could even implement an exponential backoff strategy where the time between each of your retries increases each time as described in our documentation.