I'm trying to debug my Windows Store App when it gets suspended (trying to prevent my server app from kicking my WSA client when it gets suspended and stops responding to keep-alive messages). But Windows keeps terminating my app almost immediately after it suspends it. Is there a way to prevent Windows from terminating suspended apps? I've searched the interwebs and the group policy editor for such a setting, but the best I can find is a setting to prevent it from auto-terminating apps on shutdown, which doesn't help me. And of course running in the debugger and pressing the Suspend button doesn't help either, since the app doesn't actually get suspended. I guess I could hack in some debug code to make it pretend to be suspended, but I'd prefer not to.
The command line tool PLMDebug, which is part of the Debugging Tools for Windows package, can be used to exempt an app from the Process Lifetime Management (PLM) policies. When put into debug mode, an app will not be subject to termination and will not be automatically suspended.
Usage:
plmdebug /enableDebug <PackageFullName> [OptionalDebuggerCommandLine]
Once you've exempted it from PLM automatic suspension and termination, you can use /suspend to force a manual suspension.
Related
I've created an SNMP listener application for one of our servers that runs as a service and passively listens for any SNMP message alerts sent from another server, and when one is received is sends out a page/email to appropriate staff. I followeda few online tutorials for setting up the application as a windows service since it needs to run constantly and won't require input/interaction from a user, or interaction with any GUI/desktop applications.
For some reason, when I install the application as a service, it installs correctly, but doesn't actually seem to be working. When SNMP messages are sent to the server nothing happens. However, in my app.publish folder there's an SNMPTrapper.exe application,and if I run that exe on its own, then everything works fine. For the time being I'm using a workaround so that the Onstart section of the code for the service basically just launches the SNMPTrapper.exe application, and when the service is stopped, it finds and kills the SNMPTrapper.exe process. At this point though, the service itself doesn't seem to be working/doing anything. It's essentially just a way to get the SNMPTrapper.exe application launched.
Does anyone know what the issue may be? In some of the tutorials I've read through they outline how to setup polling intervals for the service, but I don't think that would be applicable since this service will essentially just run constantly to listen for new messages, it won't need to check for anything at a regular interval.
Right now pretty much all of my code is executed in Sub Main() except for a few function calls.
Any help would be greatly appreciated.
You don’t state how you’re doing any of this. For a windows service you get two messages from the system: OnStart and OnStop. The job of OnStart is to set up all the required code to do the job, then exit. It doesn’t take part in the work so you need a Task or Thread setting up to do that. The Task or Thread should loop until it gets a message, passed by OnStop, that we’re done. If you want a service that you can test from the command line then your Main routine needs to do exactly the same setup, then wait for a key to be pressed before sending an OnStop.
(As an aside, you ARE remembering to start the service once you have installed it?)
Apologies, this may not be a good question.
I have a VB based UI application running, supported by C++ modules through COM.
a month before it started to close randomly without any clue. I initially analyzed in perspective of a application crash and expected to see Dumps and Application/System event log entries. I have prior experience in application crash debugging. tried registry configurations (Like, CorporarteWerServer for application hang, LocalDumps and all that).
But no luck.
End user says they don't see any popup like "This application is not responding with options close/wait". The application just closes down without any prompts.
We have logging enabled where we intentionally close the application using exit(). So it is not closing formally.
User does not have testing environment where we can install debugging tools and monitor.
I have verified for insufficient memory and antivirus software and they are fine.
So, Is there any cases where an application can just simply close/crash without any prompts, logs, dumps ?
Please suggest if I am missing something. Also, is there any built-in windows tools to monitor ?
I have an app which can currently communicate with an server.
Imagine the following case:
User hits some buttons which triggers an server request.
The request is send to the server and is processed.
The user hits the home button (and maybe removes the app from the
memory by hitting the home button two times).
The script is done processing and returns it result.
Question: Will the device from the user gets this response (I am pretty sure it will not when removing from memory, but what when just closing the app)?
There are 5 active states in iOS:
Not running: The app has not been launched or was running but was
terminated by the system.
Inactive: The app is running in the foreground, but not receiving
events. An iOS app can be placed into an inactive state, for
example, when a call or SMS message is received.
Active: The app is running in the foreground, and receiving
events.
Background: The app is running in the background, and executing
code.
Suspended: The app is in the background, but no code is being
executed.
On your third scenario where the user hits the home button, the app will be sent into the Background state, #4, and can still receive data and allow your script to run. If the user kills the app, (state #1) your script will not complete running.
So, to answer your question, yes your app will continue executing code if the user places it in the Background state, but not if they close the app because that will put your app in the Not Running state.
Application is suspended (on the background, not running) - In this case the execution of you requests get paused. When your app gets to the foreground, usually the requests end with a timeout.
Application is terminated - in this case the context of your application is lost and after restarting there are no running requests.
That's the 2 cases you should be concerned about. For me it a good solution to cancel all running requests when the application is entering background because it is easier to restart everything when the app gets to foreground again.
Also, you can setup background mode and that enables the app to perform some code when on the background but that's a more advanced topic.
I am looking for a way to monitor the state of one of my applications on OS X. There's a number of components that I need to monitor such as the status of various communication channels. If they go down, the monitoring process should be able to warn the user both on screen and via a push notification.
XPC services look promising, but if the app crashes, I presume this will take out the service as well, or am I mistaken?
My preferred solution is something which would also monitor for unexpected termination, and restart the app if it happens.
What is the best way to do this?
I think monitoring communication channels, etc. must be done by the each specific components (processes). And if the unexpected error occur that component should exit immediately to ensure proper cleanup.
For processe monitoring, below Apple Technical Q&A document will be really helpful:
Technical Note TN2050: Observing Process Lifetimes Without Polling
You could write an app which starts your main application as a child process, and waits for it to exit. It could check the exit code, and then react according to your needs.
This approach is explained here: https://stackoverflow.com/a/78095/785411
To fork() some monitoring process to run your main application as a child process, this is explained here: https://stackoverflow.com/a/4327062/785411
I think you could possibly make use of the built in facilities Launchd and CrashReporter to achieve your requirements.
Launchd is the OS X system supervisor intended for launching and monitoring background processes, and would be typically used to run XPC services. Launchd agents can react to various system events, and can be configured to restart processes in the event of them crashing ( specified via the KeepAlive/SuccessfulExit key in the property list)
Launchd can be set to react to various system events as launch event, including monitoring files and directories, scheduled times, or listening to network connections.
CrashReporter is the OS X system facility that catches and logs all process crashes. It logs through the AppleSystemLogger facility and can be accessed with the syslog tools as documented in the linked TechNote. On Mountain Lion, user process crash reports end up in ~/Library/DiagnosticReports/ , with a crashlog and plist file pair created per crash event.
I think you could use these features in a couple of ways to achieve your requirement, if launchd is responsible for running the xpc services, it can take reponsibility for restarting them on crash events, and they can be dissociated from any app crashes.
You could write a launchd agent that responds to for crash events by montioring the crash report directory (e.g. using the QueueDirectories property) for new logs and re-launches your applicaton, or presents notifications.
If each process runs in its own thread you could run a watchdog program that monitors whether the threads are alive. A script that runs ps in a loop and parses the output could do it.
You can see the various options here. See for example -C to select by command name, and -m to show all threads.
I'm trying to take users of My App to the AppStore for several different functions - like Upgrade to Full Version, Rate/Review or simply View another App I've developed. However, all of these are causing my App to Terminate when iTunes is launched on the device. I'm using some simple code and
have tried many combinations of URLs, all of which successfully get to where they are going. Here are the behaviors:
User clicks Rate App
Code directs them to the web via:
[[UIApplication sharedApplication] openURL:
[NSURL URLWithString:[[MyApp defaultApp] itunesLink]]];
My App goes to the background, and my delegate's applicationDidEnterBackground is called successfully
As iTunes is coming up, my App is terminated. Happens whether I run via X-Code or on the device directly.
When I quit out of the store and look at the running processes on the device, my App is still shown there. I know it has been terminated from X-Code console, and when I try to restart it it starts fresh.
I've tried the itunesLink as either itms://itunes.apple.com/app/ or with http - all of which get to the correct end point. If I use www.google.com it works fine and my App is NOT terminated, just sent to the background and the website is displayed OK.
Other points are that when I run via the simulator, the openURL call returns failure and doesn't open any URL.
Any insights as to why my App would be terminating? It's acting like an iOS security feature or something which is shutting my App down, but I thought what I was doing was pretty standard stuff.
If anyone has seen anything similar, I'd really appreciate advice on the situation.
Your app could be terminated for a number of reasons. The best thing is to look at the device console using Xcode's Organizer:
Your app may simply be terminated as a result of low memory notifications. As soon as it moves to the background and the app store launches (iTunes and the app store both use plenty of memory) it can be killed to free up memory. In this case you will set messages from "jetsam" like this:
<Notice>: jetsam: kernel termination snapshot being created
<Warning>: Application 'UIKitApplication:com.yourapp[0x6337]' exited abnormally with signal 9: Killed: 9
You should use the Activity Monitor in Instruments to see how much memory your application is using. iOS will terminate the most memory-intensive applications first, so you should try to reduce your app's memory footprint.