Jump to content

Windows Security Center Service unable to load instances of AntiVirusProduct from datastore.


Zardoc

Recommended Posts

same issue started with ver 17

 

The Windows Security Center Service was unable to load instances of FirewallProduct from datastore.

The Windows Security Center Service was unable to load instances of AntiVirusProduct from datastore.

Link to comment
Share on other sites

  • Administrators

Unfortunately I haven't received any ELC logs as requested except from @Zardoc who had the Security Center service not running which is a prerequisite for any AV to register in the system. Please supply logs collected with ESET Log Collector. Also raise a support ticket since I'm unable to reproduce the error on Windows 11.

Link to comment
Share on other sites

Hi Marcos,

I did not change that setting. It changed to that after update. So, there is that is turning off the security center with this update.

I installed Version 16 and the security center works fine. Why is it not starting after this update. That's something that either the update or a command in the coding is not right with Windows perimeters and doesn't turn on the security center.

I and I'm sure neither of those who posted have messed with the Security Center settings, before or after install.

Edited by Zardoc
Link to comment
Share on other sites

1 minute ago, Purpleroses said:

So is my computer protected even with these two event id?  My Windows Security Window looks like this one.

If you look hard right on your image, it's stopped. So same issue.

Edited by Zardoc
Link to comment
Share on other sites

One thing that needs to checked by those seeing these Eset ver. 17 Security Center error Win event log entries is to verify if Microsoft Defender is running concurrent with Eset.

Using Process Explorer or Win Task Manger, check if mpengine.exe is running.

Edited by itman
Link to comment
Share on other sites

Based on the fact that Security Center is accessible via its desktop toolbar icon and Eset is being properly registered as the Win AV real-time solution: https://forum.eset.com/topic/38760-windows-security-center-service-unable-to-load-instances-of-antivirusproduct-from-datastore/?do=findComment&comment=176096 , I would say that these Win Security Center error Event log entries can be ignored.

Link to comment
Share on other sites

I've been on this forum way before it was just an Eset Forum and I even recommended Eset on my own website for many years. Aryeh knows me and I usually don't post because there's nothing good on TV. I install Eset on all my customers machines and my customers are important.

I hope Eset sees it the same way.

So, I am not asking if I should ignore error messages. They aren't publicity messages. When they show up it means something is wrong. Is it major? I don't think so. Am I going to ignore it ?

I'm trying not to. But with the kind of comments I'm getting and with the experience I have I'm close to dropping this and running back to version 16.

I gave a full log and it showed clearly Security Center was not turned on.

So my question is simple @Marcos why is version 17 not turning on the security Center on boot and is Eset looking for a fix?

So if you want to keep giving replies that have no foundation to getting a fix, i'll get back to my customers and install something else until I see someone cares because it doesn't seem like it. 🙄

 

 

 

 

Link to comment
Share on other sites

  • ESET Staff

Windows security center service is a delayed start service by default. We have quite elaborate waiting system for that service.

1. We have a system notification registered for start of `wscsvc` service.

2. When notified by system, we try to ask via WSC API if there are some data. If it is still initializing it returns `ERROR_SERVICE_NOT_ACTIVE`

3. If that happens we register a notification to the WSC itself, to tell us when it is ready. Otherwise we start issuing requests.

4. If the initialization took more time and notification comes from WSC, we start issuing requests.

 

Events (error) with Id 16 are expected and according to the specification from MS. If our application changes certificate, the request to update status fails with certain error. When this error occurs we are obliged to register again and then report requested status. You can see that in event log those 2 errors with Id 16 are followed by Id 15 Events (informational) that we successfully reported status.

Events (errors) with Id 18 and 19, are from initialization of the `wscsvc` service itself. Actually just checking that I got those errors on my machine too on 20.11.2023, probably reboot after upgrade to new Endpoint v11. It might have been just a coincidence. Also logged 0x8007000D (should be something like `ERROR_INVALID_DATA`) is not coming from our provider requests, since the errors are followed by event with Id 1 (start of the service) and even with Id 15 (successful reports of status).

 

Edited by JozefG
Link to comment
Share on other sites

  • ESET Staff

Tried to investigate the issue more. After checking our WSC module logs I was suspecting the read request (point no.2) to being somehow involved, as its time was very close to logged events. Using custom built 1038 without the read request issue still persists.

Next I disabled startup scan as someone was mentioning it earlier in this thread. Still no luck and issue persists.

Link to comment
Share on other sites

Hi JosefG,

Thanks for the the explanations. I hope you can sort it out. I'll just tell my customers to be patient. AV works fine. It's just cranking the engine takes more time and the carburetor needs an adjustment.

That's an explanation they'll understand. 🙂

Link to comment
Share on other sites

The 17-version is offered several times , but will stay on 16-version , untill its been fixed .............though dont understand WHY( ??) it takes sooo long !

Link to comment
Share on other sites

@pete12, sometimes we don’t understand the implications of coding, especially with security software. You can’t always say, let’s add a comma to the line and it’s fixed. MS has stringent settings for security and also updates their code on the OS. So, what Joseph explained is that he sees the problem and is trying to see where the code doesn’t align with the Security Center and they will try to fix the problem on their end (if it is their problem).

Pushing people to fix something fast is never good. It frustrates everyone and is a waste of time. 

It’s like making a soufflé. “The hardest part of making a soufflé is when you incorporate the beaten egg white with yolks, and the rest of the batter. You have to be very careful to fold the egg whites slowly, so that they don’t melt.” 😜

When people take their time to fix something, the chances of success are better.

Getting an explanation acknowledging the issue and trying to find a fix tells us at least someone knows about it and they will try to fix it as soon as it is possible.

 

Link to comment
Share on other sites

  • Administrators

I've started getting the error after installing one of the recent Windows 10 updates. Before there were no errors logged when v17 was installed.

Link to comment
Share on other sites

3 hours ago, JozefG said:

Next I disabled startup scan as someone was mentioning it earlier in this thread. Still no luck and issue persists.

Now that ver. 17 is available via in-product update option, I decided to do so and I am now also receiving the Win 10 WSC errors at system startup time. The following is important and might aid in the resolution of this issue.

Early in this thread I posted I was not encountering this WSC issue when I had previously tested ver. 17. Here's the details of that previous testing. I had downloaded the early release of ver. 17.0.13 via forum provided link. I installed ver. 17.0.3 on top of my existing ver. 16.2.15 installation. No WSC Win event log errors immediately after ver. 17 installation or thereafter.

This leads to the following conclusions;

1. Something changed between ver. 17.0.13 and 17.0.15 release.

2. There is a problem with the in-product upgrade processing in regards to ver. 17.0.15.

Edited by itman
Link to comment
Share on other sites

  • Administrators

With v17.0.15 installed and updated on a Win10 system without recent uodates there were no errors. Between v17.0.13 and v17.0.15 there were no changes but certain strings were amended in the Japanese gui.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...