Hardware monitor and sysinfo errors

[ffrasisti [ARG]]

Hi, I'm running Time Spy as I always do, and now after each run, almost always I get either a message saying Hardware Monitor was Off (it wasnt) and I cant see some data like temps which irks me or it says "Somw system data could not be parsed" and then says it doesnt know my GPU or CPU. Even after a rare correct run with no issues, clicking Run Again can cause the next one to have these issues. I never had any of this happen before the new loading screen and benchmark were introduced in an update

[Cake]

I also believe it was something introduced in this update. All system data was showing up just fine before Steel Nomad released. Not to mention not a single thing changed on my system. Hopefully a fix comes out soon.

[ffrasisti [ARG]]

Have the devs said something?

[Migz - DH]

Seems fine to me.
http://www.3dmark.com/sn/86114
https://www.3dmark.com/spy/48242858

[ffrasisti [ARG]]

I tried several times and only a couple actually had all function. Either the monitor goes off or it does and then it doesnt even recognize my hardware.

[BlurP_NurG]

toune en rond sur collecting info

le logiciel ne se lance pas il tourne sur la page collect...

[Brian48]

Same issue here. Monitor comes and goes. Also a separate issue running Fire Strike Extreme (I made a separate post).

[ffrasisti [ARG]]

Still happening for me

[UL_Jarnis]

There are actually several different underlying issues.

1. Hardware monitoring may go missing. In these cases, actual hardware scan always works, but the result after the run shows no hardware monitoring information (other than the FPS graph). This is caused by the SystemInfo monitoring component crashing mid-run. This can occur for several reasons. For overclocked systems, this can happen simply because the overclock is not stable. If default clocks allow the hardware monitoring to always work, but it sometimes goes missing while overclocked, this is the cause. Reduce overclock. For stock systems, the most common cause is that there are more than one program running that does hardware monitoring, and not all of them are working nicely with each other. SystemInfo goes out of its way to be "nice" and only poll the data once per second and do so only if there are no flags up that say "some other application is reserving this low level bit for itself". Problem is that other applications may or may not care - they may reserve the low level bits for themselves at almost all the time (iCUE used to do this, but they fixed it for latest version) or they may completely ignore any kind of reservation system which may then cause either SystemInfo or the other application have a crash because some of the very low level motherboard and CPU components accessed by the kernel level driver are such that you cannot have two things poking at them simultaneously. For this issue our ability to do anything immediate is limited, but we are looking into solutions.

2. SystemInfo scan itself may fail on the CPUID portion. We are painfully aware that especially on AMD-based systems the scan may randomly just not get the data. In these cases, the CPUID component takes > 60 seconds to get the data which is longer than the current timeout for it (normal system gets this data in under 15 seconds). One change was made in SystemInfo 5.72 that cured a repeatable version of this specific to AMD systems, but it is clearly not the only thing that causes this. The remaining issues are not easy to reproduce and in our test lab we have perhaps 1-3% of runs failing to get data on the affected systems, making this hard to debug. Normally a simple restart of the 3DMark UI and rerun allows data to be gathered. We're very interested in situations where this is somehow repeatable-on-demand. Contact us if you have such a system, we'd like to investigate.

3. SystemInfo scan itself can very very rarely fail on the GPUZ portion. Effectively, querying GPU info just outright crashes. We have not yet seen this in our test lab and do not know the root cause for this. Effect is that on the result screen, you get CPU information but no GPU information at all. Again, if you have a repeatable-on-demand version of this issue (GPU data always missing), please contact us, We'd like to investigate.

4. SystemInfo scan can hang/timeout due to Storage component. This is also rare, but 100% reproducible if the system has a faulty hard disk attached. If you are getting hangs, easy thing to check is to see if windows event viewer has any disk errors in it. If it does, please cure them and try again. Problem with this is that the hang happens in a Windows component we have to call for storage device information. In some very rare cases this can also be due to an attached external storage device. We've seen one case where USB headphones comes with a storage device built-in that contains the software for it. Except that storage device does something very nonstandard and hangs the storage information query. Our options here are limited as the hang happens during a quite normal OS system call.

5. SystemInfo scan can hang/timeout due to WMI component. This is extremely rare and effectively suggests a broken Windows OS installation (WMI = Windows Management Interface, the 'official' way to query various things from the Windows OS). Right now we have no other solution than to suggest reinstall of the OS, as something is quite wrong with it. Luckily this is super rare.

So there are not just one issue. We can help figure out what the underlying issue for your system is if you contact us.

https://support.benchmarks.ul.com/support/tickets/new

...and then offer potential solutions to work around the issue. We do want to solve these, but due to rarity and in some cases poor reproducibility makes it hard.

[ffrasisti [ARG]]

Could Adobe

UL_Jarnis eredeti hozzászólása:

There are actually several different underlying issues.

1. Hardware monitoring may go missing. In these cases, actual hardware scan always works, but the result after the run shows no hardware monitoring information (other than the FPS graph). This is caused by the SystemInfo monitoring component crashing mid-run. This can occur for several reasons. For overclocked systems, this can happen simply because the overclock is not stable. If default clocks allow the hardware monitoring to always work, but it sometimes goes missing while overclocked, this is the cause. Reduce overclock. For stock systems, the most common cause is that there are more than one program running that does hardware monitoring, and not all of them are working nicely with each other. SystemInfo goes out of its way to be "nice" and only poll the data once per second and do so only if there are no flags up that say "some other application is reserving this low level bit for itself". Problem is that other applications may or may not care - they may reserve the low level bits for themselves at almost all the time (iCUE used to do this, but they fixed it for latest version) or they may completely ignore any kind of reservation system which may then cause either SystemInfo or the other application have a crash because some of the very low level motherboard and CPU components accessed by the kernel level driver are such that you cannot have two things poking at them simultaneously. For this issue our ability to do anything immediate is limited, but we are looking into solutions.

2. SystemInfo scan itself may fail on the CPUID portion. We are painfully aware that especially on AMD-based systems the scan may randomly just not get the data. In these cases, the CPUID component takes > 60 seconds to get the data which is longer than the current timeout for it (normal system gets this data in under 15 seconds). One change was made in SystemInfo 5.72 that cured a repeatable version of this specific to AMD systems, but it is clearly not the only thing that causes this. The remaining issues are not easy to reproduce and in our test lab we have perhaps 1-3% of runs failing to get data on the affected systems, making this hard to debug. Normally a simple restart of the 3DMark UI and rerun allows data to be gathered. We're very interested in situations where this is somehow repeatable-on-demand. Contact us if you have such a system, we'd like to investigate.

3. SystemInfo scan itself can very very rarely fail on the GPUZ portion. Effectively, querying GPU info just outright crashes. We have not yet seen this in our test lab and do not know the root cause for this. Effect is that on the result screen, you get CPU information but no GPU information at all. Again, if you have a repeatable-on-demand version of this issue (GPU data always missing), please contact us, We'd like to investigate.

4. SystemInfo scan can hang/timeout due to Storage component. This is also rare, but 100% reproducible if the system has a faulty hard disk attached. If you are getting hangs, easy thing to check is to see if windows event viewer has any disk errors in it. If it does, please cure them and try again. Problem with this is that the hang happens in a Windows component we have to call for storage device information. In some very rare cases this can also be due to an attached external storage device. We've seen one case where USB headphones comes with a storage device built-in that contains the software for it. Except that storage device does something very nonstandard and hangs the storage information query. Our options here are limited as the hang happens during a quite normal OS system call.

5. SystemInfo scan can hang/timeout due to WMI component. This is extremely rare and effectively suggests a broken Windows OS installation (WMI = Windows Management Interface, the 'official' way to query various things from the Windows OS). Right now we have no other solution than to suggest reinstall of the OS, as something is quite wrong with it. Luckily this is super rare.

So there are not just one issue. We can help figure out what the underlying issue for your system is if you contact us.

https://support.benchmarks.ul.com/support/tickets/new

...and then offer potential solutions to work around the issue. We do want to solve these, but due to rarity and in some cases poor reproducibility makes it hard.

could Adobe Creative cloud be causing the icue issue? Its the onyl new software ive got running

[UL_Jarnis]

No, Adobe Creative Cloud does not cause any issues. We have it installed on many systems in our testlab (due to having to test UL Procyon Photo and Video editing tests) and it does not matter in this context.

What can matter is out of date motherboard BIOS and various system hardware monitoring utilities. In a very crude way: if it can show system component temperatures or clock speeds, it is potentially something to look at.

[ffrasisti [ARG]]

I dont think my bios is outdated. The only other thing in the background for me is logitch g which controls the dps of my mouse? I have a x670e-e gaming mobo, a 7800x3d and a 4080

[UL_Jarnis]

One thing you could try is write down any modifications you made to your BIOS, then reset all BIOS settings to default, then restore AMD EXPO settings and possibly any changes related to boot drives etc. and see if that changes anything. If it does, some BIOS modification may cause issues. If you find which one, do tell us :)

[®€nκλ]

Same thing here 12900k, on Msi z690 Carbon wifi + last bios update, 3080 TI and windows 10x64 22h2 19045.4412.
It's a real pain, because before the update everything was working perfectly.
Now it's running in circles without stopping while the hardware is being detected.

It is impossible to run a single benchmark, which is really frustrating, especially as none of the above methods seem to work.

[UL_Jarnis]

Contact us, I will send documentation how to pull logs on SystemInfo to figure out the possible cause.

https://support.benchmarks.ul.com/support/tickets/new

[®€nκλ]

UL_Jarnis eredeti hozzászólása:

Contact us, I will send documentation how to pull logs on SystemInfo to figure out the possible cause.

https://support.benchmarks.ul.com/support/tickets/new

I finally found the culprit, it was Intel XTU, however it was only reading the bios information without any modification which I find strange.
Since I close it before launching 3D mark it analyzes my system correctly.

Thank you very much for your prompt reply, it's always nice to deal with conscientious developers.