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:
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
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.
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
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
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.
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): DEDF7D339D8355A9875661559BD582FA46008AE5Signing Certificate Chain:
Issued to: Microsoft Root Certificate Authority
Issued by: Microsoft Root Certificate Authority
Expires: Mon May 10 04:58:13 2021
SHA1 hash: CDD4EEAE6000AC7F40C3802C171E30148030C072Issued to: Microsoft Windows Verification PCA
Issued by: Microsoft Root Certificate Authority
Expires: Wed Mar 16 03:35:41 2016
SHA1 hash: 5DF0D7571B0780783960C68B78571FFD7EDAF021Issued to: Microsoft Windows
Issued by: Microsoft Windows Verification PCA
Expires: Tue May 15 02:41:44 2012
SHA1 hash: 5C616DC011E309DFCD15C0EA32494186654A2CDCThe 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 2021SHA1 hash: CDD4EEAE6000AC7F40C3802C171E30148030C072
Issued to: Microsoft Time-Stamp PCA
Issued by: Microsoft Root Certificate Authority
Expires: Sat Apr 03 18:33:09 2021
SHA1 hash: 375FCB825C3DC3752A02E34EB70993B4997191EFIssued to: Microsoft Time-Stamp Service
Issued by: Microsoft Time-Stamp PCA
Expires: Fri Oct 26 02:12:17 2012
SHA1 hash: FC33104FAE31FB538749D5F2D17FA0ECB819EAE5Successfully 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
Comments
- Anonymous
April 15, 2012
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? - Anonymous
April 15, 2012
slui.exe 0x2a ?? How did you know about that? I had no idea slui had that kind of error code lookup functionality :) - Anonymous
April 24, 2012
A very useful article indeed :) - Anonymous
May 17, 2012
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? - Anonymous
July 08, 2012
slui 0x2a is the command to resolve win32 error codesSyntax: slui 0x2a <error code in hex or decimal> - Anonymous
November 07, 2012
The comment has been removed - Anonymous
August 19, 2013
You are a hero, boss, now I can boot my system again - Anonymous
November 06, 2013
GREAT! THANK YOU VERY MUCH! - Anonymous
August 11, 2014
I used Disable Driver Signature Enforcement now my monitor,mouse and keyboard wont turn on what do i do in this situation?