Troubleshooting Windows Update


The Windows family tree.
The Windows family tree. (Photo credit: Wikipedia)
Image representing Windows as depicted in Crun...
Image via CrunchBase

Troubleshooting Windows Update:

The error messages generated while using the Windows Update site can be used to determine where the problem is occurring. Windows Update error messages can be viewed in two locations; they are displayed on the Windows Update site when the error occurs and are also entered into the WindowsUpdate.log file.

The following table lists the basic format.

Collapse this tableExpand this table

Date Time PID TID Component Text
2005-06-01 18:30:03 992 810 Misc = Logging initialized
2005-06-01 18:30:03 992 810 Misc = Process:
2005-06-01 18:30:03 992 810 Misc = Module:

The WindowsUpdate.log file is located in the %SystemRoot% directory, which is usually C:\Windows. It is important to note that there are two similarly named log files, WindowsUpdate.log is the version 5 log file, while Windows Update.log is the version 4 log file. For quick access to this file, click on Start /Run and type WINDOWSUPDATE.LOG and click OK.

To determine where an error has occurred by looking up the error code in the table below. The beginning segment will identify what Windows Update process returned the error. Once you have identified the error code and determined where it is being generated you can look up the error text in the spreadsheet for a more detailed description.

Error Prefix Process
0x8DDD???? Windows Update Web Site
0x18?????? Windows Update Web Site
0x800700?? Windows Update Web Site
0x8024???? WUS Controls (Scan for Updates)
0x8019???? Background Intelligent Transfer Service (BITS)
0x8020???? Background Intelligent Transfer Service
0x8007F??? update.exe installer
0xC???????? Corruption in C:\windows\softwaredistribution\datastore

Using the error code received from the log file, you can search for articles from Microsoft website.

Troubleshooting Windows Service Startup Problems

If you cannot start the services tool, configure the service to use the built-in system account using the following steps:

  1. Start Registry Editor (Regedit.exe).

Important: This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs.

  1. Locate the ObjectName value in the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ServiceName

  1. On the Edit menu, click Modify.
  2. In the Value Data box, type localsystem, and then click OK.
  3. Quit Registry Editor.
  4. Attempt to restart the service. You may need to restart the computer for some services to restart properly.

Note: If you cannot start Registry Editor, you can modify the service account information by performing a parallel installation.

Troubleshooting Windows Firewall

While troubleshooting Windows Firewall, follow the basic rules mentioned below:

  1. Windows Firewall can be enabled or disabled only by administrators. It can be enabled or disabled by a Local Security Policy or Group Policy, as well—sometimes preventing access even by a local administrator.
  1. To share printers and files on a local computer that is running Windows Firewall, you must enable the File And Printer Sharing exception.
  1. If the local computer is running a service, such as a Web server, FTP server, or other service, network users cannot connect to these services unless you create the proper exceptions in Windows Firewall.
  1. Windows Firewall blocks Remote Assistance and Remote Desktop traffic by default. You must enable the Remote Desktop and/or Remote Assistance exceptions for remote users to be able to connect to a local computer with Remote Desktop or Remote Assistance.

Follow these steps to diagnose problems:

  • To verify that TCP/IP is functioning correctly, use the ping command to test the loopback address (127.0.0.1) and the assigned IP address.
  • Verify the configuration in the user interface to determine whether the firewall has been unintentionally set to Off or On with No Exceptions.
  • Use the netsh commands for Status and Configuration information to look for unintended settings that could be interfering with expected behavior.
  • Determine the status of the Windows Firewall/Internet Connection Sharing service by typing the following at a command prompt:

sc query sharedaccess

(The short name of this service is SharedAccess.) Troubleshoot service startup based on the Win32 exit code if this service does not start.

  • Determine the status of the Ipnat.sys firewall driver by typing the following at a command prompt:

sc query ipnat

This command also returns the Win32 exit code from the last start try. If the driver is not starting, use troubleshooting steps that would apply to any other driver.

  • If the driver and service are both running, and no related errors exist in the event logs, use the Restore Defaults option on the Advanced tab of Windows Firewall properties to eliminate any potential problem configuration.
  • If the issue is still not resolved, look for policy settings that might produce the unexpected behavior. To do this, type GPResult /v > gpresult.txt at the command prompt, and then examine the resulting text file for configured policies that are related to the firewall

Windows Firewall Troubleshooting Tools

Windows XP with SP2 provides the following tools for troubleshooting Windows Firewall issues:

  • Netsh firewall show commands
  • Audit logging
  • Windows Firewall logging file
  • The Services snap-in
  • The Event Viewer snap-in
  • The Netstat tool

Netsh Firewall Show Commands

To obtain information when troubleshooting Windows Firewall, use the following netsh commands:

netsh firewall show state verbose=enable

This command displays the actual state of Windows Firewall for the current set of settings, as configured by the combination of local Windows Firewall settings and Group Policy-based Windows Firewall settings, and the current set of open ports.

netsh firewall show config verbose=enable

This command displays only the local Windows Firewall settings as configured by local settings. Note that unlike the netsh firewall show state verbose=enable command, this command only shows what is configured locally, rather than the current state of the Windows Firewall. You can use this command when you want to compare what is configured locally to the actual state of Windows Firewall, to determine the changes in Windows Firewall settings due to Group Policy.

Audit Logging

To track changes that are made to Windows Firewall settings and to see which applications and services asked Windows XP to listen on a port, you can enable audit logging and then look for audit events in the security event log.

To enable audit logging on a computer running Windows XP with SP2, do the following:

  1. Log on using an account that is a local administrator.
  1. From the Windows XP desktop, click Start, click Control Panel, click Performance and Maintenance, and then click Administrative Tools.
  1. In Administrative Tools window, double-click Local Security Policy Shortcut.
  1. In the console tree of the Local Security Settings snap-in, click Local Policies, and then click Audit Policy.
  1. In the details pane of the Local Security Settings snap-in, double-click Audit policy change. Select Success and Failure, and then click OK.
  1. In the details pane of the Local Security Settings snap-in, double-click Audit process tracking. Select Success and Failure, and then click OK.
  1. Close the Local Security Settings snap-in.

You can also enable audit logging for multiple computers in an Active Directory® directory service domain using Group Policy by modifying the Audit policy change and Audit process tracking settings at Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy for the Group Policy objects in the appropriate domain system containers.

Once audit logging is enabled, use the Event Viewer snap-in to view audit events in the security event log.

Windows Firewall uses the following event IDs:

  • 848 – Displays the startup configuration of Windows Firewall.
  • 849 – Displays an application exception configuration.
  • 850 – Displays a port exception configuration.
  • 851 – Displays a change made to the application exceptions list.
  • 852 – Displays a change made to the port exceptions list.
  • 853 – Displays a change made to the Windows Firewall operation mode.
  • 854 – Displays a change made to Windows Firewall logging settings.
  • 855 – Displays a change made to ICMP settings.
  • 856 – Displays a change made to the Prohibit unicast response to multicast or broadcast requests setting.
  • 857 – Displays a change made to the Remote Administration setting.
  • 860 – Displays a change made to a different profile.
  • 861 – Displays an application attempting to listen for incoming traffic.

Windows Firewall Logging File

To determine whether a specific computer is dropping packets, enable Windows Firewall logging, either on an individual computer or through Group Policy settings. Then, check the Windows Firewall log file for entries that correspond to the suspected traffic.

The Pfirewall.log file, stored by default in your main Windows folder, records either discarded incoming requests or successful connections based on the Security Logging settings on the Advanced tab in the Windows Firewall component of Control Panel or through the Windows Firewall: Allow logging Group Policy setting. You can use the contents of the Pfirewall.log file to determine whether traffic is reaching the computer on which Windows Firewall is enabled without having to create an exception or enable ICMP traffic.

For example, when you select the Log dropped packets check box, all incoming traffic that is discarded by the firewall is logged in the Pfirewall.log file. You can view this file by double-clicking it in your main Windows folder with Windows Explorer. Use the contents of the log file to determine whether traffic reached your computer and was discarded by Windows Firewall.

The Services Snap-in

You use the Services snap-in to check the status of services (programs running on your computer that provide capabilities to other application programs you might run). For Windows Firewall troubleshooting, use the Services snap-in to check the status and properties of the Windows Firewall (WF)/Internet Connection Sharing (ICS) service. Once Windows Firewall has been enabled, the Windows Firewall (WF)/Internet Connection Sharing (ICS) service in the Services snap-in should be started and configured to automatically start. To use the Services snap-in for Windows Firewall troubleshooting, do the following:

  1. Click Start, click Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-click Services.
  2. In the details pane of the Services snap-in, double-click the Windows Firewall (WF)/Internet Connection Sharing (ICS) service.

Startup type should be set to Automatic and the Service status should be Started.

The Event Viewer Snap-in

If the Windows Firewall (WF)/Internet Connection Sharing (ICS) service is unable to start, then it adds entries to the system event log with information about why it could not start. Additionally, audit log events corresponding to changes in Windows Firewall configuration and program requests to open ports are stored in the security event log. To view the system or security event logs, use the Event Viewer snap-in.

To view the entries in the system or security event logs with the Event Viewer snap-in, do the following:

  1. Click Start, click Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-click Event Viewer.
  1. To look for error events for the Windows Firewall (WF)/Internet Connection Sharing (ICS) service, click System in the console tree of the Event Viewer snap-in.
  1. In the details pane of the Event Viewer, look for Error events.
  1. To look for audit events corresponding to applications or service attempting to open ports, click Security in the console tree of the Event Viewer snap-in.
  1. In the details pane of the Event Viewer, look for events with the event IDs 849, 850, and 861.

The following figure shows an example of an audit event in the security event log.

The Netstat Tool

The Netstat tool displays a variety of information about active TCP connections, ports on which the computer is listening, Ethernet statistics, the IP routing table, and IPv4 and IPv6 statistics. In Windows XP with SP2, the Netstat tool supports a new –b option that displays the set of components by file name that are listening on each open TCP and UDP port.

In Windows XP with SP1 and Windows XP with SP2, you can use the netstat –ano command to display the complete set of ports being listened to in numerical form and their corresponding process IDs (PIDs). You can then look up the PID in the display of the tasklist /svc command to discover the name of the process that owns the port. However, in some cases, there are multiple services within a single process and it is not possible with the netstat –ano command to determine which service within the process owns the port.

With the netstat –anb command, Netstat displays the complete set of TCP or UDP ports in numerical form, the file names corresponding to the components of the service that owns the port, and the corresponding PIDs. From the file names and the PID, you can determine which of the services in the display of the tasklist /svc command opened the port.

Troubleshooting Registry Corruption

When registry is corrupt, you may encounter different error messages such as

Windows XP could not start because the following file is missing or corrupt: \WINDOWS\SYSTEM32\CONFIG\SYSTEM

Or

Windows XP could not start because the following file is missing or corrupt: \WINDOWS\SYSTEM32\CONFIG\SOFTWARE

Recovery Steps

To restore the computer to a stable condition, perform the following actions:

  1. Use Repair Hives: Replace current registry hives with those from %windir%\Repair.
  2. Boot the Computer to Safe Mode: boot to Safe Mode in order to access the Restore Point registry files easily.
  3. Obtain Restore Point Hives: Retrieve registry hive files from a recent Restore Point and place them in a folder under %windir%.
  4. Use Restore Point Hives: Replace current registry hives with those from the folder created in the previous step.

The steps for each of these actions are given below in detail:

Use Repair Hives

The best currently accessible registry files are in the %windir%\repair directory. These need to be copied to the %windir%\system32\config folder, after renaming the files currently in place. The steps in this section should enable the computer to boot, but applications installed since the Repair registry hives were last saved will likely not function.

Use the following steps:

  1. At the Recovery Console command prompt, type the following lines, pressing ENTER after you type each line:

cd \windows\system32\config

ren system system.old

ren software software.old

ren SAM SAM.old

ren security security.old

ren default default.old

cd \

cd windows\repair

  1. This next step checks the date and time on the files in the Repair folder. It is important to determine how recently these files were updated. They could be unchanged since Windows XP was originally installed. In order to check the date and time of the files, type DIR.
  2. Note the date the files were modified for use later.
  3. Continue with the copy of files from the Repair folder to the Config folder using the following commands:

copy system C:\windows\system32\config\system

copy software C:\windows\system32\config\software

copy sam C:\windows\system32\config\sam

copy security C:\windows\system32\config\security

copy default C:\windows\system32\config\default

  1. Type exit and restart the computer

Boot the Computer to Safe Mode

You may be unable to log on to the computer in Normal Mode at this point. This can occur because the local user account passwords have been reset to the point at which the Repair registry hives were last saved.

In the event that you cannot log on, use the Administrator account, which does not have a password set by default.

Obtain Restore Point Hives

After gaining access to Windows, you can now make copies of the more recent registries from the Restore Point folders created by System Restore. To do this, use the following steps:

  1. Start Windows Explorer.
  2. On the Tools menu, click Folder options.
  3. Click the View tab.
  4. Under Hidden files and folders, click to select Show hidden files and folders, and then click to clear the Hide protected operating system files (Recommended) check box.
  5. Click Yes when the dialog box that confirms that you want to display these files appears.
  6. Double-click the drive where you installed Windows XP to display a list of the folders. If is important to click the correct drive.
  7. Open the System Volume Information folder. This folder is unavailable and appears dimmed because it is set as a super-hidden folder.

Note: This folder contains one or more _restore {GUID} folders such as “_restore{87BD3667-3246-476B-923F-F86E30B3E7F8}”. If you receive the following error message, use the steps below to add the current user to the permissions for the folder. Otherwise proceed

to step 8 below.

C:\System Volume Information is not accessible. Access is denied.

  1. Open My Computer, right-click the System Volume Information folder, and then click Properties.
  2. Click the Security tab, which will display an interface such as that shown below.
  1. Click Add, and then type the name of the current user. This is the account with which you are logged on.
  2. Click OK, and then click OK.
  3. Double-click the System Volume Information folder to open it.
  1. In the GUID folder, open a folder that was created recently. You may need to click Details on the View menu to see when these folders were created. There may be one or more folders starting with “RP x” under this folder. These are restore points.
  1. Open one of these folders to locate a Snapshot subfolder. The following path is an example of a folder path to the Snapshot folder. Also see for an image of a Snapshot folder:

C:\System Volume Information_restore{D86480E3-73EF-47BCA0EB-

A81BE6EE3ED8}\RP1\Snapshot

  1. From the Snapshot folder, copy the following files to the C:\Windows\Tmp folder:

REGISTRY_USER.DEFAULT

_REGISTRY_MACHINE_SECURITY

_REGISTRY_MACHINE_SOFTWARE

_REGISTRY_MACHINE_SYSTEM

_REGISTRY_MACHINE_SAM

  1. Rename the files in the C:\Windows\Tmp folder as follows:

Rename REGISTRY_USER.DEFAULT to DEFAULT

Rename _REGISTRY_MACHINE_SECURITY to SECURITY

Rename _REGISTRY_MACHINE_SOFTWARE to SOFTWARE

Rename _REGISTRY_MACHINE_SYSTEM to SYSTEM

Rename _REGISTRY_MACHINE_SAM to SAM

Use Restore Point Hives

Now these registry hive files can be copied to the proper location for use by the system. To do this, return to Recovery Console.

  1. At the command prompt, type the following lines, pressing ENTER after you type each line:

cd system32\config

ren sam sam.rep

ren security security.rep

ren software software.rep

ren default default.rep

ren system system.rep

copy c:\windows\tmp\software

copy c:\windows\tmp\system

copy c:\windows\tmp\sam

copy c:\windows\tmp\security

copy c:\windows\tmp\default

  1. Type exit to quit Recovery Console. Your computer restarts

The computer should start in Normal Mode, and the most recent passwords should be functional again and the final state of the computer has matching files and registry configuration.