So we are running a Pandora on a specific pc to feed music to our phone lines. Every so often the program times out with "Are you still listening" or " Cant connect to the internet". In both instances all we need to do is to click the radio button and it resumes fine. The problem is as it only feeds the phone lines we never know when it has hung.
Currently I am closing and restarting Pandora thru a task at timed intervals. But as those conditions happen randomly as far as I can tell I still end up with no music for 1/2 to 45 min.
However in both instances when that occurs the Processor and memory usage is "0%". So what i think I can do is check to see if the Memory and processor usage both = 0 and if so I can then close and restart the applet.
I have tried several power-shell and bat scripts but I have not been successful.
Can anyone assist?
Thanks
-EDS
It is not circumventing business licensing. We are a paid subscriber.
Related
I have a simple batch script running constantly on a Windows 10 PC at work that performs relatively simple tasks over and over again throughout the day, basically testing certain server diagnostics while I'm working on it.
Every once in a while, the program will crash, so I have another program I downloaded that will auto-start up the program if it does crash and close.
However, there is one scenario where instead of the program just crashing and closing completely, a message box will pop up saying the program has stopped responding, with a 'Close Program' button. In this case, the auto-start program I have thinks the program is still running, so it won't attempt to re-run the batch script.
Is there a way to auto close the program when it crashes this way, or something that will automatically click the 'Close Program' button for me when it appears?
I suspect the messages comes out when the main thread hangs for too long. It may be cleaner to spawn another thread to take care of expensive / slow computation, Windows should not bother to kill the main thread (and your program) in first place like that.
I currently run a 64bit Windows 10 development box. I have old VB6 source that I have to unfortunately keep updated for the time being. For some reason all the sudden I noticed that one of the applications I have just built seemed to stay running in the background after the GUI was closed.
I started debugging the issue more and more until I found out that the only time it would seem to persistently stay open in the background after the GUI was closed was if I clicked the button on my form that would call the Common Dialog control to show the file open GUI. I only have to show the file open window and then hit cancel for this to happen.
This ONLY seems to happen on ONE of my dev machines (not the other). Every time I use that CD file open box I have to open task manager up and end the task. I also tried to make sure all forms were closed when my main form starts to Unload. Nothing seems to work or shed any clue on what the issue is. I have also double checked that the following files are now all the same coping them from the known working dev machine to my broken one and re-registering them.
COMDLG32.OCX
comdlg32.oca
comdlg32.dll
COMDLG32.DEP
Both machines are running the same exact OS Win10 Pro 64bit.
That does sound strange, getting different results on the two machines. Pragmatically, you can work around the problem (without actually understanding it) by making sure that you execute an End statement. (You can put it in the QueryUnload event to make sure it's hit if the user clicks the "X".)
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've got a legacy VB6 application that runs on over 200 machines,mostly Windows 10 but also some 7 and 8. Its working great on the vast majority of computers but it randomly crashes on a small number of Win 10 systems. Randomly = between 1 and 5 times a day.
By crashing I mean it simply freezes. No other message. Nothing in the event viewer. The screen does grey out.
The crash occurs when a user clicks a button. Not the same button each time. The code behind the button(s) could be anything from opening a help form to running a search on an SQL Server. There is no consistency. I don't believe its actually the code causing the issue.
When I analyse the wait chain its always csrss.exe.
csrss.exe has been scanned to ensure its not a virus. Its clean.
I know csrss.exe is something to do with the Windows sub system but its beyond my knowledge at the moment.
I'm looking for any help, ideas on the next step to finding the problem and of course curing it.
Thanks in advance
Sam
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).