What should I do if my computer does not boot into Windows?

When a computer starts or boots up, the Windows operating system will be loaded. There are many files that are executed and processes that are started for Windows to properly load.

If a computer cannot load the Windows operating system, the problem can be due to several possible causes. Review the possible causes and resolution options below to try and resolve the problem on your computer.

Newly installed hardware

New hardware in a computer can sometimes cause problems with the computer being able to boot into Windows properly or at all. If you recently installed new hardware in your computer, turn off the computer, remove the new hardware, and start up the computer again.

If the computer can boot into Windows successfully after removing the new hardware, try connecting it again, if the problem persists the hardware may be incompatible or defective. If there is no new hardware in the computer, and the computer cannot boot into Windows, continue to the next section below.

Out of date or corrupt hardware drivers

The Windows operating system relies on drivers to understand how to communicate and work with hardware in the computer. If a driver is outdated or becomes corrupt, it can cause Windows to become unstable and sometimes cause the computer to not boot into Windows.

An option for trying to update or reinstall a driver is to boot the computer into Safe Mode (select the Safe Mode with Networking option). Once in Safe Mode, access the Windows Device Manager and check for any devices with a yellow exclamation point or red X next to them.

If any devices have an exclamation point or red X, right-click that device and select Update driver to look for an updated driver. If you cannot find an updated driver, try right-clicking the device, select Uninstall device, and restart the computer. By uninstalling the device and restarting the computer, it forces Windows to try and reinstall the device automatically and sometimes fix the issue.

If updating the drivers or uninstalling and reinstalling the device do not fix the Windows boot issue, proceed to the next section.

Corrupt system files

When Windows is loading, many system files that are being executed. If one or more of those system files are corrupt, it can cause Windows not to load properly or at all.

You can fix corrupt system files by either activating a Windows restore point or running the Windows repair process.

Activate restore point

If Windows restore points were created, you can try to activate a restore point before the Windows boot issue started to occur. Since Windows is not booting normally, you can try accessing Safe Mode to activate a restore point.

1. Open the Safe Mode menu.
2. Select the Safe Mode with Command Prompt option in the menu.
3. At the command prompt, type rstrui.exe and press Enter .
4. Follow the instructions and prompts provided to find and an activate a restore point before Windows started having issues booting into Windows normally.

If activating a restore point does not work to fix the Windows boot problem, or there were no restore points available, try the Windows Repair process.

Windows repair process

Some computers provide the repair feature through the Recovery Console or system recovery environment that can be accessed when the computer is first booting up. Most often, one of the function keys, like F1 , F2 , F10 , or F12 , or possibly the R key, gets you into the Recovery Console. Once in the Recovery Console, check for a Repair or Fix Windows option. The repair process should only replace the Windows operating system files and not delete any of your files.

If you cannot access the Recovery Console or system recovery, or a Repair or Fix option is not available, use a Windows installation disc or USB drive to access the Windows Repair feature. Start the computer and boot to the Windows installation disc. When the installation menu is displayed, check for a Windows Repair option and select that option. Follow the prompts to run the repair process. Again, only the Windows operating system files should be installed, and your files should remain intact.

If running the Windows repair process does not fix the issue, continue to the next section below.

Bad sectors or other hard drive issues

Problems on a hard drive, like bad sectors, can cause Windows to not boot up successfully. Hard drive issues can occur without warning, but they can also be fixed in many cases.

You can test a hard drive for failures using different free utilities, some of that are already available on your computer. Hard drive manufacturers often provide scan and test utilities for their specific hard drives.

Test the hard drive for failures and if any are found, run the available fix process to try and repair the problem. If the hard drive has too many failures or the fix process does not work to repair the issue, you will likely need to replace the hard drive.

If the hard drive is working correctly or repairing any hard drive issues does not fix the Windows booting problem, continue to the next section below.

Other hardware failures

If you didn’t install any new hardware and the hard drive is working, another existing piece of hardware in the computer is causing the issue. A defective motherboard, or the video card, or piece of RAM could cause Windows not to be able to boot properly.

To test for hardware issues, you can create and use an Ultimate Boot CD, which contains a collection of troubleshooting utilities to try and identify, and sometimes fix, hardware problems. If a defective piece of hardware is found, replace that hardware and then test the computer to see if it can boot into Windows successfully.

Reinstall Windows

If, after trying all the above troubleshooting options, the Windows boot issues still occurs, the best course of action is to reinstall Windows. A full Windows reinstall erases all files on the computer and reinstall the operating system.

If possible, remove the hard drive from the computer and connect it to another computer as a secondary hard drive or external hard drive using an enclosure kit. Then, back up your files so that you do not lose any of it.

After you have backed up your files, connect the hard drive to the computer again and install the Windows operating system again. When going through the installation process, make sure to select the option to erase all files on the hard drive first. Doing so helps ensure that Windows is properly reinstalled and works again after the install process is complete.

Loading and Unloading

About Loading and Unloading

A minifilter driver can be loaded at any time while the system is running. If a minifilter driver’s INF file specifies a driver start type of SERVICE_BOOT_START, SERVICE_SYSTEM_START, or SERVICE_AUTO_START, the minifilter driver is loaded according to existing load order group definitions for file system filter drivers, to support interoperability with legacy filter drivers. While the system is running, a minifilter driver can be loaded through a service start request (sc start, net start, or the service APIs), or through an explicit load request (fltmc load, FltLoadFilter, or FilterLoad).

A minifilter driver’s DriverEntry routine is called when the minifilter driver is loaded, so the minifilter driver can perform initialization that will apply to all instances of the minifilter driver. Within its DriverEntry routine, the minifilter driver calls FltRegisterFilter to register callback routines with the filter manager and FltStartFiltering to notify the filter manager that the minifilter driver is ready to start attaching to volumes and filtering I/O requests.

Minifilter driver instances are defined in the INF file used to install the minifilter driver. A minifilter driver’s INF file must define a default instance, and it can define additional instances. These definitions apply across all volumes. Each instance definition includes the instance name, its altitude, and flags that indicate whether the instance can be attached automatically, manually, or both. The default instance is used to order minifilter drivers so that the filter manager calls the minifilter driver’s mount and instance setup callback routines in the correct order. The default instance is also used with explicit attachment requests when the caller doesn’t specify an instance name.

The filter manager automatically notifies a minifilter driver about an available volume by calling its InstanceSetupCallback routine on the first create operation after the volume is mounted. This can occur before FltStartFiltering returns, when the filter manager enumerates existing volumes at system startup. It can also occur during runtime, when a volume is mounted or as a result of an explicit attachment request (fltmc attach, FltAttachVolume, or FilterAttach).

A minifilter driver instance is torn down when the minifilter driver is unloaded, the volume the instance is attached to is being dismounted, or as a result of an explicit detach request (fltmc detach, FltDetachVolume, or FilterDetach). If the minifilter driver registers an InstanceQueryTeardownCallback routine, it can fail an explicit detach request by calling FilterDetach or FltDetachVolume. The teardown proceeds as follows:

If the minifilter driver registered an InstanceTeardownStartCallback callback routine, the filter manager calls it at the beginning of the teardown process. In this routine, the minifilter driver should complete all pending operations, cancel or complete other work such as I/O requests generated by the minifilter driver, and stop queuing new work items.

During instance teardown, any currently executing preoperation or postoperation callback routines continue normal processing, any I/O request that is waiting for a postoperation callback can be «drained» or canceled, and any I/O requests generated by the minifilter driver continue normal processing until they are complete.

If the minifilter driver registered an InstanceTeardownCompleteCallback routine, the filter manager calls this routine after all outstanding I/O operations have been completed. In this routine, the minifilter driver closes any files that are still open.

After all outstanding references to the instance are released, the filter manager deletes remaining contexts and the instance is completely torn down.

While the system is running, a minifilter driver can be unloaded through a service stop request (sc stop, net stop, or the service APIs), or through an explicit unload request (fltmc unload, FltUnloadFilter, or FilterUnload).

A minifilter driver’s FilterUnloadCallback routine is called when the minifilter driver is unloaded. This routine closes any open communication server ports, calls FltUnregisterFilter, and performs any needed cleanup. Registering this routine is optional. However, if the minifilter driver does not register a FilterUnloadCallback routine, the minifilter driver cannot be unloaded. For more information about this routine, see Writing a FilterUnloadCallback Routine.

Filter Manager Routines for Loading and Unloading Minifilter Drivers

The filter manager provides the following support routines for explicit load and unload requests, which can be issued from user mode or kernel mode:

The following routines are used to register and unregister callback routines for instance setup and teardown:

Minifilter Driver Callback Routines for Instance Setup, Teardown, and Unload

The following minifilter driver callback routines are stored as members of the FLT_REGISTRATION structure that is passed as a parameter to FltRegisterFilter:

File system filter load order

The Windows operating system loads file system filter drivers based on:

• The driver’s start type, where each start type represents phases of booting a system.
• The load order groups for file system filter drivers that are loaded at system startup. The concept of load order groups is required by file system filter drivers for interoperability with legacy file system filter drivers. Note that a «minifilter» filter driver can be loaded at any time.

Before exploring when and how file system filter drivers are loaded during the system boot sequence, it is necessary to understand driver start types and load order groups.

Driver start types

A kernel-mode driver’s start type specifies whether the driver is to be loaded during or after system startup. There are five possible start types:

Start Type	Description
SERVICE_BOOT_START (0x00000000)	Indicates a driver started by the operating system (OS) loader. File system filter drivers commonly use this start type or SERVICE_DEMAND_START. Legacy file system filters must use this start type; see file system filter load order groups for more information.
SERVICE_SYSTEM_START (0x00000001)	Indicates a driver started during OS initialization. This start type is used by the file system recognizer. Except for the file systems listed below under «SERVICE_DISABLED,» file systems (including network file system components) commonly use this start type or SERVICE_DEMAND_START. This start type is also used by device drivers for PnP devices that are enumerated during system initialization but not required to load the system.
SERVICE_AUTO_START (0x00000002)	Indicates a driver started by the Service Control Manager during system startup. Rarely used.
SERVICE_DEMAND_START (0x00000003)	Indicates a driver started on demand, either by the PnP Manager (for device drivers) or by the Service Control Manager (for file systems and file system filter drivers).
SERVICE_DISABLED (0x00000004)	Indicates a driver that is not started by the OS loader, Service Control Manager, or PnP Manager. Used by file systems that are loaded by a file system recognizer (except when they are the boot file system) or (in the case of EFS) by another file system. Such file systems include CDFS, EFS, FastFat, NTFS, and UDFS. Also used to temporarily disable a driver during debugging.

All drivers that specify a start type of SERVICE_BOOT_START will be loaded before drivers with a start type of SERVICE_SYSTEM_START or SERVICE_AUTO_START. Within each start type category, the load order group determines when file system filter drivers (and legacy filter drivers) will be loaded.

Specifying start type

A driver writer can specify the start type for a driver at installation time in either of the following ways:

By specifying the desired start type for the StartType entry in the service-install-section referred to by an AddService directive in the driver’s INF file. This method is described in the ServiceInstall Section of Creating an INF file for a filter driver.

By passing the desired start type for the dwStartType parameter when calling CreateService or ChangeServiceConfig from a user-mode installation program. This method is described in the reference entries for CreateService and ChangeServiceConfig in the Microsoft Windows SDK documentation.

Driver load order groups

Within the SERVICE_BOOT_START and SERVICE_SYSTEM_START start types, the relative order in which drivers are loaded is specified by each driver’s load order group.

Drivers whose start type is SERVICE_BOOT_START are called boot (or boot-start) drivers. On Microsoft Windows 2000 and earlier systems, most filters that are boot drivers belong to the «filter» group. On Microsoft Windows XP and later systems, filters that are boot drivers generally belong to one of the FSFilter load order groups. These load order groups are described in detail in Load Order Groups for File System Filter Drivers.

Driver whose start type is SERVICE_SYSTEM_START are also loaded in the order of the load order groups to which they belong. However, no system-start driver is loaded until after all boot drivers have been loaded.

Load order groups are ignored for drivers whose start type is SERVICE_AUTO_START, SERVICE_DEMAND_START, or SERVICE_DISABLED.

A complete, ordered list of load order groups can be found under the ServiceGroupOrder subkey of the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control registry key.

The same load group ordering is used for SERVICE_BOOT_START and SERVICE_SYSTEM_START drivers. However, all SERVICE_BOOT_START drivers are loaded and started before any SERVICE_SYSTEM_START drivers are loaded.

Specifying load order group

A driver writer can specify the load order group for a driver at installation time in either of the following ways:

By specifying the desired load order group for the LoadOrderGroup entry in the service-install-section referred to by an AddService directive in the driver’s INF file. This method is described in ServiceInstall Section of Creating an INF file for a filter driver.

By passing the desired start type for the lpLoadOrderGroup parameter when calling CreateService or ChangeServiceConfig from a user-mode installation program. This method is described in the reference entries for CreateService and ChangeServiceConfig in the Microsoft Windows SDK documentation.

For more general information about driver load order and load order groups, see Specifying Driver Load Order.

Rules for loading a filter driver

The following rules about start type and load order groups determine when a filter driver will be loaded:

• A filter driver that specifies a particular start type and load order group is loaded at the same time as other file system filter drivers and legacy filter drivers in that start type and load order group.
• Within each load order group, file system filter drivers and legacy drivers are generally loaded in random order. This normally results in drivers being loaded based on the order in which the driver was installed.
• If a file system filter driver or legacy filter driver does not specify a load order group, it is loaded after all the other drivers of the same start type that do specify a load order group.

—>