My background agent is hitting the 6MB memory limit, and I'd like to understand what objects are being allocated.
In principle I can do this using the Visual Studio Windows Phone Performance Analysis tool, however I don't see how I can run this on a background agent, only on the main app.
Anyone know how to run the Visual Studio Windows Phone Performance Analysis tool on a background agent?
If you are just trying to get the background agent to run while you are profiling you can use ScheduledActionService.LaunchForTest like in this question. And here it is noted that it can still take a while before the agent runs.
If you want to test just the background agent outside of the rest of the app I haven't seen a good way to do it. However I would make a make an empty app and have it manually run the background agent functionality. Then you can profile that and it should work well enough.
Additionally here are some links about keeping your memory consumption down in background agents that you might find helpful:
Wp7.5 Mango–Background Agents - Chris Sainty (of gReadie fame)
Optimizing memory consumption for WP7 Background Agents - Oliver Weichhold
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.
I am developing a Windows Phone 8 app that would have a live flip tile. I will be creating a scheduled agent (periodic task not resource intensive) which will update the live tile using local data.
The whole app does not connect to the internet in any way, it uses only local data. So push notifications are out of the question.
I need to update the live tile from the background agent and/or from the foreground app when it's launched whichever happens first.
However how can I ensure the foreground app and the background agent do not step on each other's toes? I have two main options to do this :
Use a mutex (AFAIK the background agent runs in a different process so locks (monitor that is) is out of the question). But I'm afraid it would have a high performance cost (obtaining and releasing the mutex, that is).
When the foreground app starts I would always remove the agent, do its work and reschedule the agent back. Theferore there would not be any chance of overlapping between the foreground app and the background agent, BUT the whole add/remove agent could also be lengthy and, furthemore, the user might close the app after this removed the agent but before it added it back.
I am really torn between these two approaches and can't tell which would be best.
PS : You can't reschedule an agent from the agent's own code, right?
Mutex
The mutex option is officially recommended by the MSDN documentation for both Windows Phone 7 and 8.
I have used this option and experienced no noticeable performance problems when sharing data between the Background Agent and Foreground App, and I target WP7.1 and test on 1st and 2nd generation WP7 devices (LG E900 and Lumia 800).
Obviously, when using mutex, the key is to lock the resource for as short a time as possible. And when trying to acquire a lock on a resource in a Background Agent, the timeout feature of WaitHandle.WaitOne is very useful as the Background Agent only has 25 seconds to run.
NOTE: If you are targeting Windows Phone 8 only, or via a 2nd project/binary then a different approach (named events for inter-process-communication) is available. Peter Torr wrote about it on the official Windows Phone Developer blog.
Enabled/Disable Background Agent
The second approach you mention is riskier because the we don't know what guarantees the OS gives for adding or removing of the Background Agent - what happens if removal if not instant? what happens if a newly renewed Background Agent fires while to Foreground App is running? etc.
Agent Renewal
Background Agents cannot renew themselves - once added, they will run for a maximum of two weeks unless renewed by the Foreground App. This will prevent Background Agents running for apps the user no longer uses.
I'm currently working on writing a load testing application that takes advantage of Load Test using Visual Studio 2010. The load test will simulate 20 users on the same machine, and I need some data to be shared in-memory between all simulated users.
I was suprised I couldn't find documentation answering the following question:
What seperates each virtual user's running context from the other? Does each virtual user runs the tests in its own process? Maybe in its own app domain? Or just on its own thread? I need to know because if each user is running tests in its own process then all the in-memory cache isn't shared and is created for each user instead of one time for all of them, which is bad for me.
You can use Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653 it’s an advanced version of Task Manager) to get the answer.
Run a Visual Studio Load test and open Process Explorer. Check for new processes are being created. Then find the Visual Studio process and double-click. Then select the .NET Performance tab and it should show the list of all AppDomains in the process.
Incidentally, today we released a Fiddler Extension for load testing called StresStimulus - http://stresstimulus.stimulustechnology.com. Where we keep all virtual users on different threads in the same process.
This is the closest to an answer that I have found so far.
http://blogs.msdn.com/b/billbar/archive/2007/06/13/coded-web-tests-and-web-test-plug-ins-should-not-block-the-thread.aspx
The answer being that there is a single process per machine doing the load tests, multiple threads are used, but the virtual users are "optimised" to work many per thread.
With regards to what you are wanting to do, creating a static class with a static constructor will get a shared block of memory between all virtual users. The caveat being that this is a multithreaded environment and the appropriate caution should be taken with your code.
happens to me occasionally:
I start my program in visual studio and due to some bug my program goes into 100% cpu usage and basically freezes windows completely.
Only by utter patience requesting the task manager (takes forever to come up and paint itself) I can kill my process.
Do others encounter this too sometimes? Is there a clever trick to get this process down (other than pulling the plug and possible ruining files on the HD)? It now takes 5-10 minutes to kill it properly if the task manager is not accidentally present and I have to request this first
R
p.s. weird that a 'multitasking os' can still allow processes to eat up so much time that nothing else can be done anymore. My program doesn't even bump up it's thread priorities or anything
Check out Process Lasso
"Process Lasso is a unique new technology that will, amongst other things, improve your PC's responsiveness and stability. Windows, by design, allows programs to monopolize your CPU without restraint -- leading to freezes and hangs. Process Lasso's ProBalance (Process Balance) technology intelligently adjusts the priority of running programs so that badly behaved or overly active processes won't interfere with your ability to use the computer!"
http://www.bitsum.com/prolasso.php
I am not affiliated with Bitsum, just a user of their product, and it helps me solve this type of problems.
For what it's worth, I've never see this on either XP 64 or Vista 64, developing C++ apps in Visual Studio. Perhaps an OS upgrade is in order?
Edit: I use Process Explorer as a replacement Task Manager - it wouldn't surprise me if it did a better job of appearing in good time even when there's a rogue process running. And you can use it to boost its own priority.
I usually hit ctrl-alt-delete start the task manager sort by cpu find the offending process and right click and end the process..
task manager usually has enough priority to do this although it may be slow.
I think a shotgun to the head is the only way to be sure.
I generally don't see anything like this happen strictly as a function of an app that's eating 100% CPU. As part of stability / performance testing, I've gotten apps to cause Windows to get very slow, but this is usually done by writing heavily threaded apps (thus causing the O/S scheduler to thrash), or by writing apps that consume all available system memory or resources (much more impactful to the GUI apps than simply one thread that consumes its full share of processor time during its slices).
You say you get this behavior under Visual Studio? VS has a "Pause" button...
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?