I noticed that some common commands(ls, cat, touch, etc.) run very slow on my Mac. I couldn't find out why. So I use top to monitor cpu usage after I run some program in a terminal. I found that no matter what program I am running, a process called automountd pops up immediately and starts using lots of cpu (60% - 70%). I feel this might be the cause. If so, why this happened? What should I do?
Edit: I've confirmed that automontd/autofsd slows down my command line. After I kill the autofsd, ls and other commands become responsive. But disabling autofsd doesn't seem to be a perfect solution, so I hope someone can shed some light on this.
Related
While I'm using my computer a blue window will pop up for a second then go away. The label said windows power shell, I've tried looking at the event viewer but I could not identify anything there since I'm a new user. What could be causing this?
Running windows 10
Sometimes installed programs open up command prompts to run services/init tasks, so its not completely unusual.
I've never seen it happen with powershell however.
it could be innocent and just a program you have installed running init behavior, but it could also be malicious.
the first thing to try is checking what programs are set to startup automatically. if there is a load of bloat, you could try turning off the unnecessary ones and see if it still happens.
but realistically the only real way forward is to get a good quality antivirus, and run a full system scan over your pc to double check. it wont give you 100% certainly as things could possibly get passed it, but realistically if it passes you should be fine
I have a new Win10 laptop. I've installed lots of software, including a 25-year-old Codewright editor that I've customized up the wazoo, and that I've been installing on all my machines for, well, 25 years. After working for a few days, it suddenly stopped, and reinstalling it didn't fix it. On startup, it puts up a small splash window, and normally opens the main window a half a second later (that took more than 5 seconds 25 years ago). It's not using any CPU, and there's nothing I can do but kill the process.
In the past, I've occasionally got my system into a state where Codewright would hang on loading, due to some other program that hadn't terminated correctly, and it was unfrozen by killing off that other process. So that's reason to believe that Codewright is waiting at some global lock which some other malfunctioning software is holding. So I have two questions:
Does this ring a bell? Is there some known failure mode where a program putting up a splash window then switching to another window can be prevented by something else going on the system?
Is there a way to diagnose this, perhaps by finding out what system call it's hanging inside? I tried dtrace.exe, started Codewright, and then stopped tracing, and it produced a 3GB XML file, which is quite a haystack. There's a way to filter it by PID, but since this is a startup problem, I have no idea what the PID will be. Is there a better tool for doing this, or some more appropriate dtrace feature that I missed?
The comment about using the Task Manager to create a dump file actually led me to notice that there is an Analyze Wait Chain function there that I had never seen before, since I haven't used Task Manager much since I switched from Win7. This gave me exactly the answer I wanted. My editor was waiting for something that was being held by some NVIDIA GeForce Experience module. Since I don't use that, I uninstalled it, and I'm back up and running. Thanks for the tip.
I have a program that runs under windows. I only have the binary and no symbol information, and I have VS2008. When I run this program, it hangs for around 60 seconds doing something, and I would like to understand what it is doing. Under Linux, I would use ltrace, strace and gdb, but on Windows I have no experience whatsoever.
I found Process Monitor to solve my problem. It's a very nice program with great filtering capabilities.
On a clean installation of Octave 3.6.4 for Windows MinGW on a Windows 7 machine, octave takes around 30 seconds to start every time. From what I have seen elsewhere, this is far from normal.
By "take 30 seconds to start" I mean from the time that I enter octave on the command line or initialize the octave.exe executable, it takes consistently 30 seconds to give the octave:1> prompt. Otherwise, it runs quite quickly, start-up is just agonizingly slow.
Something possibly relevant is that when watching resource manager, the octave process first peaks quickly in CPU usage as soon as it is called, then totally disappears in terms of CPU usage, than peaks again as it finally comes up.
I have searched for any other instances of this happening, and was unable to find any. This happens without loading any packages.
I'm guessing that your command prompt is starting octave at a very slow rate. Personally, I prefer using Console2 as an enhancement for the command prompt as you can set a path of the octave.exe and have it automatically load up in the window once you start Console2. It also gives you other additional features. This might or might not fix your slow start problem but I think it's worth a try:
http://robertcorvus.com/how-to-run-octave-in-console2/
I tried to wrap a little command in a batchfile to prevent me from typing it the whole time. But the result was a mess! I'm ended up with thousands of cmd processes and was unable to stop it with CTRL+C
The command was quite simple START iisreset
System Win7 64bit
Why is that happening?
EDIT:
With some help and additional tests I can now say that the Batch command START within a *.cmd file cause that mess. It opens a new commandwindow with every window until it crashes. Maybe you have luck and hit CTRL-C exactly the right time, but that really has to be luck. Anyway I will not use this command in future and it also seems not to be applicable to all machines. (Read the comments for full history of this)
It works OK on Windows 7 pro, 64 bit, but based on the other stuff you've tried, it looks like it might be a bug... You could try raising a bug report
(although that seems like a non-trivial exercise).