Speccy eats more and more RAM, unable to be killed/suspended

[Scales]

This is the first time that Speccy has ever done something out of the ordinary for me. Whenever I start it up currently, it locks down everything and I am unable to move the mouse for about 10 seconds. After this, it starts allowing me to do things. The first thing I did was open Task Manager, which explained the freeze: Speccy was using an excessive amount of RAM. I tried to kill the process/process tree in Task Manager, no dice. I opened up Process Explorer ( http://en.wikipedia....rocess_Explorer ) and tried to Kill Process / Kill Process Tree / Suspend, still nothing. Speccy kept eating up more and more RAM until capping out at about 4 gigs. At this point, it finally crashed / was killed by task manager / went away SOMEHOW, to my relief.

 

Thinking it was just a fluke, I started it up again, same thing. Freeze, followed by slowness, ate all the RAM, then crash.

 

I used the program fine just a few hours ago, and no drastic changes have been made since, not even a reboot.

 

I have uploaded a screenshot I took just before it crashed, as well as a DxDiag with my system info.

 

I love the program, keep up the good work/etc.

 

Thanks,

Scales

 

EDIT: The forum shrunk down the image (1920x1080), making the text unreadable. Uploaded a cropped version.

DxDiag.txt

[Alan_B]

Operating System ?

[nodles]

Operating System ?

It's in the DxDiag.txt attachment.

Operating System: Windows 7 Professional 64-bit (6.1, Build 7601) Service Pack 1

[Scales]

Through some trial and error going through the programs that were running at that time, I was able to find out the culprit: Fraps.

If you didn't know, Fraps is a program that is used to record video game or other footage (http://en.wikipedia.org/wiki/Fraps).

 

If Fraps is running BEFORE Speccy is started, Speccy will freak out with memory and do bad things.

If Fraps is started AFTER Speccy, they will run as usual without problems.

 

I'm able to reproduce this 100% of the time.

 

Version Details:

Speccy - v1.16.317 (64-bit)

Fraps - Version 3.2.3, Build 11796

 

Attached are Speccy debug logs, one from a time when it goes haywire, and another from a normal run with no problems. There don't seem to be any discrepancies.

 

If there's anything else you would like me to provide to help you guys fix this problem, let me know.

HAYWIRE_Speccy_log1_16_31719-6-2012_4-33.txt

NORMAL_Speccy_log1_16_31719-6-2012_4-54.txt

[Alan_B]

http://www.fraps.com/faq.php

There is a small overhead associated with drawing the framerate on screen.

...

The best way to measure it on your own system is to find a game that allows you to benchmark it and compare the results obtained with and without Fraps loaded.

When you are benchmarking the overlay is automatically disabled to provide the most accurate results.

If you are recording a movie with Fraps there can be a noticeable impact on the game. This is due to all the extra work involved in saving the screen data to disk.

That suggests to me that FRAPS may have mistaken Speccy as a game,

and is unfortunately having a stupendously noticeable impact on this "game".

 

The situation may be aggravated by the existence of both 32 bit and 64 bit frap processes..

Speccy has the decency to only use a single instance of its version that is most appropriate for the O.S.

 

After a 6 month absence of updates FRAP is now averaging 5 bug-fix updates per month.

The last one was issued 12th June so they may fix their product tomorrow,

otherwise perhaps you could notify them of their incompatibility with Speccy.

[Scales]

There is a small overhead associated with drawing the framerate on screen.

 

That suggests to me that FRAPS may have mistaken Speccy as a game,

and is unfortunately having a stupendously noticeable impact on this "game".

 

If that is true, then shouldn't the memory issues be visible for Fraps, not Speccy?

Also, Fraps shouldn't have a direct impact on a game's (or any program's) memory, the overhead is due to Fraps itself running and recording.

 

I've downloaded and tested the 3.5.5 (most recent) update to Fraps, and the same problem exists.

 

I still believe that the fault is with Speccy, not Fraps.

 

Since Fraps and Speccy can coexist and work correctly when Speccy is run after Fraps, this would logically suggest that the problem is somewhere in the startup sequence for Speccy.

[Super Fast]

@Alan -> You can tell it is Windows 7 via the aero glass on the task manager screenshot. But nice that he decided to tell us!

[Alan_B]

If Fraps is running BEFORE Speccy is started, Speccy will freak out with memory and do bad things.

Since Fraps and Speccy can coexist and work correctly when Speccy is run after Fraps,

Those statements appear inconsistent.

 

Perhaps Fraps has usurped authority within Windows and is preventing Speccy from accessing Windows Management Instrumentation or some other Windows facility.

 

The logical Speccy fix for this bug is to detect such an obstacle and to terminate itself.

Alternatives under your control are to contact the Fraps people, or to refrain from launching or allowing the launch of Fraps when you wish to use Speccy.

[Alan_B]

@Alan -> You can tell it is Windows 7 via the aero glass on the task manager screenshot. But nice that he decided to tell us!

Actually it was Nodles who told us after he put in the effort to download and read a 33 kByte text file.

[Scales]

Those statements appear inconsistent.

 

Perhaps Fraps has usurped authority within Windows and is preventing Speccy from accessing Windows Management Instrumentation or some other Windows facility.

 

The logical Speccy fix for this bug is to detect such an obstacle and to terminate itself.

Alternatives under your control are to contact the Fraps people, or to refrain from launching or allowing the launch of Fraps when you wish to use Speccy.

 

They are "inconsistent" because they are different occurrences, you would know this if you read both lines. I even put the important words in bold.

 

If Fraps is running BEFORE Speccy is started, Speccy will freak out with memory and do bad things.

If Fraps is started AFTER Speccy, they will run as usual without problems.

 

Or I could put it like this:

 

Situation 1:

Fraps is already running.

Speccy is started.

Speccy takes up a lucrative amount of system resources and locks up the system.

 

Situation 2:

Speccy is already running.

Fraps is started.

Nothing bad happens.

 

Actually it was Nodles who told us after he put in the effort to download and read a 33 kByte text file.

 

Why so snide? All of the main system information is at the top of a DxDiag for quick access.

[Alan_B]

I was not being snide.

I was pointing out to Superfast that it was Nodles who put in the legwork to state your system, and not yourself.

 

I did not recognise the source of DxDiag and did not know that it held your Operating System,

so had not downloaded when I asked that you identify the O.S. - my bad

[Scales]

A detailed report has been sent to the Fraps team as well.

 

Alan, I'd prefer that you cease posting in this thread.

 

If any devs or others have thoughts pertaining to the problem, I'll be happy to assist.