61 replies to this topic

[Sora]

I have the Shared memory items all checked and enabled too, but don't have any other program running consistenly that would utilize the memory. EVGA Precision is the only program I have running with AIDA64, but have always run that side by side with AIDA64 without problems. To check if it was a conflict with Precision, I recently ran AIDA64 without EVGA Precision running, with the same issues. I haven't tried unchecking all the 'shared memory' items in AIDA64, and thought of that optiion to try.

Yes, I use the Desktop Gadget, and even tried unchecking the 'Use HKLM in Registry' box, that didn't fix the issues.

[Squall Leonhart]

use HKLM just affects where the settings are written to, if the shared memory or gadget stuff was at fault it wouldn't affect it.

try running without shared memory and without the desktop gadget.

actually, i have a feeling its specifically Shared Memory causing the problem due to a mismanaged constants buffer

[Sora]

Okay will try running AIDA64 with 'Shared memory' unchecked while gaming and see how that works tonight and check on the sluggishness later on as well as the icon appearing near the Start button as a result of clicking on the icon in Notification area, and the AIDA64 not opening as roblion and I have experienced. Thanks Squall.

[Sora]

I just gone done gaming and after ALT+Tabbing out of game several times while playing, I opened Event Viewer and clicked on the logs, with no sluggishness! Also, am able to click on the AIDA64 icon in Notification Area many times without a problem of not opening. It appears that disabling 'Shared Memory' fixed this issue for me. I'm not 100% convinced yet, but 98% sure this problem is solved. I'll be more sure after gaming tomorrow night.

Roblion, try disabling the 'Shared memory' in AIDA64, see if that fixes it for you.

Since Roblion and I didn't have this issue up till about 2 weeks ago, do you guys think it's a bug in AIDA with having 'Shared memory' enabled and it being a mismanaged constant buffer as you've suggested Squall?

[roblion]

Yep same for me Sora, disabled external data shared memory and no lock up this morning!

And you were right about Event Viewer too.... was sluggish redrawing screen etc when AiDA64 had hung, but all ok now....

I can live without shared memory, i used to so that my fan controller and LCD screen could read and use it, but i'll do it another way now.....

Good luck Sora.....

[Fiery]

I just gone done gaming and after ALT+Tabbing out of game several times while playing, I opened Event Viewer and clicked on the logs, with no sluggishness! Also, am able to click on the AIDA64 icon in Notification Area many times without a problem of not opening. It appears that disabling 'Shared Memory' fixed this issue for me. I'm not 100% convinced yet, but 98% sure this problem is solved. I'll be more sure after gaming tomorrow night.

Roblion, try disabling the 'Shared memory' in AIDA64, see if that fixes it for you.

Since Roblion and I didn't have this issue up till about 2 weeks ago, do you guys think it's a bug in AIDA with having 'Shared memory' enabled and it being a mismanaged constant buffer as you've suggested Squall?

That's a great catch! We're already doing test runs with Shared Memory enabled to see if we could reproduce the issue on our test systems. Meanwhile, can you please check what happens if you enable Shared Memory, but only have the CPU temperature enabled from the list of Ext.Applications items -- and no other items enabled.

Second test run: have every items enabled there, disable Shared Memory, but enable Registry exporting.

Those test runs may confirm whether one of the items cause a memory or handle leak, or whether the Shared Memory feature is generally at fault.

[Sora]

Yep same for me Sora, disabled external data shared memory and no lock up this morning!

And you were right about Event Viewer too.... was sluggish redrawing screen etc when AiDA64 had hung, but all ok now....

I can live without shared memory, i used to so that my fan controller and LCD screen could read and use it, but i'll do it another way now.....

Good luck Sora.....

Roblion, I'm glad you noticed the sluggishishness of screen redrawing as well and that I wasn't the only one.

Good luck to you too.

[Sora]

That's a great catch! We're already doing test runs with Shared Memory enabled to see if we could reproduce the issue on our test systems. Meanwhile, can you please check what happens if you enable Shared Memory, but only have the CPU temperature enabled from the list of Ext.Applications items -- and no other items enabled.

Second test run: have every items enabled there, disable Shared Memory, but enable Registry exporting.

Those test runs may confirm whether one of the items cause a memory or handle leak, or whether the Shared Memory feature is generally at fault.

I'm glad to have caught it too, thanks to Squall Leonhart!

Okay, will do Fiery. Tonight while gaming I'll utitize the first suggestion you gave, selecting only the CPU Temperature, and tomorrow or later tonight will try the second suggestion.

Question on 'registry exporting'. Is that the listing called 'Enable writing sensor values to the Registry' in the 'External Applications' section?

[Squall Leonhart]

That's a great catch! We're already doing test runs with Shared Memory enabled to see if we could reproduce the issue on our test systems. Meanwhile, can you please check what happens if you enable Shared Memory, but only have the CPU temperature enabled from the list of Ext.Applications items -- and no other items enabled.

Second test run: have every items enabled there, disable Shared Memory, but enable Registry exporting.

Those test runs may confirm whether one of the items cause a memory or handle leak, or whether the Shared Memory feature is generally at fault.

I believe its a handle leak, memory use doesn't suddenly balloon and GDI count isn't excessive either.

[Fiery]

Question on 'registry exporting'. Is that the listing called 'Enable writing sensor values to the Registry' in the 'External Applications' section?

Yes, that's it.

[Fiery]

I believe its a handle leak, memory use doesn't suddenly balloon and GDI count isn't excessive either.

Yes, that's our suspicion too. We already have a theory about where the Shared Memory feature piles up the handles, but it's not easy to reproduce and verify it. We'll work on it in the upcoming days, collect feedbacks from other beta testers as well, and hopefully we can fix it up soon.

[Sora]

I tried both of the suggestions you mentioned Fiery, and no sluggishness with just the CPU Temperature checked that I noticed, and a little bit of sluggishness noticed when opening Event Viewer logs with the Registry exporting checked.

Sounds good on the possible fixing of this issue soon! In the meantime, I'll leave 'shared memory' unchecked.

Thanks again Fiery, Squall and roblion.

[Fiery]

I tried both of the suggestions you mentioned Fiery, and no sluggishness with just the CPU Temperature checked that I noticed, and a little bit of sluggishness noticed when opening Event Viewer logs with the Registry exporting checked.

It means maybe not the Shared Memory feature itself, but one of the items would cause the handle or memory leak. Can you please check what happens if you enable the Shared Memory feature, disable Registry exporting, and enable all items in the Ext.Apps items list? Then check how many handles does Task Manager show on its Performance tab, and how much memory, threads and handles does AIDA64 use for its main process on the Processes tab (there you may have to enable the Handles and Threads columns from main menu / View / Select Columns). Then play some games, and when AIDA64 or Event Viewer becomes sluggish, check the handles and threads values in Task Manager to see which one is piling up.

I'm sorry to request so many test runs, but apparently on our test systems even enabling all Ext.App items, no issues can be found with the AIDA64 Shared Memory + LcdStudio combo And what we've previously thought may be the root cause of the issues is actually done properly, so there must be something else. We suspect it may be something about video driver calls when detecting GPU clocks -- or something like that. It's quite tough to diagnose such bugs

[Sora]

Okay Fiery, will give this a go tonight while gaming, which will be in a few hours.

[Sora]

Here are the results after gaming for 5 hours. The sluggishness starting showing up after gaming awhile, with these results. No problem at all on doing these test runs, glad to help any way I can. As Squall Leonhart mentioned before, if the commit size shows a higher number than Working Set memory, that would signify some of the memory is being paged out, and this is what shows here with AIDA64 having a higher commit size than working set. I'm sure that's normal though to a degree. I won't enable 'shared memory' since I don't use it with other programs at this time, but I may in the future. I thought having it enabled would ensure that I would need it for other programs, but at this time I don't see any programs that I have that would utilize the shared memory. Roblion may need to use it with his LcdStudio more than I would at this point, unless he uses another method as he said he might. So for now until it can be fixed, I'll just have 'shared memory' unchecked.

Hmm, I wrote this with the two listings side by side with a space between them, but it didn't show up that way after posting it. I hope you can read it well with how I organized it. The bottom two listings of 'Handles' and 'Threads' and the 'Working Set' and 'Commit Size' are from the Processes Tab of the Task Manager.

Like you said, it does appear to be tough to diagnose these bugs!
Thanks again Fiery.

Before gaming: Performance tab of Task Manager Before gaming: Memory for AIDA64
Handles: 11906 Working Set: 10,352K
Threads: 588 Commit Size: 37,436K
Handles: 179
Threads: 5


After gaming: Perfomance tab of Task Manager After gaming: Memory for AIDA64
Handles: 13923 Working Set: 12,368K
Threads: 773 Commit Size: 43,940K
Handles: 282
Threads: 6

[Squall Leonhart]

Yes, its normal AIDA64 has a small enough footprint that being paged out wouldn't really affect performance.

that handle count isn't showing what i expected it would though.

how many GDI objects are there after gaming?

[Sora]

Good to know all is normal there on the handles and threads count.

I didn't have GDI checked in Task Manager but just added that column, and am about to game and will post the before and after gaming GDI count soon. I'll go ahead and re-enable the 'shared memory' and all the external applications items for this test.

[Sora]

Wow, okay GDI objects count before gaming was 867 and rising. After about 6 hours of game play, the GDI object count has slowly risen to 6905 and rising still. This is with 'Shared memory' enabled and all the items check under ext. apps. I'll uncheck 'shared memory' for now.

With 'shared memory' and all of the ext apps items unchecked, AIDA64 under Task Manager shows a consistent 464 GDI Object count. So it could be what you mentioned Fiery and Squall as video driver calls when detecting GPU clocks, I don't know.

[Fiery]

We've fixed the device context leakage issue. Please upgrade to the latest beta version of AIDA64 Extreme Edition available at:

http://www.aida64.co...29bcq0xs8flwzip

After upgrading to this new version, make sure to restart Windows to finalize the upgrade.

Let me know how it works.

[Squall Leonhart]

that was a massive amount of GDI objects, xD, its no wonder it wouldn't open and caused the event viewer to be so sluggish

hope its fixed in this new beta