On this system the WLAN AutoConfig service will not start:

In error log/system:

"The WLAN AutoConfig service depends on the NativeWiFi Filter service which failed to start because of the following error: Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source."

In error/log security:

"Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error. C:\Windows\system32\drivers\nwifi.sys"

I ran sfc /scannow and it found no errors.

I ran sigverif and it says that this file, along with vwififlt.sys are not signed.

Next I uploaded nwifi.sys and vwififlt.sys to virustotal, which says they are signed and Ok.

Finally I directly compared these files with the same files on another Windows 7 machine. They have identical sha256 and md5 sums, and the other machine thinks that they are signed.

What is happening?


Windows drivers often do not contain the digital signature within the actual file. Instead, all the signatures for a group of drivers are bundled into a single file called a catalog. If this file becomes damaged, all the files which it authenticates will be marked as unsigned. Windows will not tell you that it is really the catalog that is damaged, you just have to guess. It also won't tell you which catalog is damaged. The catalogs are stored in c:\windows\system32\catroot\.

You have to go to a working machine and run sigverif and then look at the log. You'll see a line like this for the file:

nwifi.sys 14/07/2009 2:5.1,2:5.2,2:6.0,2:Signed Microsoft-Windows-ClMicrosoft Windows

Microsoft-Windows-Cl is part of the name of the catalog containing this file's signature. Windows doesn't bother to tell us the whole file name and there are 11 catalog files which begin with this string. In order to find which one it really is you must install the Windows SDK to get the program signtool.exe. In the catroot folder, under a long CLSID, you will find a bunch of files which begin with this string. In order to figure out which one is damaged, use signtool to try to verify nwifi.sys. Eventually you'll find it:

signtool verify /a /c c:\windows\system32\catroot\{F...}\Windows-Client-Features-Package~31bf3856ad364e35~amd64~~6.1.7601.17514.cat c:\windows\system32\drivers\nwifi.sys

This command will succeed on a normal Windows 7 machine (with wifi). On the problem machine it fails. After comparing the catalog files I found they were different, and indeed Windows would refuse to open the damaged one if I double clicked it directly. Of course it would offer no clue at all what the problem was until I already figured it out.

So at this point to fix the machine you simply copy the catalog from the working machine to the broken one.

  • Actually the information here is somewhat wrong, because it discusses two different types of signatures. One is the signature created by the vendor who authored the driver; the one on the catalog file, however, is the counter-signature from Microsoft. It may stem from simple attestation signing or even from the vendor going through all the hoops of sysdev/HLK testing. So a driver file may be signed by the vendor only or by the vendor and counter-signed by Microsoft through attestation or logo-signing. The latter is checked by asking signtool.exe to use the kernel signing policy! – 0xC0000022L Oct 16 '17 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.