I have a Window Forms application (using clickonce installation, running on a terminal server) that occasionaly ends up with a thread that appears to be running in a tight loop. The user doesn't know this happens as the app continues to run as expected. Also I have determined that I can kill the problem thread without any apparent affect on the app.
I can use Process Explorer to find the instance of an app with the problem and can isolate the thread with the problem but haven't found any way to look into the thread to find anything that would help me determine what is causing the problem. Does anyone know of a way to some additional information about a thread, like maybe strings, that would help me zero in on the issue?
Thanks,
Dave
Haven't tried this myself but "Process Monitor" claims it "shows real-time file system, Registry and process/thread activity"
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Hope this helps.
You should be able to attach Visual Studio to the running process to get more information. Provided the .pdb files are included with the application and you have source code for the avialable version you should be able to use the Threads window combined with pausing / stepping through to see just what the code is doing.
Related
I have a problem trying to schedule a task with Automation Anywhere 10.5.
I've actually activated the Auto login option at AAE Client but when the computer is locked and the task is suppose to start the computer doesn't login and the task starts normally as in background without unlocking the computer.
The problem with it is that we can only run tasks that normally would run on background (tasks that don't need to activate windows and perform operations like clicks or object cloning).
Example: I schedule a task that shows a simple Messagebox but when apparently it doesn't run. Then, I log in to the computer and I can see the messagebox active.
Do you know how to solve it?
My team has hit a few snags on this previously. If you haven't solved this yet - please utilize the following link:
http://www.automationanywhere.com/techsupport/Customers/Support/Utility/Autologin_Diagnose_Fix_Utility.zip
I received this from an AA employee as well as a best practice document. The utility tool should alert you of any practices you're not currently adhering to and resolve them if it can.
Please let me know if you need additional assistance.
My program checks if there is a new version of itself. If yes it would exit and start an updater that replaces it and then restarts.
My problem is that I haven't found any info on how to make process start right after closing the actual program.
Any suggestions?
Thanks in advance
I intended to add a comment, but I'm too low in points here. The updater itself should probably contain a check to determine whether your application is running an instance, and it should contain a timeout loop that performs this check and factor the timeout following it's startup state. That way you can awaken it, and close your application. The updater should just determine your application is not running, compare versions perform the intended update operation.
a possible solution would also be to create a task via tash sceduler or cron job, starting an out of process application, like CMD.exe.. which brings me to my original comment-question: in regards to what Operating System(s) and Platform(s) is your program intended for?
So I am trying to keep my Node server on a embedded computer running when it is out in the field. This lead me to leveraging inittab's respawn action. Here is the file I added to inittab:
node:5:respawn:node /path/to/node/files &
I know for a fact that when I startup this node application from command line, it does not get to the bottom of the main body and console.log "done" until a good 2-3 seconds after I issue the command.
So I feel like in that 2-3 second window the OS just keeps firing off respawns of the node app. I see in the error logs too in fact that the kernel ends up killing off a bunch of node processes because its running out of memory and stuff... plus I do get the 'node' process respawning too fast will suspend for 5 minutes message too.
I tried wrapping this in a script, dint work. I know I can use crontab but thats every minute... am I doing something wrong? or should I have a different approach all together?
Any and all advice is welcome!
TIA
Surely too late for you, but in case someone else finds such a problem: try removing the & from the command invocation.
What happens is that when the command goes to the background (thanks to the &), the parent (init) sees that it exited, and respawns it. Result: a storm of new instantations of your command.
Worse, you mention embedded, so I guess you are using busybox, whose init won't rate-limit the respawning - as would other implementations. So the respawning will only end when the system is out of memory.
inittab is overkill for this. I found out what I need is a process monitor. I found one that is lightweight and effective; it has some good reports of working great out in the field. http://en.wikipedia.org/wiki/Process_control_daemon
Using this would entail configuring this daemon to start and monitor your Node.js application for you.
That is a solution that works from the OS side.
Another way to do it is as follows. So if you are trying to keep Node.js running like I was, there are several modules written meant to keep other Node.js apps running. To mention a couple there are forever and respawn. I chose to use respawn.
This method entails starting one app written in Node.js that uses the respawn module to start and monitor the actual Node.js app you were interested in keeping running anyway.
Of course the downside of this is that if the Node.js engine (V8) goes down altogether then both your monitoring and monitored process will go down with it :-(. But its better than nothing!
PCD would be the ideal option. It would go down probably only if the OS goes down, and if the OS goes down then hope fully one has a watchdog in place to reboot the device/hardware.
Niko
I know the calls are going out, as I've used an incremented variable to track it. But some just never make it to the output window. Is this a known issue? Is there a workaround?
Similarly, breakpoints in the workflow are very unreliable. Stuck with this?
For brakepoints to work you need to make your workflow project the startup project. If it's a dll use the debug startup application to get it running.
No clue about the Debug.WriteLine. Could it be the trace listener is dropping data because of multi threaded locking?
On the issue with break points not being hit, it usually is because the refactoring folder (obj folder) is out of sync with the workflow designer. One way around this is to close Visual Studio completely (all instances if you run several like me), then in Windows Explorer navigate to your project folder and delete the obj folder. Then open up your solution again and do a re-build.
I've had that happen to me several times, and the way around it was the above trick.
This isn't strictly a programming question, but hopefully someone here has the knowledge to help me.
Running Vista x64, the "Open File With" dialog takes forever to appear when trying to open a file with unknown type.
To be specific, the prompt giving the choice between "Use the web service to find the correct program" and "Select a program from a list of installed programs" appears immediately, but there is about a 10 second delay between pressing OK here and the next window (with a list of installed programs) appearing.
The same delay is present when I run "rundll32 shell32.dll,OpenAs_RunDLL" from a command line.
I'm guessing that this is not common behaviour, because I find it incredibly annoying, and I couldn't find any mention of it anywhere.
So..does anyone have any ideas what it might be? Or what I could do to try and find out?
VonC could be correct.
Read this article:
http://blogs.technet.com/markrussinovich/archive/2005/08/28/the-case-of-the-intermittent-and-annoying-explorer-hangs.aspx
You should use process explorer to watch the stack when you initiate the action. You should be able to tell what sort of operation is timing out.
Download process explorer here:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
You could check if you do not have have network connection declared (net use), or more generally any network paths which may be used by your list of program listed to "Open File With".
If a network path is unavailable, a 'timeout' delay can affect the GUI responsiveness, especially if that GUI must explore/list those paths.