Error -198: Failed to add scan package service. HRESULT: -2146762487

[houghton]

The above error in BP is thrown.

I have five hosts on my closed network here. Three are tablets running Win8.1 and then two desktops running Win7. I downloaded the cab file this morning and ran BP to “Retrieve consolidated url list of available updates”. 4 of the 5 hosts threw an error, the two desktops produced what is in the title. 2 of the tablets produced a HRESULT: -2147024894. I ran a TaskKill on the 4 faulty hosts. I ran the “Retrieve…” again and tablets took this time, but the workstations continue to show the error in the title above.

I read the forum posts on this issue about the erroneous cab file from Microsoft and bad certs. All the certs checked out, but I re downloaded anyway, deleted the first downloaded cab, pasted new cab in cache folder, and tried again, same error message. Then I went to my two desktops and removed the cab file from the C:Program FilesBatchPatch folders and try again with a THIRD downloaded cab file from Microsoft.

The credentials all match. The cab files have all matched and contained all the same certs. The cab file copies correctly to all hosts.

Why did the tablets work out but not the desktops? I am using BP on one of the desktops to do all of this work so the other desktop just sits idle, just like the tablets. I don’t understand why the tablets worked fine but not the desktops?

I just tried it for a fourth time, this time using a different thumb drive and the error was just thrown again.

The file does copy correctly and it appears to begin Executing BatchPatchRemoteAgent.exe… but 90 seconds later the error message is shown.

[doug]

Error -198 indicates that there was a problem when BatchPatch tried to add the scan package service for the WsusScn2.cab file. The HRESULT value is the reason code.

---

HRESULT -2147024894 translates to:

0x80070002 -2147024894 ERROR_FILE_NOT_FOUND

The System cannot find the file specified

This would only happen if the file itself did not exist on the target computer when the scan was initiated. It sounds like you got this resolved.

---

HRESULT -2146762487 translates to:

0x800B0109 -2146762487 CERT_E_UNTRUSTEDROOT

A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider

This indicates that the certificate on the WsusScn2.cab was signed by an untrusted CA. This is not the same problem that you read about in other forum postings that described some cases where the WsusScn2.cab file contains no digital certificate. In this case the .cab file is signed, but the issue is that the certificate is not trusted by the target computer(s). I suspect that you have not used Windows Update on these target computers for a very long time, and now the certificate authority that Microsoft is using to the sign the cab file is not in the trusted root store of the target computers. This does not mean that there is a problem with the WsusScn2.cab file. Probably the file itself is fine and legitimately signed. However, since your target computers are probably either an old OS (you didn’t mention which OS they are) and/or they have not been updated in a very long time, the trusted root store simply does not contain the CA that Microsoft used to sign the .cab file.

I think you just need to get the CA to be included in the trusted root store on the target computers in question. I’m not sure the exact path to make this happen. You might be able to simply view the details of the certificate (right click on the WsusScn2.cab file and then select the ‘digital certificate’ tab, and dig in to ‘view certificate’), and then once viewing the certificate you might be able to simply click a button to import that cert. I think this might depend on which OS you are running on the targets, and I’m not 100% certain that this is the exact correct method. When I look at the cert for the most recent .cab file that I just downloaded, the CA is ‘Microsoft Code Signing PCA.’ I believe historically the way that Microsoft has modified the trusted root store on Windows computers is by publishing a Windows Update with the desired/needed updates. In your case since the computers do not have internet access it seems like you would need another way to get the trusted root store updated. If the method that I described above does not work, then I wonder if maybe you can export the cert from a computer that has it to then import on the computers that do not have it. I’m not sure, but hopefully I’ve given you enough information to go on so that you can get it worked out. If/when you get it worked out it would be great if you could post here with the exact steps you took to get the trusted root store updated.

-Doug

[houghton]

Thank you for your reply.

I attempted to install the Digital Signature Certs both automatically and then by placing them in the Trusted Root Certification Authorities store. No change in BP though as the same error and HResult number is shown.

These are Win 7 desktops that I have been running BP on quarterly for 9 months now, this is my 4th update. With that in mind, I went back and checked the previous wsusscn2 to review their Certs and the last I one I used in May, had the same Certs. The only difference was the timestamp of the Signature on the Cert.

I have not made any progress. I am doing some more searching but perhaps this extra information may provide something you can think of.

[doug]

Very peculiar. At the moment I don’t have any great thoughts, though it might be interesting to see if the old WsusScn2.cab is still able to scan successfully without producing this error. Are you able to test with the old .cab file that you used successfully back in May?

[houghton]

I just tried the .cab file from May and it was copied correctly to both desktops but did throw the same error. -198: Failed to add scan package service. HRESULT: -2146762487.

What services need to be running for BP to work correctly? I am guessing here but maybe an update from May has stopped a service that needs to be running.

[doug]

I don’t think this issue is due to a service being stopped. You can see which services need to run for BP here. However, what you are experiencing is not a BP error, per se. It’s being thrown by the Windows Update Agent, and the HRESULT code in this case is *not* ambiguous. It would be highly unlikely that CERT_E_UNTRUSTEDROOT exception is somehow being thrown erroneously due to some other problem. The issue has pretty much got to be somehow relating to the certificate and root store. It’s very peculiar that you would see the same issue now occur with both the old and new WsusScn2.cab file even though in May the old WsusScn2.cab file did not cause any problems. I believe Windows has, in addition to the trusted root store, an untrusted root store. This is described here: https://blogs.technet.microsoft.com/srd/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store/

Perhaps somehow your problem machines have revoked a valid cert and maybe even the cert that was used to sign the .cab file is located in the untrusted store?

If you believe the issue occurred from a previously installed update, you could consider removing the last group of updates that you applied in May to see if there is an effect. I unfortunately do not have any better suggestions at the moment. If I think of anything I will post it here.

Thanks,

Doug

[houghton]

A little update, I haven’t solved it yet. I did address a couple of Certificates but no dice.

I have found that the error could be linked to the HomeGroup Listener. I try to start the service and I am unable to. Does this ring a bell of any kind?

My next step is to roll back some of these updates from May (my last successful BP update), but I wanted to ask about the HomeGroup Listener.

[houghton]

Also, when and where would I see PsExec when BP is running? Services? Task Manager?

[doug]

I can’t imagine how the HomeGroup Listener service would have anything to do with producing the error that you are seeing.

With regard to your question about PsExec: On the computer running BatchPatch you would see psexec.exe in task manager processes list only *during* execution of remote actions. Also note that not all remote actions will utilize psexec, so you will only see it running for actions that do utilize it. Additionally on the remote computer you will see psexesvc.exe running in the task manager processes list during execution.

NOTE: the certificate error that you are receiving would be completely unrelated to psexec. Psexec appears to be running properly in your case. The certificate error is occurring *after* psexec is already successfully running and after the batchpatchremoteagent.exe is already successfully running on the target computer. The batchpatchremoteagent.exe tells the Windows Update Agent (WUA) to load the WsusScn2.cab file. It’s during this process when the WUA tries to load the .cab file that the WUA returns the HRESULT -2146762487 to the batchpatchremoteagent.exe. This HRESULT means that the certificate chain terminated in an untrusted root certificate. I cannot imagine any scenario in which this error could/would occur for any reason other than something relating to certificates and the trusted root on the target computer.

I hope this helps.

-Doug

[houghton]

After I post the HG Listener, I realized it was off. I searched the HRESULT and got some feedback from that about it.

I have been adding certs and am just not getting anywhere. Very frustrating. If you think of anything else, other than what you have added, please reply again.

Thank you for your efforts, THE FIGHT continues…..

LOL, just got the same Error -198 as I was about to hit enter. This is ridiculous.

[doug]

FYI for the sake of google searching I would recommend that you search the HEX representation of the HRESULT, which is 0x800B0109. Searching the decimal representation (-2146762487) probably won’t yield as much.

-Doug

[houghton]

Yes sir, I have been down that road. Still working on this.

[houghton]

If I am running BP completely offline. What certificate does BP, or the wssusscn2 file, use to typically verify when using the program?

[doug]

I think you are misunderstanding how it all works. You might consider reviewing general PKI concepts to better understand how it all works, or you may just reach out to a coworker who has experience with PKI and security fundamentals to help you troubleshoot, but essentially the WsusScn2.cab file is signed by Microsoft. The act of “signing” is a way to authenticate that the file actually came from Microsoft. When the scan is initiated the WUA attempts to validate the signature. It sees that the file was signed by ‘Microsoft Code Signing PCA’ and then it looks in its trusted root store to see if it has a corresponding certificate for Microsoft Code Signing PCA which is what tells is that it can trust or not trust a file that was signed by Microsoft Code Signing PCA. If the trusted root does not contain the proper certificate, then it will say that it can’t trust the file. This is not an outright rejection saying that the file is invalid or bogus or cannot ever be trusted. In your case it’s just saying something along the lines of “we don’t know if we can trust this file because our trusted root store does not have a signature that says we can trust it.” Considering that your previous WsusScn2.cab file worked fine in May but no longer works due to this error implies that somehow the trusted root store has been modified, and it no longer contains a certificate for Microsoft Code Signing PCA even though it used to contain the cert and should still contain the cert. But if you can get the appropriate certificate imported once again into the trusted root, then the WsusScn2.cab file should pass the certification check. It’s unclear to me what would have removed the cert from your trusted root. This is peculiar, unless an administrator came in and emptied the trusted root store. Perhaps another option would be to use System Restore and see if you are able to revert the computer back to a time prior to May when things were working properly. This will also end up uninstalling updates that were installed since that time. But that would/should be ok because you can then just install them anew.

-Doug

[houghton]

Thank you for your time. I was hoping that the name(s) of the certificates where known and I could simply update them. I understand the handshake part of the process, but I figured the actually certificate in the Trust Root Certification AuthoritiesCertificates that makes the Wsusscn2 file authenticate would be known as my folder contains 43 certificates. I believe the Intermediate Certification AuthoritiesCertificates folder is suppose to contain a certification to enable this process too. BP has a major WU portion, so I was hoping the certifications needed were known. If they are known, please reply.

My workstation involved with this BP process does not create restore points, as its security guide does not allow it. I have not started the process of uninstalling the May updates yet, but I guess that is the hopeful answer here. My other workstation on this network is throwing this same error, so I guess the last round of updates just didn’t mesh well with the workstations. Perhaps the error will show itself.

Thank you again Doug for your help and patience.

[doug]

Ok no worries. Sorry about that. Based on viewing the cert chain on the WsusScn2.cab file I would think that the certificate that needs to be in the trusted root store is the Microsoft Root Certificate Authority. I conclude this based on looking at the ‘certification path’ tab of the certificate for the WsusScn2.cab. The path ends with the Microsoft Root Certificate Authority. And I can confirm that I have this Microsoft Root Certificate Authority listed in my trusted root CAs snap-in. If I were you I would look to see if you have it showing and if you can see that the dates on it are valid. I hope this helps. Let me know what you find.

-Doug

[houghton]

Hey Doug,

Thank you again. I have check the certifications and here is what I have found.

Microsoft Root Authority 12/31/2020

Microsoft Root Certificate Authority 5/9/2021

Microsoft Root Certificate Authority 2010 6/23/2035

Microsoft Root Certificate Authority 2011 3/22/2036

There is also a

Microsoft Authenticode(tm) Root Authority 12/31/1999

But I don’t believe that last one has anything to do with this as, is was right before Y2K, Microsoft must have released something else that picked up where that left off.

The four listed at the top match some of my other machines (that are not part of this closed network), so I am assuming these are all good.

My current course of action is to attempt to turn off this validation of signature step. Do you know if this is possible? I am searching.

I understand that this is out of scope for you at this point. Thank you again for your assistance.

[doug]

My trusted root store shows the same CAs as yours. This is so weird. Are you absolutely sure that you have been providing me with the correct error and HRESULT? Is there any possibility that you mixed things up? The -198 error can occur with a number of different HRESULTS, so possibly you saw -198 but assumed the HRESULT was the same when it was not? This might be a stretch, but I want to confirm because it has happened before with other users.

I think the likelihood of being able to disable signature validation is almost nil. I think that you have a couple of more realistic options…

0. Try running the Microsoft Baseline Security Analyzer on the targets. It uses the WsusScn2.cab also (at least it used to, but I have not used it in a very long time) https://www.microsoft.com/en-us/download/details.aspx?id=7558 See if it scans successfully or if it throws a similar certificate error. If it works and gives you the list of available security updates, then you can download these and install them manually or download them and then use BP to deploy them with the ‘Deploy’ feature in BP.

1. If possible, provide temporary internet access to these computers, and then perform the scan in online instead of offline mode.

2. Manually figure out what updates Microsoft has released for these computers in the past few months, and then download all of them manually for installation. Since Microsoft switched to cumulative update model not that long ago, it might not be that challenging or time consuming to do this (unless Windows 7 isn’t using that same cumulative model– I can’t remember off the top of my head if it is or is not). You could still use BP to deploy the standalone updates to the computers using the ‘Deploy’ feature in BP. But you would need to obtain the correct updates from Microsoft manually first.

3. Try uninstalling May’s updates from these computers and see what happens.

Good luck and keep me posted.

[houghton]

The error is the value shown. Lol, I have seen it about 35 times in the past three days.

I did check the installed updates though and found something interesting. The updates from round 1 back in November 2016 are listed. The updates from round 3 in May 2017 are there. The updates from round 2 back in February 2017 are there but they have a May 2017 date. It is as if they were install on 5/2/2017 but should have been installed on 2/28/2017. The dates go from Nov16 straight to May17. The updates performed in February took over a week to complete but are now listed as updates that occurred in May.

I do have the option to use a restore point too, so I am keeping that as an option. I like your idea of using the Baseline Analyzer to see if it will use the cab file.

[houghton]

Update. I had to roll back to the last critical update. While this is not what I was hoping for, the search is now taking place and should update without issue.

Going to test after the update completes to make sure that the search process will commence as it has in the past. Feeling good about this one!

[doug]

Excellent. Keep me posted on how things progress!

Thanks,

Doug

[doug]

More recently we’ve learned of two possible causes for this error. 1: If you are trying to apply updates to an operating system that Microsoft is no longer supporting and delivering updates for. If you have not purchased an Extended Security Update (ESU) package from Microsoft, you might need to do this. 2: You have not installed the most recent servicing stack update (SSU). Try manually applying the most recent SSU for the OS in question, and it’s likely this error will go away.

[Author]

Posts