Jump to content
AIDA64 Discussion Forum
Sora

fixed: AIDA64 won't open after gaming

Recommended Posts

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.

  • Like 1

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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 :(

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Yes it was Squall, and it is fixed now and working just fine with this new beta! With 'shared memory' enabled and all of the ext. apps checked, GDI count is at 433 and stable, and no more sluggishness when opening Event Viewer and other programs. Thanks so much Fiery and Squall! :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×