Troubleshooting Boot Issues due to missing Driver signature (x64)

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:

clip_image001

This article explains this type of stop error.

Bug Check 0xC000021A: STATUS_SYSTEM_PROCESS_TERMINATED
https://msdn.microsoft.com/en-us/library/windows/hardware/ff560177(v=vs.85).aspx

 

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

Stop 0XC000021A FATAL SYSTEM ERROR
(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

clip_image002

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> .

clip_image004

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.

clip_image006

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

 

Remediation...

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.

Sigcheck
https://technet.microsoft.com/en-us/sysinternals/bb897441

 

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

clip_image008

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:

clip_image010

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

Note:

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.

clip_image013

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
https://msdn.microsoft.com/en-us/library/windows/hardware/ff539911(v=vs.85).aspx

 

Appendix - B

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

Signtool
https://msdn.microsoft.com/en-us/library/windows/desktop/aa387764(v=vs.85).aspx

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}\Package_7_for_KB2661001~31bf3856ad364e35~amd64~~6.1.1.0.cat
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
https://msdn.microsoft.com/en-us/windows/hardware/gg487317

Driver Signing Guidelines for ISVs
https://msdn.microsoft.com/en-us/windows/hardware/gg463036

Kernel-Mode Code Signing Walkthrough
https://msdn.microsoft.com/en-us/windows/hardware/gg487328

Installing an Unsigned Driver during Development and Test
https://msdn.microsoft.com/en-us/library/windows/hardware/ff547565(v=vs.85).aspx

 

Hope this helps and until next time, Take care.

Parthiv Seth
Support Escalation Engineer
Microsoft Windows Server Core Team