WMI PROVIDER HOST CRASH AFTER CUSTOM SCAN

[chris13 0]

Hello,

 

I would just like to emphasize a new issue that i just discovered. After each computer scan but especially when i start a custom wmi database scan the WMI PROVIDER HOSTS crashes. This is what i found in the event log. And the same entry is created after each scan.

Can somebody assist?

Faulting Application Path:    C:\Windows\System32\wbem\WmiPrvSE.exe

Problem signature
Problem Event Name:    CLR20r3
Problem Signature 01:    wmiprvse.exe
Problem Signature 02:    10.0.19041.546
Problem Signature 03:    5da7ab91
Problem Signature 04:    System.Management.Instrumentation
Problem Signature 05:    4.8.4084.0
Problem Signature 06:    5dda3e38
Problem Signature 07:    40
Problem Signature 08:    132
Problem Signature 09:    FatalError
OS Version:    10.0.19042.2.0.0.256.48
Locale ID:    1033
Additional Information 1:    ba66
Additional Information 2:    ba665be9707b05c3401a25e345fcc5c9
Additional Information 3:    e321
Additional Information 4:    e321cd104b60201d6468d53bd9769b58

Extra information about the problem
Bucket ID:    45782a9a1a61f26c27dfe8789c869ae9 (1720349187398605545)
 

Regards

Chris

[Marcos 5,443]

An issue like this was already investigated. Unfortunately there's no solution to it and we can only recommend disabling WMI scan.

Theoretically the issue might resolve with some Windows updates.

 

[itman 1,799]

1 hour ago, chris13 said:

especially when i start a custom wmi database scan the WMI PROVIDER HOSTS crashes.

I wouldn't advise doing this.

Appears Eset has recently optimized its Smart scan regards to WMI scanning to do so efficiently with minimal conflicts.

[chris13 0]

21 hours ago, Marcos said:

An issue like this was already investigated. Unfortunately there's no solution to it and we can only recommend disabling WMI scan.

Theoretically the issue might resolve with some Windows updates.

 

This is not a microsoft issue. It is ESET that needs to solve the problem. The same error appears after a computer scan not only wmi. 

[Marcos 5,443]

You can open a support ticket. However, there have been several cases of wmiprvse.exe crashing and an analysis by developers showed that they all were caused by a bug in MS Windows (lazy garbage collection). Handles remained open until there was a serious shortage of them and as WMI scanning opened new handles continuously garbage collection seemed not to release them fast enough.

And removing scanning of WMI completely because of occasional crashes on some machines was not an acceptable solution since WMI is an object where file-less malware is typically stored.

[shocked 60]

i'd suggest those  affected by that issue to use the feedback hub app in windows 10 to report it and send logs as requested by the app so the MS dev team can fix it.

Edited March 27, 2021 by shocked

[peteyt 396]

1 hour ago, Marcos said:

You can open a support ticket. However, there have been several cases of wmiprvse.exe crashing and an analysis by developers showed that they all were caused by a bug in MS Windows (lazy garbage collection). Handles remained open until there was a serious shortage of them and as WMI scanning opened new handles continuously garbage collection seemed not to release them fast enough.

And removing scanning of WMI completely because of occasional crashes on some machines was not an acceptable solution since WMI is an object where file-less malware is typically stored.

Has anyone from Eset contacted Microsoft about this? I can see this being brought up a lot until it is fixed 

[itman 1,799]

18 minutes ago, peteyt said:

Has anyone from Eset contacted Microsoft about this?

I expect MS's response will be that Eset is scanning WMI in an improper fashion. In other words, we have the classic " You're at fault. No, you're the one at fault."

[chris13 0]

27 minutes ago, itman said:

I expect MS's response will be that Eset is scanning WMI in an improper fashion. In other words, we have the classic " You're at fault. No, you're the one at fault."

In my humble opinion this need s to be sorted out between Microsoft and Eset. Disabling wmi scan is not an option as it leaves you vulnerable. As far as i remember the famous stuxnet took advantage of wmi technologies. 

One more thing: After computer scan not only does wmi host provider crash but there is also a handle leak taking place. 

[itman 1,799]

I believe the resolution to this issue lies in why some have it and others do not. I for one have never encountered it since it was implemented on any Win 10 version running. The only complaint I have is that the WMI event log is filled with errors after an Eset off-line scan is run. I just clean the log after a scan to get rid of them.

What have observed is the WMI repository scan is much faster now that it was when the feature was initially implemented.

Here's an article by Microsoft on diagnosing WMI issues: https://techcommunity.microsoft.com/t5/ask-the-performance-team/wmi-common-symptoms-and-errors/ba-p/375483

Edited March 27, 2021 by itman