Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SharedMemory ID's changing on every restart
#1
Hi,

I  am monitoring 3 PC's from the HWiNFO networking plugin into RainMeter. The problem is that on one of my PC's, the SharedMemory Sensor ID changes on Ethernet Card, GPU, and SSD on every single restart (when I restart both my main PC and the server PC). It's only when I restart my main PC and this particular PC. The other PC never changes. Why does this happen and how can I prevent it from happening? I'm having to edit the HWiNFO.ini file every single time...
Reply
#2
Please post a few example of the various IDs.
Reply
#3
(06-25-2018, 07:02 AM)Martin Wrote: Please post a few example of the various IDs.

This system is a bit older,

Intel DX79TO x79 motherboard
i7-3930k
Nvidia GT710 (purely for having a GPU, this system is 100% remote controlled only -- lowest power consumption I could find)
Intel 82579M LM LAN port

Actually it just happened without even restarting. Sometimes HWiNFO "loses" the ability to track the LAN/GPU on this PC, and when I check (after restarting HWiNFO) the Sensor "Instance" has changed. It happens surprising a lot, like multiple times a day.

Sensor Instances that was listed when I started the PCs up today:


; Remote Host 1 : Network 0
HWiNFO-RemoteHost1-Network0-SensorId=0xf000ea00
HWiNFO-RemoteHost1-Network0-SensorInstance=0xc
HWiNFO-RemoteHost1-Network0-CurrentDownload=0x8000002

; Remote Host 1 : GPU 0
HWiNFO-RemoteHost1-GPU0-SensorId=0xe0002000
HWiNFO-RemoteHost1-GPU0-SensorInstance=0xb
HWiNFO-RemoteHost1-GPU0-Temp=0x1000000

- - - - - - - - - - - - -

Sensor Instances a few hours later, when HWiNFO networking "lost the connection" (meters go to 0C in RainMeter and I know the ID has been changed). These I have updated and then it works again:

; Remote Host 1 : Network 0
HWiNFO-RemoteHost1-Network0-SensorId=0xf000ea00
HWiNFO-RemoteHost1-Network0-SensorInstance=0xa
HWiNFO-RemoteHost1-Network0-CurrentDownload=0x8000002

; Remote Host 1 : GPU 0
HWiNFO-RemoteHost1-GPU0-SensorId=0xe0002000
HWiNFO-RemoteHost1-GPU0-SensorInstance=0x9
HWiNFO-RemoteHost1-GPU0-Temp=0x1000000

- - - - - - - - - - - - -

The Instances seem to alternate between 0x9, 0xa, 0xc, 0xb, 0x7, 0x6. Wow, checking now, tons of the ID's have changed, more than normal. SSD, Motherboard, GPU, SSD, Network, all changed automatically without even restarting the computer.

Note that I have another PC attached to this setup, and the Instances remain completely static. It's only this PC that changes all the time.
Reply
#4
This is quite strange and I believe this is related to some hardware enumeration issue. The system must be also enumerating those devices with different instances, check in Device Manager how they appear and under Details the Device instance path, Address, Bus number and Location paths whether that changes too.
Which version of Windows do you have?
You might also attach the HWiNFO Debug File from both situations.
Reply
#5
(06-25-2018, 11:36 AM)Martin Wrote: This is quite strange and I believe this is related to some hardware enumeration issue. The system must be also enumerating those devices with different instances, check in Device Manager how they appear and under Details the Device instance path, Address, Bus number and Location paths whether that changes too.
Which version of Windows do you have?
You might also attach the HWiNFO Debug File from both situations.

Do you think it could be anything to do with a failing motherboard? Would that affect the way it assigns these variables / ID's?

Okay I have enabled debug mode, let's see when it changes again if anything is provided.
Reply
#6
Alright here is the debug file from re-opening then closing HWiNFO


Attached Files
.dbg   HWiNFO64.DBG (Size: 944.09 KB / Downloads: 1)
Reply
#7
Sorry, but you need to attach 2 Debug Files because each time you start it, the Debug File will be overwritten with new one.
Reply
#8
(06-26-2018, 07:02 AM)Martin Wrote: Sorry, but you need to attach 2 Debug Files because each time you start it, the Debug File will be overwritten with new one.

So after a long night of no sleep, thinking the motherboard finally died, troubleshooting for hours -- and almost ordering a new build because Windows 7 randomly started freezing on every load... I discover that it's HWiNFO debug mode that killed my PC.

No sure what's going on with that, but I just wasted 10 hours troubleshooting USB drivers, system restore from weeks ago, only to find out that it was HWiNFO the whole time. I finally figured it out by backing up everything, doing an old System Restore, seeing that it didn't freeze anymore... then opening HWiNFO from a version I saved, and it instantly froze. I opened the config, changed DebugMode to 0 and now it's back to normal...
Reply
#9
Sorry, but it's impossible that HWiNFO would kill a machine.
If you had it auto starting in Debug Mode and this mode would cause some problems, then it should be easy to fix by disabling either auto start or debug mode. But an irreversible hardware damage is not possible.
Reply
#10
(06-26-2018, 01:39 PM)Martin Wrote: Sorry, but it's impossible that HWiNFO would kill a machine.
If you had it auto starting in Debug Mode and this mode would cause some problems, then it should be easy to fix by disabling either auto start or debug mode. But an irreversible hardware damage is not possible.

That's not what I said.. or meant.. I'm saying I didn't think that HWiNFO would've had anything to do with why the PC started freezing, I have another build I had to install Win10 on, and was upgrading the version of TeamViewer on this PC to 13... when suddenly the PC started freezing on every boot. I just never thought in a million years HWiNFO would be the cause, but it was. Not saying it cause hardware damage... of course not.
Reply
#11
Oh sorry, I misunderstood that "killed my PC". Debug Mode reads and writes a lot mode data, which is useful for troubleshooting only. It's definitely not recommended to enable it for normal usage.
Reply
#12
(06-26-2018, 02:14 PM)Martin Wrote: Oh sorry, I misunderstood that "killed my PC". Debug Mode reads and writes a lot mode data, which is useful for troubleshooting only. It's definitely not recommended to enable it for normal usage.

Well the constant SensorInstance changing continues even with the latest HWiNFO beta. It's happening so much now I had just changed it, when I noticed the SSD and GPU reporting the same temp. I check my main PC (the one that does the monitoring of the 2 other PCs) HWiNFO to see that the GPU temp has been "shifted" into the S.M.A.R.T header! I had to restart HWiNFO on the other PC and my main PC to fix it. The Instances cycle every X minutes, what could possibly cause this?

The only thing I could possibly think of is that instead of installing Intel MEI on this PC, I just disabled it in device manager... I also have Nvidia's HDAudio disabled. Could this be causing it?

Also, none of the other ID's change, I've gotten it down to only 3:

GPU
SSD (SMART)
Network/LAN

RAM/CPU Load/CPU Temp all remain static.

Note that I am monitoring 2 PCs with the networking script -- and only the Sandy Bridge one is having this issue. The H370 never changes ID's (nor does my main PC - Z370).
Reply
#13
First try to do a full Reset Preferences in HWiNFO and then start it again to see if that changes something.
If not, check in Device Manager as described above if this is a general system problem.
Reply
#14
(06-26-2018, 03:42 PM)Martin Wrote: First try to do a full Reset Preferences in HWiNFO and then start it again to see if that changes something.
If not, check in Device Manager as described above if this is a general system problem.

I haven't changed any options besides the Polling Period, made is 1000ms instead of 2000.

But I did reset ALL layout changes, all hidden/non-monitoring items, and reset all other settings.

I installed the proper MEI driver and now have no yellow marks in device manager.

The issue just happened when I restarted the program on remote machine, then on local machine... but I tested restarting the program again and they didn't change, so it doesn't seem to happen on every reset.

Recording hardware information here for next change:

GPU
NVIDIA GeForce GT 710
HWID - PCI\VEN_10DE&DEV_128B&SUBSYS_8C931462&REV_A1
Address - 00000000
Bus Number - 00000004
Location - PCI bus 4, device 0, function 0


LAN
Intel® 82579LM Gigabit Network Connection
PCI\VEN_8086&DEV_1502&SUBSYS_49538086&REV_05
Address - 00190000
Bus Number - 00000000
Location - PCI bus 0, device 25, function 0


Storage Controller
Intel® C600/X79 series chipset 6-Port SATA AHCI Controller - 1D02
PCI\VEN_8086&DEV_1D02&SUBSYS_49538086&REV_05
Address - 001F0002
Bus Number - 00000000
Location - PCI bus 0, device 31, function 2


SSD
Sandisk SDSSDA120G
IDE\DiskSanDisk_SDSSDA120G______________________Z22000RL
Address - 00000000
Bus Number - N/A (IDE)
Location - Channel 1, Target 0, Lun 0
Reply
#15
Hey on that note, besides this issue I'm really curious, does monitoring / showing less sensors reduce the CPU usage of HWiNFO? Or is it only be such a small amount that it's not worth it? I've seen you talk about SMART data before, I only need the temp, no other data. Would it be worth hiding the things I don't need, or just leave everything showing?
Reply
#16
Yes, in some cases reducing the amount of sensors monitored can improve the latency. Enabling the Profiling Time column will allow you to see how much time is spent for readout of each sensor, so you can exactly see if there are any bottlenecks.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)