Troubleshooting Boot Issues due to missing Driver signature (x64)

re: Troubleshooting Boot Issues due to missing Driver signature (x64)

Dave Morse — Wed, 07 Nov 2012 18:34:32 GMT

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.

re: Troubleshooting Boot Issues due to missing Driver signature (x64)

Parthiv — Sun, 08 Jul 2012 10:34:08 GMT

slui 0x2a is the command to resolve win32 error codes

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

re: Troubleshooting Boot Issues due to missing Driver signature (x64)

Thorkell — Thu, 17 May 2012 14:07:31 GMT

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?

re: Troubleshooting Boot Issues due to missing Driver signature (x64)

Arijit Roy — Wed, 25 Apr 2012 05:47:22 GMT

A very useful article indeed :)

re: Troubleshooting Boot Issues due to missing Driver signature (x64)

Ian — Sun, 15 Apr 2012 22:16:16 GMT

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

re: Troubleshooting Boot Issues due to missing Driver signature (x64)

Paul Haldane — Sun, 15 Apr 2012 18:31:16 GMT

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?