I've got an Adobe AIR application written in pure AS3 that has some functionality that happens when the user is idle and then returns to the normal state when the user returns. I'm detecting this activity with the following code:
NativeApplication.nativeApplication.idleThreshold = 180;
NativeApplication.nativeApplication.addEventListener(Event.USER_IDLE, onUserIdle);
NativeApplication.nativeApplication.addEventListener(Event.USER_PRESENT, onUserPresent);
The onUserIdle method is called after 3 minutes as it should be, but then the onUserPresent event is fired almost immediately afterwards. I'm talking milliseconds later. This happens without any user input whatsoever. The bizarre thing is that this does not occur on Windows - only on OSX. And it happens on all flavors of OSX going back to 10.6.3.
Adobe's documentation is incredibly vague on how those events are determined, so I'm not sure if there is something I can do at the system level to fix the problem. Does anyone have any experience with this issue, and if not, any other suggestions on how I can detect user idleness even when the app does not have focus?
Just to preempt the suggestion, I cannot use mouse/keyboard listeners to simulate the same behavior because they do not work if the application loses focus, whereas the NativeApplication events still fire. I've also used NativeProcess to get the output of ioreg to get the hardware idle time as reported by the system, but it does not appear to be affected by the mouse.
I really appreciate any assistance.
Edit: I just discovered that this does not occur when the application is run in an Administrator account on OSX. It only happens in a User account, which only serves to confuse me more.
I figured out what the issue is. When the USER_IDLE event is fired in a user account, we did several things - one of which was forcibly kill the Dock in order to make sure it was hidden from the screen. For whatever reason, this resets the internally available idleThreshold count. This was not only happening in AIR - it was also happening when monitored through Terminal and it appears there is absolutely nothing that can be done to stop it. The solution was to stop killing the dock. Everything magically worked after that.
Related
I want to capture a stacktrace of an application which sometimes stops responding for few minutes.
When the application stops responding, the windows desktop also stops responding to mouse clicks, although some other already running applications are working fine at that time (for example windbg works fine, ProcessExplorer refreshes its screen, but does not respond to mouse events).
While the application is non responsive, it is actually taking about 80% of one CPU core. That is why I would like to get a stacktrace.
The misbehaving application usually takes about 2-3 minutes to do its strange job or if Ctrl+Esc is pressed it becomes responsive immediately (and the start menu opens of course...)
I have WinDbg attached to the misbehaving application and when I issue the Break command, the break-in does not happen until the application starts to respond again.
From what I understand the break-in actually creates a remote thread which pretty soon calls DbgBreakPoint.
What could be preventing debugger's thread from executing?
EDIT:
First of all thanks for your help!
I was also thinking that this might be caused by a bad device driver or something that installs a system wide hook somewhere.
I was thinking to enable kernel debugging and get a stack trace from the kernel for the offending thread or enable manual bluescreen trigger to produce a dump and look at that afterwards.
Process Explorer and Process Monitor does not reveal anything interesting. They also become unusable when the bug is triggered (updating their windows but not responsive to mouse or keyboard).
EDIT2:
Background info:
App uses QT, OpenGL and also DirectSound and runs on Windows 7 SP1 x64
I am currently suspecting something with the graphics part.
The strange thing is that if a system-wide lock is taken (like GDI Lock), this would prevent drawing of other Windows, but that does not happen. WinDbg on same machine works fine. ProcessExplorer updates but does not receive mouse clicks, Desktop updates but no mouse clicks.
I currently have a kernel debugger attached...
EDIT3
ETW was most useful for debugging. It turns out that Qt's main event processing loop goes crazy. PeekMessage and MsgWaitForMultipleObjectsEx (with 0 timeout) gets called in a tight loop. That is where the high CPU usage comes from.
It looks like the App is generating/getting loads of messages at that time. But it is not easy to see what the messages are (or I don't know how to access function parameters in ETW). Using a debugger also does not help much but, with a breakpoint in the QT's event loop leads me to believe that WM_TIMER messages are the culprit.
Given that the desktop also misbehaves during this time, it sounds like your app isn't necessarily misbehaving but merely aggravating a bug elsewhere (e.g., in a device driver or some crummy anti-malware code that has injected itself into other processes). Stack traces from your app may or may not be very revealing.
If the problem is easily reproducible, I'd set a breakpoint somewhere in the "middle" of the app and see if the problem happens before or after that. Then move the breakpoint until you find the last instruction your app executes before things go bonkers. Figuring out what your app does that triggers this behavior may give a clue as what's going on.
Another option is to try using some system-wide debugging tools. First, I'd peak in the Event Viewer to see if there are suspicious error or warning events posting in proximity to the moment the machine goes haywire. Then I'd try a tool like Sysinternal's Process Monitor or Process Explorer to get a better view of what's happening. You might also try ETW to capture a system-wide trace of what's happening on the system that you can study after the fact. (ETW can be hard to use, so check out Bruce Dawson's UIforETW.)
Use ETW to find the cause. Install the Windows Performance Toolkit (part of the Win10 v1511 SDK: https://go.microsoft.com/fwlink/p/?LinkID=698771 which is the last version that works in Win7), run WPRUI.exe, select CPU Usage and click on Start.
After you captured the hang, click on Save. Wait until WPRUI is finished, open the ETL in WPA, setup and load debug symbols in WPA.
Drag & Drop the CPU Usage (Precise) graph to analyse pane and look for WAIT (µs) max for your process to see that long hang and expand the stack to see where it happens.
I have a graphics application that occasionally displays incorrectly after a sleep / wake cycle.
I'm wondering if there is something I should do on the Sleep or Wake events. I'm capturing these events already, because I hide the cursor in the app, and when the app wakes the cursor appears and has to be re-hidden. I'm creating my images with [[NSBitmapImageRep alloc ]initWithBitmapDataPlanes:outplanes, doing lots of bit manipulation on multiple images. I display the image full screen. Xcode 7.1, OSX 10.10
The error I get is a shimmering on the display as if my merge routines are using the wrong data.
I was assuming the sleep took a snapshot of all my data, including whatever is on the stack? It's hard to reproduce the problem, but my App is going to be running every day in a public space and uses the scheduler to sleep each night and autowake in the morning.
Should I reinitialise all my variables on a wake?
I can't see anything on the apple docs about actions you should take on these events.
It should not be necessary to worry about this. If it is, that is likely to be either a bug in your app, or a bug in Apple's code. Indeed, the cursor issue you mention sounds like a bug to me, and you should log a bug in Apple's bug reporter about that. Sleep/wake should be entirely transparent for apps that don't have a specific reason to care. You will need to try to pin down the issue you are seeing, somehow, and diagnose it.
I just had an app rejected because I have a user changeable setting which allows the user to disable screen lock via
[UIApplication sharedApplication].idleTimerDisabled = YES;
Apple says I used an undocumented API but it IS indeed documented here: https://developer.apple.com/library/ios/documentation/uikit/reference/UIApplication_Class/index.html#//apple_ref/occ/instp/UIApplication/idleTimerDisabled
My app graphs the barometric pressure and if you want the graph to run longer than a minute or two, it is important to disable screen lock. The default behavior is screen locking as usual, but there's an option in the settings to disable screen lock and this seems to be what Apple took issue with. I've had academic users request this feature, and I have used it in other apps successfully, however this time Apple rejected my app for using it. Is this normal? Is disabling screen lock via UIApplication really now allowed?
I am not sure but I think the issue is that note under the important heading with the documentation you shared;
"You should set this property only if necessary and should be sure to
reset it to NO when the need no longer exists. Most apps should let
the system turn off the screen when the idle timer elapses ..."
You should write into resolution center and confirm this;
We use that capability to prevent idle sleep when we are updating the firmware on a BlueTooth device. Immediately upon completing the update, we restore idle timeout. Apple never said a thing to us about it.
However, in your case, there is no technical reason to disable the idle timer. Your data collection is not going to fail because the system went idle. There is no adverse or unusual customer experience going to be had. That is probably what Apple took exception to.
Three possible paths exist:
1) Gather your data at intervals in the background while the system is idle and update the graph when the app again comes to the front.
2) Add messaging to your app to tell the user that if they want continuous display, they will need to change the idle timeout period in system settings. (With caveats about impact on battery charge duration.)
3) State your case to Apple.
I would go for both 1 & 2
I need to starting my app when our USB device connected.
My first attempt at this is a background application that pays attention to when USB devices are plugged in. When it notices our device connected, it calls ShellExecute( ) and starts our application.
This works nicely except in Windows 8. Supposing we're on the "Start" screen in Windows 8. In that situation, the application starts in the background and the start screen remains in front.
I think this is a "focus" problem since what I'm actually hoping to do is "steal focus" from the Start screen.
http://blogs.msdn.com/b/oldnewthing/archive/2009/02/20/9435239.aspx
Since my background application doesn't have focus (the Start screen has focus; besides, my application doesn't have a UI), it can't give focus away to my foreground application.
Let me say that in general, I hate focus stealing. Starting the app the user wants to use is a great help to our users.
How can I fix this problem? Maybe the answer is to programmatically ask the start screen to start my app but I don't see a way to do that:
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/9ed23f32-0708-48a8-9ff7-5fce6dbe123f/windows-8-start-screen-api
Maybe I'm approaching this in the wrong way. Suggestions?
You're going about this the wrong way. Although you can write a program to constantly monitor the USB ports to detect when something is connected, there's no need. The OS is already doing that anyway.
Register an Autoplay handler for your device type and class. This is distinct from the old AutoRun feature, which would automatically execute programs found on an inserted file system.
You can begin with an overview of the feature from the November 2001 issue of MSDN Magazine.
Your handler will be a COM DLL. You can register the DLL as a handler, and register the handler with events you want to handle. You can either perform everything in the DLL, or you can put the bulk of the functionality in your application and just use the DLL as a proxy between the OS and your program.
On Microsoft website I saw this:
What does it mean when a program is not responding?
If a program is not responding, it means the program is interacting more slowly than usual with Windows, typically because a problem has occurred in the program. If the problem is temporary, and if you choose to wait, some programs will start responding again. Depending on the options available, you can also choose to close or restart the program.
On Windows 8, how do you DISABLE "the options" so that users of my application do not see the options to restart my app?
I'd suggest changing your application's design so that this situation doesn't arise. "Not responding" afaik means that the thread with the main message pump is not fetching messages. This is not a good thing to allow to happen.
It's better to do things that will take a long time in a separate thread, and keep responding to the user in the meantime (even if this just means asking them to wait and keeping a dialog responding to mouse events etc).