WMI-Activity errors in windows event logs

[countingtls]

Rules

• [X] I made myself familiar with the Readme, FAQ and Troubleshooting.
• [X] I understand that, if insufficient information or no app logs will be provided, my issue will be closed without an answer.

What's wrong?

I've been using and testing Ghelper in recent months, and it generally worked fine.

But when I was testing the latest pre-release (v0.154), I found that my ROG Flow Z13 now would randomly crashes/freezes from time to time some hours after rebooting. I dug in the Windows event logs to check what might be the possible causes, and I found the log is filled with continuous WMI-activity errors every 2 to 3 seconds every few hours (Event Id 5858, ResultCode 0x80041032, ). And when I looked up the ClientProcessId, it was GHelper.exe causing this.

I looked up this error, and Microsoft Learn said it was caused by WMI application calls IEnumWbemClassObject::Next with a timeout value that is too short before it can return and be queried again (query battery status info? or Idle status?). When I switched back to the older version 0.152 pre-release, this occurred at lot less (and when this happened, it is 4 or 5 WMI errors in a roll at the same timestamp, instead of every few seconds continuously for quite a long duration). Although it might not be a big issue normally, however, at a high workload, the constant logging could cause unforseen consequences, which might contribute to the random crashes (the crash almost always happened at high workloads with full CPU/GPU running tasks, I suspect it has something to do with my GPU overheating, and I thought at least report this one issue first). When I turned off Ghelper this error completely stopped so besides the PID, it has to be related to changes in Ghelper.

I tested the v0.151 release version as well, and it generally behaved the same as the v0.154 pre-release with WMI errors for some minutes after some hours but quite rare and doesn't last that long. I've always noticed my NB crashed from time to time, but before switching to GHelper, ASUS AC caused a lot of problems and freqent crashed daily, and I was glad they reduced to about once every week or so with Ghelper. I thought it was other issues causing the crashes and I haven't seen this frequent WMI errors before.

How to reproduce the bug?

Just start up the Ghelper v0.154 pre-release version, and check Windows Event Log

Logs

log.txt

Device and Model

Asus Rog Flow Z13 GZ301VV

Additional information.

Armoury Crate

Uninstalled

Asus Services

0

Version

0.154

OS

Windows 11 22H2

[seerge]

@countingtls hello, I honestly have no idea what do those things mean.

G-Helper uses WMI mainly to get model name on launch :) and listens for some events from asus driver.

Absolutely nothing has changed in relation to that in last builds at all.

May be your windows is acting or has damaged / broken WMI?

It was someone yesterday, who had broken wmi so couldn't launch the app. Fixing wmi helped them

Check that issue and what they did https://github.com/seerge/g-helper/issues/2090#issuecomment-1953804447

[seerge]

@countingtls P.S. did you try running windows repair as mentioned in troubleshooting section?

https://github.com/seerge/g-helper/wiki/Troubleshooting#repair-corrupted-system-fails

[seerge]

P.P.S. If you think it's something with reading current battery charge, app checks for that only when main window is visible.

So you may close it to verify.

But it would mean something is wrong with windows / system if simple battery charge reading causes issues for you. And it needs to be fixed outside if the app ...

[countingtls]

I've actually already tried the above suggestion, reset winmgmt, still the same.

The troubleshooting like repairing system files with sfc /scannow; asus system interface (I have a traditional Chinese interface, so I have to update it from our local website), hardreboot, the only thing I haven't tried is to completely uninstall and then reinstall GPU drivers (although it is already up to date, and I seriously doubt it is the cause, I might tried it anyway later)

And nothing worked, the only thing that works is to simply stop Ghelper, and there is no WMI errors, and the only function I need for it is to keep the keyboard light on and lower the battery charge level, and I can seriously live without these features with Ghelper. I doubt I am the only one who runs into this problem since there are almost no symptoms besides thousands of Windows logs every day and high CPU usage when they are triggered (especially noticeable when it is already at high workload, the CPU fans will spin up out of nowhere). If not for the crashes/freezes, I wouldn't even check the Event log often (these constant WIM error logs didn't exist last time I checked when I was still using ASUS AC).

Since it is not solved, I don't think it is fair to close it just because

[countingtls]

P.P.S. If you think it's something with reading current battery charge, app checks for that only when main window is visible.

So you may close it to verify.

But it would mean something is wrong with windows / system if simple battery charge reading causes issues for you. And it needs to be fixed outside if the app ...

I've checked and tested if it was during reading battery information, and no it even happened when I was not in front of the computer. And the event details in Event log files also showed these error are triggered by various operations

Start IWbemServices::ExecQuery - root\wmi : Select from NvWmiBrightness Start IWbemServices::ExecQuery - root\wmi : SELECT FROM WmiMonitorBrightness which would happened several times in the same timestamp second, and then

Start IWbemServices::ExecQuery - root\cimv2 : Select from Win32_ComputerSystem Start IWbemServices::ExecQuery - root\cimv2 : select from Win32_Processor Start IWbemServices::ExecQuery - root\WMI : SELECT FROM BatteryFullChargedCapacity Start IWbemServices::ExecQuery - root\WMI : SELECT FROM BatteryStatus Start IWbemServices::ExecQuery - ROOT\CIMV2 : select ChassisTypes from Win32_SystemEnclosure Start IWbemServices::ExecQuery - ROOT\wmi : SELECT * FROM WmiMonitorConnectionParams Where a lot of these errors happened a few seconds apart. This is like a full refresh of the information for Ghelper, and looping in minutes after minutes

Start IWbemServices::ExecQuery - root\WMI : SELECT * FROM BatteryStatus happened the most often (several times often and they all group together), and if I used v0.152, almost all of the WMI errors came from this operation (which is sort of why I originally thought it has a lot to do within reading battery status).

Although there are other WMI errors sometimes as well, which are also extremely weird, they are caused by Microsoft-Gaming-Services, but Event data are EventData

Message NULL Function NULL Error Code -1994174180 Source
Line Number 1146

Which is related to GameInput Service has duplicate names I believe, and they have been there after some last year's Windows updates, and they didn't happen often (like every few days)

[seerge]

@countingtls oke, so it looks like pretty much any wmi query causes errors on your device?

Also if they come from other apps (like microsoft services)

What do you propose me to do?

I was thinking about making battery check less frequent , but since everything else from wmi is broken on your system, i'm not sure how to help :)

[seerge]

Did you try method 2 here?

https://answers.microsoft.com/en-us/windows/forum/all/cannot-access-the-windows-management/8849f190-cf4b-e011-8dfc-68b599b31bf5

[countingtls]

I was reading something interesting about New WMI arbitrator behavior (although it was discussed under windows server 2019, but I suspect simliar mechnism has to exist in all the WMI)

It describe that a patch has solve a long time issue-

"there was the potential for a query that uses a large amount of memory to cause a deadlock condition in WMI if a client does not retrieve the results. In this case, if the offending query causes total memory usage to reach the threshold of 256 MB, all other queries are throttled (not executed) until the memory pressure decreases"

And the patch effectively "free up memory" with a clean up process, but with two side-effects.

1. The client is detected to be idle for longer than the time that is specified in the registry value, the task will be cancelled, and a 5858 error is logged with the possible cause "Throttling Idle Tasks, refer to CIMOM regkey: ArbTaskMaxIdle."

2. The cumulative memory usage in the arbitrator buffer reaches the 256-MB threshold, the cleanup process cancels queries, enumerations, tasks/requests that hold memory in Winmgmt. A 5858 error is also logged, with the possible cause "Throttling Idle/stack Tasks in hitting Max Memory quota."

There has to be some kind of memory garbage collection process existed in Win 11 WMI service as well, and they too need to stop handling the requests when it was running, which might explain why WMI-activity error would happen consecutively for minutes every 2 to 3 seconds and then they stopped, when the process is in progress, and the accumulation would reastart after certain amount of time (tens of minutes to hours depend on the accumulation rate). And this "new patch" from Microsoft can be very recent (the article discussing it was published 12/26/2023).

[countingtls]

Did you try method 2 here?

https://answers.microsoft.com/en-us/windows/forum/all/cannot-access-the-windows-management/8849f190-cf4b-e011-8dfc-68b599b31bf5

Yes, I did with manually rename and with winmgmt resetrepository which did the same thing (since when I go to the folder there is already a backup folder called repository.001 after I did the resetrepository command). And No it didn't help the issue, WMI-acitivies errors still persist after rebooting.

[countingtls]

@countingtls oke, so it looks like pretty much any wmi query causes errors on your device?

Also if they come from other apps (like microsoft services)

What do you propose me to do?

I was thinking about making battery check less frequent , but since everything else from wmi is broken on your system, i'm not sure how to help :)

@seerge

After reading something about WMI management and related issue, I feel this could well be a combinations of multiple issues. I already had another constant Event logs related to Microsoft-Windows-CodeIntegrity and Microsoft-Windows-Crypto-NCrypt that might be triggered by unrelated events, with some Windows patch which reject request when clean up process would run regularly and on-demand when memory exceed. The burst update and commands from Ghelper although not in great frequency, but continous in the background exacerbates my issue. I was still solving the previous two problems unrelated to Ghelper which could be other factors contributing to this (the NULL WMI logs from time to time between long intervals might be a "clue" and I will dig further into them to see when they are triggered).

Slowing down the check frequency might help a bit, maybe I can change some config in config.json to test this (or is refreshing frequency is written in the code, if so maybe adding a "feature" for power user that can manually change the refeshing setting in config)?

[seerge]

@countingtls this build should let you increase interval for battery checks

Just add

"sensor_timer" : 20000,

To the beginning of config.json and start app. Interval value is in milliseconds GHelper.zip

But since such basic wmi calls as getting model name also fail, it won't improve much for you

Given how many problems you seem to have, why don't you just do a clean windows install?

[seerge]

@countingtls any updates here?

[countingtls]

@countingtls any updates here?

"sensor_timer" : 20000,

The error log has a error code, 0x80041032, it is not actually "fail" failed, but as it is "busy" so the operation is cancelled internally, and it is an asynchronous process, so it could have been waiting and then been processed in batches, thus the differences in the behaviors for WMI errors (logging/triggering intervals, and different clearing period).

I actually solved the other two issues I mentioned earlier (related to codeintergrity and authorization fail from the Microsoft login assistant, it has a lot to do with my antivirus software and the rules I setup). And I was able to stop these log errors and I started to see other processes using WMI now also producing WMI "cancelled" errors (not just from Ghelper). And as I suspected these are kind of unrelated. And the system is working fine without crash/freeza since I've posted the last reply, and I've been doing experiements using my NB all day today.

What I can say for sure, is that by changing the sensor_timer to a differrent intervals, they are indeed reflected in the events that triggered, instead of every few seconds of the original settings, now they would pause roughly in the same intervals as the sensor_timer setting (I said roughly because as decribed above it is an asynchronous process, so it can be triggered by operation at the exact time interval, but logged at slightly off timestamp - 00:25 00:55 01:25 01:59 02:23 02:51, etc. They averaged out to about the interval in sensor_timer). This also confirmed one of my theory previously that it likely has to do with some automatic process to "unclugged" WMI since no matter what sensor_timer interval I setup, they always logged within a roughly 6 to 7 minutes time window. Hence previously, there were hundreds of logging within this period every few seconds, now only a few if I set the interval long enough (like I now set it to 30000, and only 12 to 13 during this "unclugging". And I didn't feel any different in the functionality of Ghelper (I mean who would visually check the battery status every few seconds to see how often it is updated).

This tiny added feature at least help those who rely on logging to analyze anomoly behaviors, and quite educational to dig deep into WMI mechanism (Microsoft actually changed WMI quite a bit over the years, they used to not relied on Event Logger to log WMI events, and then added a lot more "features" in the background/internally).

[countingtls]

@countingtls any updates here?

BTW, I also found a sort of temporary measures when using the "original" Ghelper without custom sensor_timer, that is indeed to reset WMI, but not by just using command line and doing it once. But using services UI to manually restart WMI at least twice, in rapid sucession. The first restart might produce a fail warning window occasionally (I think depends on how "clogged" WMI current is), but just ingored it and click restart several times anyway. It will eventually restart sucessfully. This manual "restarting" can reset the continuos accumulations of WMI loggings for me in my high load at least for hours (maybe even half a day if activities are low), but they will eventually pop backup (another clue that this was indeed triggering by some process trying to unclogged WMI, but failed and would restart after some preset intervals to try again like other services, but I didn't see any unresponsive or warnings about services restart in logs, so it might not be an "active" service users can change, at least I haven't found it yet. (there might be some clue though. Sometimes, there was a ghost PID that I see briefly in process manager and leaving NULL respond error code and already terminated PID in logging, but it was too quick to check these PID to see which service it might belong to)

[seerge]

@countingtls oke, great.

So is current change sufficient for you (then i will include it in next release) or do you need anything else? :)

[countingtls]

@countingtls oke, great.

So is current change sufficient for you (then i will include it in next release) or do you need anything else? :)

For this particular matter, it is an added feature that solve my current problem, and likely a good feature for others if they also experiencing WMI "busy" for other reasons and can be sure it is not Ghelper that clogged WMI if they can set the sensor_timer to a ver long delay (effectively pause).

However, I still need to dig into why WMI was periodically busy in my machine, which not only would get busy when Ghelper queried but also other processes (which only run on demand, so they would only get logged on chances if WMI is within that mysterious unresponsive period). And this certainly helps make the symptom I had become trivial (instead of thousands or tens of thousands of errors in event logs, I only had hundreds or just a handful if I don't put it at high load).

Thanks so much for your quick assistance and help, and always glad to see everyone is working on making this a viable alternative and as lightweight as possible if they want to.

[countingtls]

This issue related to WMI busy errors is currently alleviated and tested by the added feature of sensor_timer in the setting at config.json.