I'm running vnc into a server at work. It runs and doesn't crash, and I am able to use the terminal and whatever else, but the mouse stays in a circular 'thinking about it' state and I see the following at the bottom in the taskbar.
Anyone else who uses vnc to access the server sees the same behavior. Does anyone know a possible cause? Can provide more details if required! Just wondering if anyone has seen similar.
It appears as if the window list program was the culprit. Somehow it got stuck in a loop opening itself, and when closed, would reload itself almost immediately. Forcing a stop by killing the process(es) and denying a reload, and then rebooting the machine worked for me.
ps -ef | grep wmctrl
kill INSERT_PID_HERE
Related
got a weird question which I haven't been able to find an answer to online so I'm trying my luck here.
I have a normal erlang application using wxWidgets, once I try to shut down my application I get the event that the wxServer has indeed entered the event which is connected to the window closing, I get a message that it is in the process of exiting, and my window does indeed close, but as shown in the picture below, the beam.smp on my toolbar doesn't close at all, I have to manually force the closing of the beam.smp file which sends a SIGTERM to the erlang terminal which also shuts down my erlang VM (which I have to reboot it later).
long story short, what am I missing on my close window event so that everything shuts down nicely without it crashing my erlang VM? I was able to read that wxWidgets behaves differently on macOS but I haven't been able to find how to correctly close the application.
handle_event(#wx{event = #wxClose{}},State = #state{frame = Frame,panel = Panel}) ->
io:format("Exiting~n"),
wxFrame:close(Frame),
wxFrame:destroy(Frame),
wx:destroy(),
{stop,normal,State};
You can close the emulator from code with init:stop/0,1
Also, if your application is started as permanent, it should suffice with terminating that application. Check the behaviour in erlang:application
Whenever UwAmp restarts itself (for example, when I modify php.ini or switch to a different version of php) it often crashes whatever Chrome pages I have opened, whether they are pages that I'm testing on UwAmp or something completely unrelated like Facebook. They go blank and I have to reload them. Sometimes it closes Chrome altogether, I have to restart it and I get the message saying that Chrome closed unexpectedly. What gives? Is this a known bug? Is there any way to prevent it? How and why does UwAmp even have control over Chrome? This is on Windows 10 x64, UwAmp 3.1.0, latest 64-bit Chrome.
Thanks!
EDIT: It just closed Notepad++ on me, so it's not specific to Chrome. There's also a message that pops up sometimes within UwAmp, saying that the process couldn't be killed because access was denied. Maybe UwAmp is trying to kill the wrong process? It also happens when I manually click the "Stop" button.
That's an issue I encounter too. If I exit UwAmp, sometimes it force closes another program (Firefox, qBittorrent, Spotify...)
I had reported this issue to the developer, but got no reply.
So, I guess we'll have to live with it.
When you start your session/computer, open first all the other softwares you wish to use (chrome, firefox, aBittorrent, Sportify or whatsoever). Then at the end, open uwamp.
It shouldn't crash down other softwares when you stop/start apache/mysql, or when you close down uwamp.
A workaround is to open uwamp.ini and change the AUTO_RESTAT_CONFIG_CHANGED to "0".
This will disable uWamp's auto-restart feature during server configuration changes.
This might be silly. When my process crashes, a WerFault.exe has been launched and I can regain control only after I close this window or kill its task.
I'm looking for a simple way of not letting crashed program show this window or any idea for me to catch this crash.
SEH is not useful, by the way. I'm not sure why. The crash also remains when I use SEH.
Thanks!
Now I'm just figuring out how to avoid this WerFault.exe windows and sometimes csrss.exe window and regain control.
Use the Application Recovery and Restart API to have Windows Error Reporting (WER) restart and recover your app when it crashes. Use RegisterApplicationRestart() to register your intent to be restarted. Use RegisterApplicationRecoveryCallback() to register your intent to save and recover state data.
I have not tried this but this api : WerAddExcludedApplication should disable error raporting: http://msdn.microsoft.com/en-us/library/bb513617%28v=VS.85%29.aspx
As for restarting your app, you could create another background process that will start your main process and monitor how it behaves. If it crashes then restart it.
[edit]
unfortunately this api might not work, as suggested in comments to it - to remove this dialog your will have to FindWindow() and SendMessage(... WM_CLOSE...).
I let me Parallels Desktop running Windows XP to start automatically during mac log-in. And to start Windows upon launch to let my dad use his WinXP by just pressing the power button, bypassing the Mac login window and desktop completely. When he shuts down Windows, Parallels closes.
I seem to remember I have a trigger to shut down mac as soon as Parallels closes. But I don't remember where... I have an AppleScript that tells Finder to shut down. I understand that. But now the problem is Mac shuts down AS SOON AS it boots up every time! I can't figure out what's triggering the shutdown... And I've run out of places to look.
It seems like a normal shut down rather than a fatal error. Seems like someone has chosen the 'Shut Down' command as soon as Mac starts up. So could mac gurus suggest places I should look -- what might have triggered this -- I'm pretty sure it's Parallels-related. Maybe there is something in the Package Contents linked to the shutdown script??
You added the Applescript (that shut down the mac) to login items
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.