My hard drive is at 100% in Task Manager.
I disabled Windows Search and Superfetch and hard drive is still at 100%.
I am using Windows 10.
Any suggestions would be helpful.
Update: Task Manager won't show what process is clogging up hard drive at 100%.
Task Manager won't show any processes that use up a lot of percentage of hard drive.
I suggest you see the processes tab and see if any process that might be using maximum read/writes in your hard drive.
Disable Indexing service that sometimes use more resources. Disable any startup process that might be using your system resources.
Windows + R -> Run Menu -> Type: msconfig and see any startup process that you can disable. Disable any program that seems suspicious.
You can try some other repair methods like:
Perform a diskcheck
Reset Virtual Memory
Disable Antivirus Software temporarily
Change the settings in Google & Skype
Fix your StorAHCI.sys driver
Update your device drivers
Win10 100% disk usage
I had the same issue on my WINDOWS 10 system and I tried a lot of things like turning off the search indexing feature of windows but nothing worked using all that. Here is what worked for me. I opened the task manager and found that there was a task with Microsoft Compatibility Telemetry (CompatTelRunner.exe). It is a Windows process that is designed to collect and send usage and performance data to Microsoft. The executable file collects and regularly sends usage and performance information to Microsoft in order to analyze the user experience and improve it. The described file also helps Microsoft to identify compatibility issues and ensure compatibility when installing the latest Windows OS version. However, Microsoft Compatibility Telemetry eats CPU by scanning computer files and check their compatibility with Windows 10 in case an update is initiated.
I simply clicked on End Task for Microsoft Compatibility Telemetry and my disk usage went from 98% to 15% within few seconds. I hope it helps others experiencing the same issue as well.
I had the same issue with windows 10 on Laptop.
I set the windows update service from automatic to manual.
Now i am always under 5%.
Click on administrative tools in control panel
Then click on Services
set windows update to manual.
Had the same problem for months. Desactivated SrTasks.exe and it started working.
However this task is clearly something important, so I think it's not recommanded to stop it.
Related
I was just downloading and installing updates it seemed really slow.
It did progress but slowly.
Finally I thought that is there anything happening.
I opened up task manager to see what is happening (if).
Malicous Removal tool was to biggest resource hog and decided to end that task.
Boom, Windows updates took a sprint and everything completed in matter of seconds.
Could this be Malicous Removal tool or was it just luck?
Malicious Software Removal tool appears in Windows Update. This tool removes some malware from Windows systems, particularly those systems without antivirus programs installed.
If you are using Solid Antivirus you wont require MSRT. You can disable MSRT by making changes in Registry and Task Scheduler.
MSRT takes lots of RAM and CPU resource. It need to be scanned each and every files check malicious software or files available.
Which Version of windows are you using now.
This is probably a pretty easy question to answer for someone that is experienced with FS minifilters. I am trying to script the removal of a filter driver and device.
Some background... this driver is running on Windows 8/10 x64. The vendor that created the driver has not been helpful in fulfilling my request for a removal tool. Unfortunately their MSI uninstall is buggy and only works about half the time you run it... They want us to upgrade to their newest version that doesn't have the bug we are encountering during uninstallation. We aren't interested in continuing use of this software so a paid upgrade seems frivolous... Their only suggestion has been to reimage the computers without the software that includes the FS minifilter device... That's out of the questions because it is on 1000+ computers...
Basically, their official uninstaller does an API callback to one of their servers and verifies the machines eligibility to uninstall:
Does the MAC address of the primary network adapter exist in their
database?
Does the password you entered for uninstallation match
what is set in their database?
If you are eligible, it runs an MSI uninstallation and disables the FS filter, removes the driver file, service files, configuration, and restarts... The bug that is keeping us from doing a normal bulk removal (their way) is that the MSI freezes during the removal process (after checking eligibility) and requires us to restart a client computer up to 3 times to finish the uninstall.
I have been able to successfully remove the software and device/driver by externally mounting the Windows file system and manually removing the driver file under System32/Drivers and also removing all of the actual program files/services. I have not been able to do this booted onto the same partition where the minifilter is loaded. The minifilter driver that is running is protecting those program files, a registry key, and the actual .sys file under System32...
I've done some basic reverse engineering of their MSI... They are using custom actions to perform the removal... First step is the removal of the service, second step is the removal of the minifilter. Both actions are done via an executable that is packaged in the MSI... I've extracted that and attempted to use it by running the same commands that they do during the MSI... I haven't had any luck. The minifilter just doesn't want to die.
They have some other custom actions that are loaded via DLL. Initial investigation makes me think its all of their custom uninstall eligibility craziness.
It looks like their minifilter doesn't have an unload routine built in. Using FLTMC I get this error attempting to detach and/or unload:
0x801f0010 Do not detach the filter from the volume at this time.
0x801f0014 Do not detach the filter from the volume at this time.
Does anyone know of a good way to unload a minifilter that is throwing those errors?
Try to kick out FltMgr.sys of the kernel by:
Renaming %SystemRoot%\sytem32\drivers\FltMgr.sys
Or changing HKLM\SYSTEM\CurrentControlSet\Services\FltMgr\Type to 0x4 (Disabled)
Reboot
Minifilters can't work without Filter Manager.
If you are desperate enough, look into Windows PE, available as part of the Windows Assessment and Deployment Kit.
A Windows PE image can be remotely installed onto a machine's hard disk and configured to perform whatever task you need done and then automatically reboot back into the original operating system. Doing it this way gives you the same access as externally mounting the infected file system, but can be automated. I've used this approach in the past to automate offline maintenance tasks on several hundred machines (e.g., changing a registry setting that Symantec Endpoint Protection was "protecting") and while getting it working is fiddly, once it is working it works well.
My email address is in my profile, you're welcome to contact me if you decide on this approach and have questions about implementing it.
Alternatively, depending on your jurisdiction and circumstances, you might want to consider threatening the vendor with a lawsuit if they refuse to provide a proper solution. They broke your computers, it should be their job to fix it. From the sounds of it, they wouldn't even need to do any work, just let you have the upgraded version for a few weeks free of charge.
I have a little network of a couple of machines at home, and I need to shutdown them at a certain hour.
I found out that Windows 7 from Pro upwards offers a graphical Security Policies editor, where it's possible to allow the remote shutdown, but apart from mine, the other PCs have just Home Premium, which doesn't have the editor.
I found out that the key is editable without the need of the editor, but how, and where do I find it?
Or, are there any other ways? Thanks for the help.
I have never done what you are trying to do in regards to remote shutdown, but here is some information that may be useful:
Are you using the group policy editor for Windows 7 Pro? I believe that's gpedit.msc, right? Back in the day it used to be that you could use regmon (a Sysinternals program) to monitor registry keys that are changed, but it looks like Microsoft bought out Sysinternals and then retired Regmon. However, I believe they moved the functionality to Process Explorer (edit: turns out it's Process Monitor):
Monitor: http://technet.microsoft.com/en-us/sysinternals/bb896645
Explorer: http://technet.microsoft.com/en-us/sysinternals/bb896653
On your Windows 7 Pro machine run process monitor and set it up to monitor registry changes for gpedit.msc. Then change the setting using the program. Once you have the key you can document it or export it using regedit. I'm not sure how you plan on changing the registry key remotely, though.
I'm having a problem with vfp9 on Windows 7 64-bit. I've found that create sql view is taking 5-6 seconds. These happen instantaneous in XP. When my app starts up, I'm doing a few of these, so in Win 7, my app is taking 30+ seconds longer to start up than in XP. My views look like this:
create sql view MyView remote connection MyConn as select * from MyTable
I've also found that calling dbsetprop is adding another 1-2 seconds in Win 7. Again its instantaneous in XP.
dbsetprop('MyView.MyPk', 'Field', 'KeyField', .T.)
dbsetprop('MyView.MyPk', 'Field', 'Updatable', .T.)
Once created, the views work as they should. No slowness on with platform.
Does anyone have any ideas about what I could try or any info on what is/could be causing this?
Thank you in advance.
I don't know why as I haven't worked with Windows 7 yet with VFP... However, what I would check within VFP and try changing some settings to see if it helps.
From the VFP/IDE menu, go to Tools, then Options. On the multi-tab form, click on the "Remote Data" tab.
I don't know if/what its trying to do, but maybe for testing, make sure the "Records to fetch at a time" is NOT set to "All" (checkbox).
I would also look into SQLSETPROP() function to see if any of those settings might help.
I can't reproduce this on Windows 7 64 bit, either with VFP9 RTM or VFP9 SP2. I don't have a database of any size to work with but on the sample database Northwind the commands you list seem to work instantaneously.
A couple of questions:
Is this reproducible on any machine running Windows 7?
Where is your database? Is it on the local machine, a local network, or the internet?
There seems to be more scope for speed problems with Windows 7 and Visual FoxPro (and similar) applications, and I think this is down to the different network stack in Windows 7, immature network card drivers, an increased susceptibility to cabling and network switch problems, or any combination of these.
Ensure that all your Windows 7 boxes are on SP1 (and any Server 2008 boxes with shared DBF files also), as this fixes a file corruption issue that affected Visual FoxPro indexes.
Ensure that your network card drivers are 100% up to date. This can make a big difference.
One thing that I have seen which can give a massive improvement to the speed of networked Visual FoxPro applications is the network card driver Interrupt Moderation setting. This is present on Intel, Broadcom and many other NICs, although with possibly slightly different names.
I have personally seen situations where disabling this has changed a networked VFP application from taking 30 seconds to start to about 6 seconds.
Found the solution.
Write caching was being disabled on the drive by the raid controller software included with the machine.
Write caching was enabled under Device Manager > Disk Drive > Properties > Polices. However the software was overriding this setting.
It can be reproduced without the raid software by unchecking it in Windows 7 Polices.
I have an application for Windows XP. This application is deployed with the hardware. The application is the only application that ever runs on these machines. These machines are never connected to the internet. I'm interested in instant-on (or quick-on) options that bypass the Windows XP startup for these machines.
This is similar to Windows XP "hibernation", but not exactly. With hibernation, the memory state is only read from disk once - the very next time the system is turned on. I want a memory state permanently stored to disk, so the system always starts from that same spot every time, regardless of how it was shut down. How can I achieve this?
Sounds like you're looking for the Hibernate Once, Resume Many feature of Windows Embedded.
If you like "hibernation", you may use VMWare.
Install a ArchLinux and VMWare on the host machines.
Prepare your Windows XP as the guest OS.
Customize startup process of the host, let it run VMWare and restore Windows to the snapshot.
Hmmm, the short answer is "not easily!", but one way could be to try playing around with replacing the windows shell with your own application / script that launches your own custom interface / state instead of Explorer as the default. Basically it's done using this reg key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\shell
Info on this actually seems to be reasonably scarce after doing a quick Google search, but this link below provides a little more detail:
http://www.trap17.com/index.php/how-change-windows-xp-shell_t20367.html
I think if you do a Google Groups search on "Windows XP shell replacement" you might get some more informative results.
You could try installing TweakUI on them, and having them autologin. Once you do that, just add your application to the Start Up menu (or in the registry, under:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
Jeff Atwood has a post on this very thing.