Skip to main content

How to use System Restore to Remove Viruses

On Windows XP, Vista and Windows 7 machines, there is a feature called System Restore.
It’s normally enabled by default and takes snapshots of your system files and registry settings.

I have used it on several occasions to repair a machine that had a virus/malware infection.

It can be very difficult to repair a virus or malware because as soon as the computer starts up, the virus gets loaded into memory and depending on the virus, it can prevent your attempts at removing it.

Luckily the viruses that I saw were not too harmful. It’s only just annoying.

You can try the following steps.

First shutdown your computer. Turn on the computer again but start it up in Safe Mode. To get into safe mode, you need to press the F8 key so it can display a list of startup options. This can be tricky so I usually hit the F8 key as soon as the computer starts and just keep hitting it until the startup options come up.

Select Safe mode from the list.

Once you have started the computer in Safe mode, go into Start->All Programs->Accessories->System Tools->System Restore.

Choose a system restore point previous to the date that you were infected with the virus.

When your computer restarts, in theory you will not see the virus or malware loading up.

This is the time now to install or update your anti-virus program and signatures. Run a full scan of your hard disk. Install the anti-malware products like Spybot or Malaware Bytes, update the signatures and scan your whole disk.

That should be it.

However, if you find that you haven’t been able to get rid of the virus or malware with System Restore, then the next step is to find it’s name or symptom or message. You can then Google to find out how to remove that particular virus. If after this you still aren’t able to remove the virus, then you will most likely need a computer professional to do it.


Popular posts from this blog

How to Schedule an Exchange PowerShell Script in Task Scheduler

Exchange Management Shell Since Exchange 2007, Microsoft has provided the Exchange Management Shell so administrators can manage all aspects of the Exchange server from the command line. The Exchange Management Shell has Exchange specific PowerShell cmdlets. These Exchange cmdlets are not normally available in an ordinary PowerShell command environment. An example of what can be done in the Exchange Management Shell is to run a PowerShell script to list all the mailboxes on the Exchange server to a file. You can output columns based on display name, size of the mailbox, last logon, and other available mailbox attributes. You can also schedule a batch migration of mailboxes from one database to another such as the migration of mailboxes from Exchange 2010 to Exchange 2013. Scheduling the PowerShell Script Once you have written a PowerShell script and utilised the Exchange cmdlets, you can run it with no problems inside the Exchange Management Shell. If you were to try

How To Migrate Mailboxes from Exchange 2010 to Exchange 2016 using PowerShell

The Scenario Your organisation have decided to migrate from Exchange 2010 to Exchange 2016. The Exchange 2016 server have been installed into your current Exchange Organization. The Mailbox role have been installed on the Exchange 2016 server and you are ready to start moving mailboxes from the Exchange 2010 server to the Exchange 2016 server. Migrating a Mailbox from Exchange 2010 to Exchange 2016 Using New-MoveRequest Migrating a single mailbox involves invoking the cmdlet New-MoveRequest from the Exchange Management Shell on the Exchange 2016 server . Make sure that your user account that you have logged into the server with have the Organization Management role. The common parameters that I use for the New-MoveRequest cmdlet is : New-MoveRequest -Identity '' -TargetDatabase "DB02" -BadItemLimit 10 The -Identity parameter identifies the mailbox to be migrated. I usually use the e-mail address of the mailbox for the identity

Elastic Load Balancing in AWS

Elastic Load Balancing is a service which allows for the automatic distribution of incoming traffic across multiple Amazon EC2 instances.These EC2 instances should be in separate availability zones in a particular region.This enables applications to achieve fault tolerance and high availability if they are designed so that they can be accessed from multiple server instances. Sometimes an application may not need to be designed as such if they both point to the same data source. More often than not, these applications can be run from anywhere. They are good candidates to be put behind the Elastic Load Balancing service.It is up to the system or cloud administrator to ensure that identical versions of the application exist across all servers that are going to be load balanced. The Elastic Load Balancing service can be integrated with Auto Scaling in AWS. As more load is put on your application servers, additional EC2 instances can be launched by Auto Scaling.Once the load dissipates. E