I'm using DeviceUseTrigger to get a "near-permanent" connection to the Microsoft Band. Explained in http://www.codeproject.com/Tips/1036512/Achieveing-Indefinite-Background-Execution-with-th
The method, described in the codeproject article, works perfectly in debug mode (without draining the battery). But running my app from the store results in a stopped backgroundtask; Windows 10 mobile stops the task due to some failing OS policy condition.
Does anybody found a workaround for this backgroundtask restrictions?
Microsoft Band does not initiate connections with channel A502CA9A-2BA5-413C-A4E0-13804E47B38F. Given that, we are uncertain what causes such RFCOMM trigger to start the background task.
Overall, today there is no supported way to solve this problem on Microsoft Mobile in RFCOMM trigger way using only the Band. Any successful experiments would hurt the behavior of Health Application.
What can help is any other device opening RFCOMM connection to the phone and a trigger set up for that connection.
Besides that it is not clear what "works perfectly in debug mode" means. When Visual Studio debugger is attached, the background tasks stay, helping the developer. Without debugger they get cancelled by OS.
Related
API Monitor has a feature to automatically watch for a new process starting and ask if you want to monitor it. However I have not been able to get this to actually work. The only option in the program I can find which seems to be related is the File menu "Pause Process Notifications" option. However, this is disabled which gives me the impressions that it can't be turned off but also that it is supposed to work automatically "out of the box". But whenever I start a new process, nothing happens.
Specifically I'm referring to the feature described here:
Process Notification
API Monitor intercepts process creation and allows you to select the
process for monitoring. Each time a process is created by the system,
a notification window is displayed with options to monitor, skip or
terminate the process. This is especially useful for monitoring
processes with a short lifespan or processes that are automatically
launched in the background. Process Notification can also be used to
monitor applications such as consent.exe (UAC prompt), which run on a
different desktop.
The following screenshot shows an example of the Process Notification
window that is displayed when launching an application that requires
elevation
I've tried both the 32-bit and 64-bit versions of API Monitor (Version 2.0 Alpha-r13) running both as regular user and as admin; makes no difference.
How can this feature be activated?
The specific reason I'd like to use this feature is that I have process A which starts process B, and it is B I need to monitor. A and B each run for only a few seconds so I can't manually get it to monitor fast enough.
Finally after reading through API Monitor forums I found some information. Unfortunately (for now at least) it seems the answer is that this feature no longer works (since Windows 8.1).
As posted on http://www.rohitab.com/discuss/topic/40418-process-notification-on-81/?p=10093378
rohitabPosted 11 October 2013 - 03:38 AM
Due to security related changes in Windows 8.1, the Process
Notifications feature of API Monitor does not work. I will try to
resolve this issue as soon as possible and post a hotfix.
But a later update in 2014 indicated that it hadn't been fixed yet, and seems not to have been since then either.
It was implied that running in a Windows 7 (or 8.0?) virtual machine might be a workaround, or obviously finding another tool which has this capability.
Other similar question mostly target Windows XP, where everything was easier. =)
I'd like my application to be able to postpone the windows shutdown transparently, without having windows show this screen:
Is there any option left to me after the Vista changes to the WM_QUERYENDSESSION handling?
The target here is Windows 7 standard embedded on an embedded device that runs only my application. Before shutting down the user needs to perform some manual steps that can not be postponed until the next start and must not be forgotten. I'd like to have the user confirm these steps before shutting down.
I've come to the conclusion, that there is no way to do this. =/
The workaround I've found is to allow shutdown only via the software at opportune moments. The start menu or task manager is not available to the user, and the hardware power button behavior can be configured to do nothing in the systems power options.
Under the current Windows Phone 7 Application Certification Requirements (pdf) applications running under lock must "stop any ... active timers" (section 6.3.1). However looking out on Marketplace there are a number of timer/stopwatch apps claiming to run under lock and also allow lock to be disabled in their settings. How are these apps certified or is there some loosening on the restrictions by Microsoft if the app allows the user to make that decision?
Also some of these apps also suggest they continue even when the app is exited or when the device off. Is it the case that they are not truly running under these circumstances, i.e. the timers either start where they left off when reactivated, or perhaps use the OS time to work out the time elapsed between tombstoning and reactivation? In these circumstance I also presume it is not possible for the app to notify the user when the timer completes?
6.3.1 requires apps to offer the ability to prevent the app from running under a lock screen.
Apps can run under a lock screen by disabling ApplicationIdleDetectionMode.
You can keep track of time while the device is off using the OS time as you note. Peter Torr demoed this with tombstoning state in his WPH305 Tech Ed 2010 Talk.. refer 28 minutes in.
You presume correct that there is no ability to notify the user using client APIs on a timer. The closest you'll get to this is notifications which entails network communication and presumes connectivity.
I'm debugging plugins on Windows 7 and of course the plugin host (Cubase5.exe) occasionally crashes because of errors in the plugin. On XP or Vista, I could always restart it immediately and continue working. But on Windows 7, even though Cubase appears to close, it is still visible in Task Manager and I cannot kill it by any means. After a minute or two, it disappears by itself. In the mean time, I can't work because the plugin DLL is still locked by the process.
Does anyone know why this happens on Windows 7? I've already tried disabling Automatic Error Reporting but that didn't help. I've tried attaching cdb to Cubase, but I get:
Cannot debug pid 5252, NTSTATUS 0xC0000001
"{Operation Failed} The requested operation was unsuccessful."
Debuggee initialization failed, NTSTATUS 0xC0000001
"{Operation Failed} The requested operation was unsuccessful."
I tried following the instructions here but it appears this is only possible if I connect a second machine to my computer to debug it remotely.
I finally found the solution, using this article:
http://blogs.technet.com/b/markrussinovich/archive/2005/08/17/unkillable-processes.aspx
This required installing the Windows Debugging Tools for Windows (nice name) and LiveKd, but by following the steps outlined I was able to track which driver was causing the process to hang: it turned out to be the 64-bit driver for the M-Audio Oxygen 8 V2 controller I'm using. Unfortunately no driver update is available.
Anyway, if anyone encounters a similar problem, this is the way to solve it.
Have you tried Process Explorer by Mark Russinovich? It is really useful for "killing":)
If you have error reporting enabled, it's possible that werfault.exe has Cubase open to write a minidump for crash reporting purposes.
This is just a stab in the dark but it might be your problem.
One thing you can try is to check with Process Monitor what Cubase is doing. Set a filter so that everything with a process name containing "cubase" will be recorded. It could be that you are facing some timeout issue when Cubase wants to exit.
you can end the process the service is running under. You can find this process by going to the Services tab of the Task Manager, right-clicking, and selecting Go To Process(you need to click the Show processes from all users button.). Note that one process may host multiple services (especially if it's svchost.exe), and ending the process will kill all those services. Also, this is an unclean exit, and may cause data corruption depending on what the service(s) was doing when you killed it.
Depending on which specific service you are trying to stop, there may be a cleaner way to simulate failure.
I have a console application (written in VB6 ) which is behaving strangely on my machine. I kick it off from the command line and what should be a two minute job drops straight back to the prompt - if I run this on another machine the executable will sit and wait until the job finishes before returning control back to the prompt. If I check process explorer I can see that the executable is running as a background process and other than this strange background-ness is running as expected.
Any thoughts on why this could be happening? (Running on 32-bit Windows XP Pro SP3.)
It's totally unclear whether this is an application you wrote and have the source code for. If that's the case, you need to get in and start debugging. At the least, use OutputDebugString to send information about what's going on to any number of potential viewers. Taking that a step further, consider rewiring the app using the Console module I wrote, along with vbAdvance to recompile. This combination will allow you the full power of the VB6 IDE to debug within. No more guessing about what's going on.
Then again, if it's not your app, I'm not sure what VB6 has to do with it and wish you the best of luck trying to figure out what's up.
It sounds to me as though the app isn't being recognised as a console app on one of your machines. Console apps weren't officially supported in VB6, although there are some well-known hacks for creating them (particularly the free add-in vbAdvance). Possibly your console app is a bit unreliable? If Windows thinks your app is a GUI rather than a console app, it won't wait for it to finish.
As a pragmatic workaround: try launching with start /wait rather than just using the exename. That forces the command prompt to wait for the program to finish, whether it's a GUI app or a console app.
Sounds like an error is occurring that is being 'swallowed' by the application. Do you have the source code?
Errors in VB6 apps are often due to some COM component not installed and/or registered.
Download SysInternals Process Monitor and this will show up accesses to ProgIDs that fail (uninstalled/unregistered COM components).
Check out: Process Monitor - Hands-On Labs and Examples.
Have you checked permissions? Is the application accessing any network based resources?