Troubleshooting Boot Issues due to missing Driver signature (x64)

Troubleshooting Boot Issues due to missing Driver signature (x64)

  • Comments 9
  • Likes

Today, I am going to discuss how to troubleshoot a scenario where the system does not boot in normal mode; however, boots up fine upon selecting F8 -> Disable Driver Signature Enforcement.

In 64-bit operating systems starting with Windows Vista, Windows will load a kernel-mode driver only if the driver is signed. You might get different fatal errors during the boot process depending on the driver that was blocked from loading and how it impacted the further processes. While some of the fatal system errors reference the driver on the blue screen, some may not.

Here is an example of how we can diagnose the problem and fix it. When booting normally, you may receive this error and the machine halts:


This article explains this type of stop error.



In decoding the stop error, you should look at the second parameter.

(0X00000000 0XC0000428 0X00100588)  <--- second parameter indicates error code


To translate the hex code, you can use the inbox SLUI.EXE tool or look up the error code from ntstatus.h file in the Windows SDK.

Command Usage:

slui.exe 0x2a 0xC0000428


Restart your computer and start pressing the <F8> key on your keyboard. On a computer that is configured for booting to multiple operating systems, you can press the <F8> key when the Boot Menu appears. On the Advanced Boot Options menu, select Disable Driver Signature Enforcement press <ENTER>.


If the server boots up after selecting this mode, we now know that it is some driver or module which is unsigned or being detected as unsigned that is preventing the system from booting up properly.

Our next task is to find out the module name and devise a remedy. You would need to open Event Viewer and go to Applications and Services Logs -> Microsoft -> Windows -> CodeIntegrity -> Operational.

Note: Check if you can see events like the ones depicted below.
In case you get “access denied” while accessing the “operational” log create a folder on the root of the C drive and give Everyone full rights.
Redirect the ETL file path to the newly created folder. Disable and enable the logging again.


Once logging is enabled, you will find the unsigned driver name from the events.



The driver can be a Microsoft inbox driver or a 3rd party driver. For drivers that have newer versions available and can be updated, that is the first thing to try. In most cases, this will fix the problem.

However, you might encounter a scenario when there is no update available. Here are the steps to find out the required catalog file and place it accordingly.

Files can be copied from another working server with similar file versions and extracted from the update that was the source of the file version.

We can use the SIGCHECK.EXE tool to find the catalog file for a file.



Step -1 : Verify if the driver is really Unsigned:

Note: The full path of the driver file should be passed as a command line parameter


You can run the command as described in the screenshot above to make sure the driver is indeed being detected as unsigned.


Step – 2 : Get the Signed driver from a working server:


The actual file and the catalog can be copied from a working server and placed in respective locations as depicted above. Once the copy completes, use the SIGCHECK tool to verify and make sure that the file is detected as signed and displays the name of the catalog. Reboot the server and ensure it comes up fine in the normal mode.


Appendix - A


To find the catalog for the file, you can also enable verbose logging for CodeIntegrity on the working server.  This will log the name of the CAT file where the file hash was found during the verification.


Steps to enable CodeIntegrity verbose logging:

i. Open Event Viewer
ii. Select the View drop down menu and choose Show Analytic and Debug Logs from the list
iii. Navigate to Applications and Services Logs -> Microsoft -> Windows -> CodeIntegrity -> Verbose
iv. Right – click and select enable log

More information on the Code Integrity can be found here:

Code Integrity Diagnostic System Log Events


Appendix - B

Note: The SIGNTOOL application can be used to get similar information.


Mentioned below is an example of this:

C:\WinDDK\7600.16385.1\bin\amd64>SignTool.exe verify /a /v c:\windows\system32\win32k.sys

Verifying: c:\windows\system32\win32k.sys
File is signed in catalog: C:\Windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\
Hash of file (sha1): DEDF7D339D8355A9875661559BD582FA46008AE5

Signing Certificate Chain:
    Issued to: Microsoft Root Certificate Authority
    Issued by: Microsoft Root Certificate Authority
    Expires:   Mon May 10 04:58:13 2021
    SHA1 hash: CDD4EEAE6000AC7F40C3802C171E30148030C072

        Issued to: Microsoft Windows Verification PCA
        Issued by: Microsoft Root Certificate Authority
        Expires:   Wed Mar 16 03:35:41 2016
        SHA1 hash: 5DF0D7571B0780783960C68B78571FFD7EDAF021

            Issued to: Microsoft Windows
            Issued by: Microsoft Windows Verification PCA
            Expires:   Tue May 15 02:41:44 2012
            SHA1 hash: 5C616DC011E309DFCD15C0EA32494186654A2CDC

The signature is timestamped: Mon Jan 16 15:24:23 2012
Timestamp Verified by:
    Issued to: Microsoft Root Certificate Authority
    Issued by: Microsoft Root Certificate Authority
    Expires:   Mon May 10 04:58:13 2021    

SHA1 hash: CDD4EEAE6000AC7F40C3802C171E30148030C072
        Issued to: Microsoft Time-Stamp PCA
        Issued by: Microsoft Root Certificate Authority
        Expires:   Sat Apr 03 18:33:09 2021
        SHA1 hash: 375FCB825C3DC3752A02E34EB70993B4997191EF            

            Issued to: Microsoft Time-Stamp Service
            Issued by: Microsoft Time-Stamp PCA
            Expires:   Fri Oct 26 02:12:17 2012
            SHA1 hash: FC33104FAE31FB538749D5F2D17FA0ECB819EAE5

Successfully verified: c:\windows\system32\win32k.sys

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0


Below are articles you should review that discuss more details about this subject.

Driver Signing Requirements for Windows

Driver Signing Guidelines for ISVs

Kernel-Mode Code Signing Walkthrough

Installing an Unsigned Driver during Development and Test


Hope this helps and until next time, Take care.

Parthiv Seth
Support Escalation Engineer
Microsoft Windows Server Core Team

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Thanks for the very thorough coverage of how to recover from this situation.

    But I'm curious about what would cause drivers on an otherwise healthy system to become unsigned? Would this be an indication of problems with the disk subsystem or is it more likely to be software and/or human?

  • slui.exe 0x2a ?? How did you know about that? I had no idea slui had that kind of error code lookup functionality :)

  • A very useful article indeed :)

  • Where did the command slui.exe 0x2a come from?

    In the picture the stop error indicate c000021a. Is it possible that the Slui command should be slui.exe 0x21a 0xC0000428?

  • slui 0x2a is the command to resolve win32 error codes

    Syntax:  slui 0x2a <error code in hex or decimal>

  • This fabulous article saved me countless hours of server restores/rebuilding due to a Major Virus Manufacturer's programming error.  

    Their agent software renamed the catroot subfolder and seems to have lost/deleted many of the cat files. Their instructions for repair told the admin to copy the contents of the TMP foler they created back into the main catroot folder, but because some signature files were missing, this did not fix the problem.

    I did try to copy just the signature files, but for some reason, even though the driver files were exactly the same version, sigcheck(and the error log) still showed them as unsigned drivers.  Even after a reboot.

    The final fix was to copy both the catroot\{F750...} folder contents, and the Windows\System32\drivers\*.* from a working server.  Reboot and viola no BSOD, no bypassing driver signing required.

    Thanks for an excellent and informative article.

  • You are a hero, boss, now I can boot my system again


  • I used Disable Driver Signature Enforcement now my monitor,mouse and keyboard wont turn on what do i do in this situation?