New
#31
That's certainly an option. Mark
CAPI2 Errors
-
-
New #32
These errors have frustrated others and MS took forever to provide a fix which doesn't appear to solve your problem.
This thread is not your solution but just example that your frustration has been shared.
CAPI2
McAfee has been accused in the past as being one cause.
After I installed SP1 I never had the CAPI2 reporting problem.
Maybe just ignore them. Event logs clearly have a purpose but if they get full of rubbish you can clear them
Event Viewer One Click Clear
-
New #33
I developed Event ID 4107: CAPI2 errors at the precisely same time as the initiator of this thread. These errors became much more frequently after I installed SP1, switched Antivirus programs from McAfee to BitDefender, and upgraded to IE9. The log of CAPI2 also identified the system program lsass.exe as having a security certificate issue as well as consent.exe (system program), dwm.exe (system program) and SeaPort.exe (Windows Live program):
lsass.exe, 80092014 The certificate is not in the revocation server's database & 800B0109 A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.The invalid certificate associated with authrootstl.cab when attempting to manually install from http://www.download.windowsupdate.co...c/trustedr/en/ is apparently a red herring:
consent.exe, 80092013 The revocation function was unable to check revocation because the revocation server was offline.
SeaPort.exe, 800B0101 A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.
dwm.exe, 80092013 The revocation function was unable to check revocation because the revocation server was offline.
As for the certificate status, it is marked as "invalid for this purpose" because the UI expects a different EKU rather than the one used by automatic root update. The CTL UI expects the signer to contain the Microsoft Trust List Signing EKU. However, the automatic root update mechanism uses a different EKU (Root List Signer) and as part of certificate chain validation, Windows checks for the presence of the Root List Signer EKU in the CTL signer chain. In this case, the chain is valid for the Root List Signer EKU. (see Event Log CAPI2 4107 and CAPI2 errors driving you crazy? - THE OFFICIAL BLOG OF THE SBS "DIVA").Thus the Event ID 4107 error message “A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file” refers to problems identified above rather than the integrity of authrootstl.cab itself.
It is not clear how serious Event ID 4107: CAPI2 actually is. Perhaps this error is just a consequence of overly paranoid system “nanny-ware” or of Rube-Goldberg-type convoluted security measures. Since no resolution to this issue appears to be imminent, the nuclear option of reinstalling the entire system seems the only solution. This will (hopefully) also improve the greatly degraded boot performance that I have experienced after a year of Win 7 use. Full scans by McAfee, BitDefender, Malwarebytes and MS Safety Scanner have not revealed any signs of infection. Kudos to Mcd73165 for braving the MS chicane and sparing us some additional frustration.
-
New #34
Wunderteam, thank you very much for your input and kind words.
-
New #35
I hope I'm not being premature but I think I finally resolved this problem, at least for my case. This link, Event ID 4107 or Event ID 11 is logged in the Application log in Windows and in Windows Server does not include the CryptnetUrlCache for 64Bit systems which is located in C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Microsoft\CryptNetUrlCache\Content and C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Microsoft\CryptNetUrlCache\MetaData. After (once again for like the 5th time) following the procedure in the Microsoft fix link above and also deleting the CryptNetUrl cache in C:\ Windows SysWow64, I rebooted several times to confirm there were no more CAPI2 Errors. I'll post again after I definitely confirm this fix is valid after a day or so. I'll keep my fingers crossed! (I found this information about the Wow64 Cache while frantically searching for a fix. I don't want to take credit away from whoever originally figured this out. I can't seem to find the link again where I got this info from).
-
-
New #37
I am getting to old for this. I remember that fix and for some reason I thought it was included in the MS FixIt but I was wrong. It worked last time and it worked again this time. I have now saved the FixIt file and a text file with the missing cache location. Maybe next time (and there will be a next time) I will get it fixed the first time.
Jim
-
New #38
MJF, it was the CAPI2 link that you provided that led me to the solution. Apparently, some of you already went through this mess back in 2010. So far there have been no more CAPI2 errors on my machine. This whole thing then with the invalid trust list certificates which I thought were the sole cause of my problem was then related to some bad entry in the SysWOW64 CryptNetUrlCache. This is a bit above my level of understanding.
-
New #39
I e-mailed Microsoft Support (for whatever it's worth) telling them that they should update their Fix It link Event ID 4107 or Event ID 11 is logged in the Application log in Windows and in Windows Server to include Windows\SysWOW64 CryptNetUrl entries for 64 Bit systems. This will save a lot of people a lot of aggravation if this CAPI2 4107 error problem is ever encountered. Thanks to everyone that provided input to this thread.
-
New #40
Hopefully MS will take include the addition.
Quote
Related Discussions