Sensors taking 12+ seconds to load on my PC

[InstantAli3n]

This is happening only on my machine. 12 seconds is a lot considering I'm running a 4790k at 4.7GHz, and an SSD. It used to take one second or possibly less. I tested on a few others PCs and they load right quickly as usual. This started happening some time after 5.20.2800 but not directly after an upgrade. Currently on 5.22.2820.


I reset all settings to default and went through other menus resetting as much as possible just in case something was bugged. I deleted the ini file as well. I don't know if I need to delete a registry entry to fully clear settings or not. I don't know where that's located anyway. 

I attempted to uninstall the HWINFO driver which says it succeeded, but if I open settings again and go to that tab it's still listed as installed. If I hit uninstall again I two errors in a row. One that it cannot be stopped, and another that it cannot be deleted.
It's probably something to do with that.


Windows 8.1 x64
All updates installed minus ALL the spying/telemetry/get Windows 10 updates.
All programs up to date, tested with nothing else is running on startup. 
I keep a super clean system, no really. SUPER clean.
Inactive/removed devices deleted with device remover.
Drivers updated with Snappy Driver Installer. Check it out, it's the only legit, free, non-malware driver updater in the universe AFAIK.
GPU drivers cleaned with Display Driver Uninstaller, latest installed.

Regular load up without sensors takes 4 seconds now. It hangs on Core #0 for a bit and a few other places. Sensor load also hangs on a few other places, then loads sensors over 12+ seconds with most but not all loading slow enough to read them easily. If I click anywhere while it's loading it gains a "not responding" status and visually freezes until all loading is complete.

Debug file proactively attached.  :angel:

 

[Martin]

Try to disable the "GPU I2C Support" option and let me know if that improves the scan time. You'll probably loose some GPU sensors with this option disabled, this is just to prove if this is the problematic item.
Also make sure to run without Debug Mode, as in this mode the startup is must slower.

 

[InstantAli3n]

Try to disable the "GPU I2C Support" option and let me know if that improves the scan time. You'll probably loose some GPU sensors with this option disabled, this is just to prove if this is the problematic item.
Also make sure to run without Debug Mode, as in this mode the startup is must slower.

Perhaps it's a half second faster with GPU I2C Support disabled... maybe. I cleared the cache on it and then tested a few times.

Debug mode does make it slower, I noticed that right away. The effect is relatively minor on my machine though. Mostly it just makes sensor fields flicker when enabled and slow loading slightly.

I do have some Asus EC sensors that throw up a warning saying they'll make things slow, but there is absolutely zero perceivable difference with them enabled vs disabled. I've kept them disabled for all testing though just to be sure.

 

[Martin]

Hm, OK so with that option it's still quite slow, so it must be something else. You can enable it back then.
HWiNFO should be showing which sensor it's currently scanning, are you able to recognize which one takes most of the time ?

 

[InstantAli3n]

For sensors, It hangs first at Core #0 for 2 seconds, then speeds up to the usual imperceptibly fast speed until it hits MX/ECM/LM/ADM, at which it starts going one by one, each taking about 150-166ms until the value after the final PMbus is reached (DRAM TS or something?), then it goes like lightning again through the remainder near instantly, like the entire thing used to be. (Except perhaps Core 0 if I remember correctly?)

Loading the regular summary, it pauses at Core #0 for 2 seconds, Analyzing memory configuration for 750ms seconds, then a little pause "Enumerating ...something I can't read" and a 1.5 second pause at Enumerating Sound Cards. All the rest are "fast" or "REALLY fast". Less than 100ms to barely perceptible (??ms).

I was going to make a gif (jif) instead of explaining it, but I think I explained it alright. I don't really know the :right way: to make a gif anyways so it was quicker to tell you for now rather than figure that out first.

If you think it would be easier to understand if I show a gif of it loading let me know and I'll make one.

 

[VictorVG]

And you all the drivers installed on the board? And ASUS loves to invent "devices" such as "Fixed button the ACPI" on motherboards ASUS P5Q* (based on chipsets G41/P43/P45 series) like P5Q SE (P45), P5QL/EPU (P43) and without having to install their corporate driver like all external works, but for some reason, the system periodically flies to a kernel panic and half of the device is simply not recognized on the bus ...

 

[InstantAli3n]

And you all the drivers installed on the board? And ASUS loves to invent "devices" such as "Fixed button the ACPI" on motherboards ASUS P5Q* (based on chipsets G41/P43/P45 series) like P5Q SE (P45), P5QL/EPU (P43)  and without having to install their corporate driver like all external works, but for some reason, the system periodically flies to a kernel panic and half of the device is simply not recognized on the bus ...

I disabled and deleted a random asus service a while back, long before this issue. 

Otherwise I do have all drivers installed for my board using Snappy Driver Installer (try it)

I just uninstalled some other Asus device driver called AMDA00 interface and ACPI Fixed Feature Button, but they installed themselves upon reboot! 
Now there is an atkexComSvc.exe process stuck using 15% CPU! I deleted that once before. I think that was the service I got rid of a few months ago. If I leave the devices alone I think it will stay gone.

There are some like Intel(R) Z97 Chipset LPC Controller - 8CC4 which is "Programmable Interrupt Controller" so I'm assuming those are essential and directly for the chipset by intel and not 3rd party crap from Asus.

Is it possible ACPI Fixed Feature Button is actually the "ASUS Direct Key" function? I use that a lot for overclocking.

HWINFO sensors are still as slow to load no matter what I did with the things above (tested before and after each change).

 

[Martin]

This looks like a problem with SMBus, which is used to access several devices including DIMM SPD and sensors. Also looking at the DBG file you posted, I cannot see any DIMM SPD devices detected, which proves this might really be the problem. The slow scan is most probably due to this fact - HWiNFO takes more time attempting to use SMBus, but it fails. You might prove this by trying to disable "SMBus support" in HWiNFO and see if that improves the scan time.
But still the question is what is causing this problem. For me it looks like some collision with another tool or driver in the system, which doesn't play fair. You might try to uninstall the SMBus Controller driver.
Regarding those ASUS services, they might be a part of ASUS AI Suite - even if you uninstall it, it still leaves some drivers and services in the system. But I'm not sure if this is causing the problem...

 

[InstantAli3n]

WOW!!! It loaded faster than I've ever seen it! It loaded instantly! Disabling SMBus Support, that did the trick. Even the main summary window loads faster, only pausing briefly at Enumerating Busses something and Enumerating Sound Cards and one more Enumerating thing, all right at the end.
NOTE: I have onboard audio disabled and use an external Objective2+ODAC.

Disabling SMBus Controller Device makes no difference I'm afraid. I wonder what could be causing it as well... Right now I'm using the Broadcom 8/30/2015 1.3.0.530 version which is listed by Snappy Driver Installer as the most optimal, although not the latest.
I'm going to try a few different versions of the SMBus driver and see what difference it makes if any. I tried with it uninstalled but that makes no difference either. (Yes, I close HWINFO each time).

As for Asus, I don't use ANY Asus software, their software is a disaster. Whatever Asus service is on here auto installs as part of the AMDA00 system device driver, but I can partially uninstall it/cripple it to not run and forget about. (Fooled around with it yesterday, not the cause).

 

[Martin]

Thanks, so we know what is the problem, but don't know why yet..
I have walked through your list of devices and can't see anything suspicious except several ASUS drivers/devices like "AMDA00 Interface" and some others.
Another problematic component could be other hardware monitoring software. Please make sure you're not running anything else.

 

[VictorVG]

As for AMDA00 functions do not know, and ACPI Fixed Feature Button is power management and thermal protection.

Overclocking? - this is good , can once burned with a good fireworks and teach you what documentation do not write schoolboys on the forums, and my colleagues engineers that these schemes are set up and are well aware of their limiting features and modes that you like all overclockers exceed on the basis of "I'm smart, but a fool developer - dispersal and win a couple of parrots!". 

 

[InstantAli3n]

Thanks, so we know what is the problem, but don't know why yet..
I have walked through your list of devices and can't see anything suspicious except several ASUS drivers/devices like "AMDA00 Interface" and some others.
Another problematic component could be other hardware monitoring software. Please make sure you're not running anything else.

Sorry! I was busy, I'm back now.

I have no other monitoring software running. I closed MSI Afterburner and there is nothing else that monitors. I will try disabling some hardware monitoring in the bios as that is possible to do...

hopefully I get back to you soon!

 

[InstantAli3n]

FIXED IT!

It was the AMDA00 driver. THis is for monitoring thermal probes and sensors in case you use them, but it's known to be not only broken but "impossible" to remove. Asus doesn't give a shit and hasn't updated it since 2014, however INTEL DOES care and there was a driver available for this SMBus device...

Disabling sensors in the bios didn't prevent HWINFO from getting values, they were just ignored in the bios...
I was able to uninstall the AMD00 device by checking remove device installation software or whatever with it and when it tried to redetect and reinstall it failed with a yellow bang/warning sign. I'm honestly not 100% clear on what it is but it has something to do with SMBus, that I know.

Using Snappy Driver Installer, I was only able to see the regular driver for it, however, when I checked "invalid drivers" I whole bunch more became available to view, some newer versions but simply not signed. Others were different "brands" so to speak. Like Intel or Broadcom or even Lenovo (???) drivers for the same device.

SMBus had 3 choices, and although Intel was the LEAST recommended, the other one (besides stock) looked strange to me, the numbers didn't match up or something. I don't remember and I already deleted the driverpack (sorry...)

Anyway, I installed the intel driver for the SMBus and it succeeded! After a reboot I tried HWINFO32 with SMBus support enabled and disabled and it was just as fast either way!!! Success!

However, there remains an unknown device i my device manager - likely the AMD00 thing. This is strange as it appears the intel drivers for it are installed.

Oh well I'm not touching it! ASUS software and drivers have always been, and will always be GARBAGE. Avoid them like the plague!

I don't think there is anything HWINFO can do to help work around this problem... perhaps detect that there is an issue loading with SMBus and disable support for it automatically? That's all I can come up with!

Perhaps this is the Fault of Snappy driver installer choosing the wrong driver. I'll go find their home and talk to them about it and see what they have to say. This may have started about the time I started using that program so I could very well have installed that horrible driver with my first use of snappy driver installer! Ahh well mistakes are inevitable. I don't hold it against them.

Thanks for that hint Martin!

 

[Martin]

I'm glad that you found the problem
I wouldn't worry about that "unknown" device - I'm sure that as long as you don't use ASUS tools it's not needed for anything. Also it's an ASUS-specific device so you won't be able to install drivers for it from any other manufacturer than ASUS.
From what I saw on some forums it looks like this driver/device makes communication with the BIOS possible (probably for ASUS tools), so perhaps a BIOS update might fix the problem as well, though I'm not sure if it really would. If you don't want to have an unknown device you might install drivers for it and then disable it via Device Manager...