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.
Related
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.
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 freeware software, which i want to install on a network share. The reason is, if the software is installed on a network share, all users which has access to this network share folder should be able to use the program.
Now, I run the setup.exe on my machine and choose on the step "destination installation" my network share \sharename\TestFolder.
The software was installaing on this sharefolder and after the installation it was possible to run the program on my computer without any errors and use it..
After that I try to start the program on other client but there is always an error message, that it starts with a false operator.
Now my question is, is there a software, which can observe on which files the program want to access when I make double click on the (program.EXE).
Thank you, I hope you can help me.
Yes, there are several tools that can monitor or observe system changes performed by a setup.exe.
Many of these tools are quite old and may not operate correctly in new versions of Windows. The most recent one I found that looks acceptable was EMCO MSI Package Builder. I never tested the monitor feature, but it is at least an updated capture product.
In my experience these monitor tools capture way too much low-level system stuff, and you will need to spend quite a bit of time to sort out what is really needed for the software to operate. If you have experience with software development you may get just as much information from using a System Internals tool such as RegMon, FileMon or ProcMon. See Microsoft site: http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx . These tools are exceptionally useful and known for their small size and great feature set. You can run a ProcMon on the launch of the application executable.
It is also possible that the setup.exe is a wrapper for an MSI file. These files can be viewed with free tools such as Orca and EMCO MSI Package Builder and you can basically see what registration settings are needed for the application to operate. Try opening a command prompt and write setup.exe /a and see if it offers to create an "administrative installation point" - or similar.
If I were to guess I'd say that the software needs to have COM servers registered locally, registry keys added to each local computer and possibly you need to install a couple of runtimes on each system - for example Microsoft C runtime of a particular version. This is just a wild guess. What is the name of the software? If it is a .NET application you may need assemblies installed to the Global Assembly Cache GAC.
I'm fairly new to deploying desktop applications, so this is the first time I'm building an installer for my software. Currently, the first time I run my software after installing it, it crashes. After that, it runs fine. I'm still in the process of debugging this issue, but I've noticed that a reboot immediately after installing and before running the software seems to fix this crash.
What are common reasons that some installers ask you to reboot before running the software?
Also, why do some installers need to restart before finishing the installation?
Thanks in advance!
Generally, reboots between install and running are because you're replacing system DLLs that are locked. The installer sets up a run-once registry entry that copies the DLLs during boot before they're locked by Windows, and then your application can use the new DLL that you laid down.
In general, this is highly discouraged. There should be no reason anymore for anyone other than Windows itself to need to reboot after install anymore.
I'd suggest going back into a debugger to find out more details about why your application is crashing. Hopefully you have enough tracing available in your code to allow that type of debugging.
In general, a reboot is only required if the installer needs to replace files that are currently in use (and locked) by the OS. Sometimes installers will err on the side of reboot-just-in-case, but this is rarer than it used to be.
We've got a case with an installer I maintain where we need to force a reboot for vista only due to UAC and privilege elevation. Once the setup is complete we need to trigger a program as the current user context, not the elevated Vista context.
In your case, I suspect that some files haven't been correctly registered and you just need to stick with the debugging ;)
As most of you probably noticed, when uninstalling an MSI package Windows will ask for the original .msi file. Why is that?
I can only see disadvantages to that:
not resilient to network changes.
not resilient to local disk changes.
unexpected by users.
typically requires users to leave their desk and start a crusade to get the correct CD.
kind of proves installations are not self-contained.
promotes the use of unsafe tools such as msizap.
which in turn promotes the "next time I'll just use a zip file" mentality.
Could someone shed some light on this?
Fix Broken Uninstall: You can try the newest FixIt Uninstall tool from Microsoft if you have problems uninstalling an MSI. And one more link: Uninstalling an MSI file from the command line without using msiexec (a plethora of different ways to uninstall an MSI).
UPDATE:
This new support tool (this tool is now also deprecated) can be tried on recent Windows versions if you have defunct MSI packages needing uninstall (rather than the outdated, deprecated, unsupported msizap.exe).
Some have suggested to use the tool linked to here by saschabeaumont: Uninstall without an MSI file. If you try it and it works, please be sure to let us know. Feedback in that answer indicates that it works (I don't have any stuck setups to test with as of now).
Why are you asked for the original installation media?:
The original MSI is not needed for uninstall unless the MSI itself is badly designed - or the cached MSI is missing (see details below).
All installed MSI files are cached in %SystemRoot%\Installer\*.* using a random hex name.
The cached MSI file is used for any maintenance, repair and uninstall operations - and it is sufficient for uninstall in the vast majority of cases.
In some cases this cached file can be missing, and then uninstall is not possible at all in some cases (some theories as to why this can happen - MSI design errors, anti-virus quarantining, system restore, tinkering, developer system in erroneous state from development work, etc...). See more info below - and links to force uninstall or unregistration of the product.
The original source is only needed if files need to be copied to disk (for a maintenance install), or the MSI does an explicit request to resolve the original source via the standard action ResolveSource or via a custom action (which shouldn't be done in a properly authored package - I think the MS Office package contained this ResolveSource error back in the day, causing everyone to go looking for their installation CDs/DVDs).
In previous editions of Windows this cached MSI was stripped of all cabs, and hence contained the installer structure only, and no files.
Starting with Windows 7 (MSI version 5) the MSI files are now cached full size to avoid breaking the file signature which affects the UAC prompt on setup launch (a known Vista problem). This may cause a tremendous increase in disk space consumption (several gigabytes for some systems). Check this article and especially the discussion at the bottom for more intel.
To prevent caching a huge MSI file, you can run an admin-install of the package before installing. This is how a company with proper deployment in a managed network would do things, and it will strip out the cab files and make a network install point with a small MSI file and files besides it. Note that this may yield a UAC prompt is some cases since the extracted MSI file is no longer signed - this must be tested with your SOE / desktop configuration.
Read my answer in this thread for the full description of admin installs: What is the purpose of administrative installation initiated using msiexec /a? or this similar but perhaps more accessible answer: admin install and its uses
In some rare cases the cached MSI (with the random name) can be erroneously missing, and uninstall will then ask for the original MSI in order to complete the uninstall. This does not happen often. It used to be the case that one could use MsiZap.exe to clean out such an install, but this tool is outdated, deprecated and unsupported. Don't use it - there are too many incompatibilities with newer Windows versions and you create new problems. Perhaps try this support tool instead (also deprecated). The only option I can suggest now is this answer from saschabeaumont. If you try this tool, please let us know if it works for you. If you want to figure out what could have caused the cached MSI to be missing, try to read section 12 here: Uninstalling an MSI file from the command line without using msiexec (in short potential causes range from interference with system restore, anti virus and cleanup scripts, to erronous manual tweaking, low disk space, power outages, developer box debugging errors, badly designed MSI files with duplicate package codes, failed patches, etc... Many theories, few certainties I am afraid).
As a last resort you can try system restore (unless it has been disabled entirely or partly) to go back to a previous installation state and see if this solves your uninstall problem (you can find video demos of this on youtube or a similar site).
Be aware that system restore might affect Windows Update that must then be re-applied - as well as many other system settings. I have seen new, unsolvable installation problems resulting from a system restore, but normally it works OK. Obviously don't use the feature for fun, it's a last resort and is best used for rollback of new drivers or setups that have just been installed and are found to cause immediate problems and such issues. The longer you go back the more rework you will create for yourself. A lot of self-evident stuff, but I guess it needs to be mentioned.
Since I mentioned system restore I suppose I should mention the Last Known Good Configuration feature. This feature has nothing to do with uninstall or system restore, but is the last boot configuration that worked or resulted in a running system. It can be used to get your system running again if it bluescreens or halts during booting. This often happens after driver installs. This will do nothing to fix your failing uninstall though (or I would be very surprised).
Related answer:
Uninstall without an MSI file
In addition to this answer, perhaps this article on various ways of uninstalling MSI packages is of interest. It is a rather popular article with a high number of views:
Uninstalling an MSI file from the command line without using msiexec.
There are a few reasons for keeping the original msi:
The uninstaller uses it to know what files and registry keys were installed and make sure they are all cleaned up.
The msi may contain special uninstall actions that need to be performed.
It allows you do to a 'repair' operation from the Add/Remove Programs menu, regardless of whether or not you saved the install file yourself.
The normal way of things is for Windows to keep the file cached for you, so you don't have to think about it. See your %WINDIR%\Installer\ folder. The only reason it would ask your for the original msi is if something is wrong with the saved file. This addresses most of your concerns, though it does raise a new one (disk-space).