Sora

Hi Fiery, ah okay, now that you mention this, I recall this posting on the RSoD disscussion from earlier last year: http://forums.aida64...creen-of-death/ You said the same thing there and I'm glad I found this posting again for more details. The problem is solved! I didn't have this setting enabled. After your suggestion here and in the previous posting linked above, I enabled the "nVIDIA GPU SMBus access through nVIDIA Forceware" setting in AIDA64 and it fixed it for me. No more RSoD's upon bootup. Having a GTX 580 before I could get away with not enabling that setting somehow. Now that I have the GTX 680 Kepler, the setting will stay enabled to prevent these issues. Thanks again Fiery! BTW, I have the 306.23 Nvidia display driver currently installed. It's been stable for me thus far. I'm a little cautious to upgrade the display drivers until I see enough positive results from others as for them being stable enough on the EVGA Forums.

Hi Fiery, it looks like there is a problem for me with the AIDA64 Gadget. I first encountered this problem a week ago. After booting up, AIDA64 would try to load up but the screen would turn all red, so I'd have to hit the reset button to reboot. After the reboot, I would get this Desktop Gadget Error Message, with the Sidebar support for AIDA64 not showing on screen anymore. Since then I wasn't experiencing this problem and thought it self corrected itself, until today, after installing Windows 7 Security Updates, but now the problem is happening on every reboot. If I even try to open a new instance of AIDA64 from the icon on the Desktop, the red screen occurs again. I've been using the Vista Sidebar support for this to let you know. Thanks. As a side note in case the card needs to be added to the lineup on AIDA64, I wanted to let you know that 2 weeks ago I purchased a new video card and have it installed. It's the Gigabyte GV-N680OC-2GB GeForce GTX 680 2GB. I'm sure the video card is free of hardware defects since I can game and browse just fine without error.

You're welcome, and I hope it's fixed for Roblion as well.

It works just fine now Fiery! With 'shared memory' enabled with all ext. apps checked, GDI Object count is stable at 433 for me, and no more sluggishness when opening Event Viewer and other programs You guys are always hard at work on AIDA64, intending to keep it stable for everyone! Thanks again.

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!

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.

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.

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

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

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.

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?

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.

Good to know it worked for you too roblion! I know, I was about to comment but didn't, that you personally need to have 'shared memory' enabled in AIDA64, using it in conjunction to allow your fan controller and LCD screen to work in tandem with the shared memory. It's good to know it will be fixed soon so that we can have 'shared memory' enabled again without issues, unless you use another method for that as you've mentioned, while using AIDA for benchmarking etc. Thanks again roblion and good luck to you too! Thanks Fiery for working on this.

Roblion, I posted a solution so far for me here. You can try it too. http://forums.aida64...ng/page__st__40

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?