ccc.exe memory increases every opening ( all Users ) fixed from kevsamiga1974

sorry for this late feedback, the program works great, I tried only v 1.1 , great job dude

 

A quickly coded hack, but still clever enough in 16K not to interfere with whatever you are doing in CCC....

But really it's up to AMD to fix the leak...not by us having to kludge a way around their ***** drivers.

In the meantime, I also tested a very old CCC from 2008 the one with the skins by forcing it on W7 with a Vista compatibility install, same memory leak so this bug must have been stone age old since they got rid of ATI control panel and replaced it with .NET CCC.

Typical. I always have to go the extra mile when bug hunting... :biggun:

 

ATI Control Panel was better (ccc got it's options from there). No .NET, perfect integration with Windows's windows (LOL) and great performance. I had the honor of using ACP with my agp radeon 9250. ATI even provided it's own uninstall utility, which was very nice.

 

Source code for the untrusting ones...

#PROCESS_TERMINATE = $1
#PROCESS_CREATE_THREAD = $2
#PROCESS_VM_OPERATION = $8
#PROCESS_VM_READ = $10
#PROCESS_VM_WRITE = $20
#PROCESS_DUP_HANDLE = $40
#PROCESS_CREATE_PROCESS = $80
#PROCESS_SET_QUOTA = $100
#PROCESS_SET_INFORMATION = $200
#PROCESS_QUERY_INFORMATION = $400
#PROCESS_ALL_ACCESS = #STANDARD_RIGHTS_REQUIRED | #SYNCHRONIZE | $FFF
#WM_SYSCOMMAND = $0112;
#SC_CLOSE = $F060;

Prototype.i PFNCreateToolhelp32Snapshot(dwFlags.i, th32ProcessID.i) ;
Prototype.b PFNProcess32First(hSnapshot.i, *lppe.PROCESSENTRY32) ;
Prototype.b PFNProcess32Next(hSnapshot.i, *lppe.PROCESSENTRY32) ;

Procedure GetProcessId_(hProcess) ; for windows Vista, Windows XP SP1, Windows 7
Protected hThread
Protected Pid
Protected GCPI

GCPI = GetProcAddress_(GetModuleHandle_("Kernel32"),"GetCurrentProcessId");
hThread = CreateRemoteThread_(hProcess,0,0,GCPI,0,0,0)

If Not hThread
ProcedureReturn 0
EndIf

WaitForSingleObject_(hThread,#INFINITE)
GetExitCodeThread_(hThread,@Pid)
CloseHandle_(hThread)

ProcedureReturn Pid
EndProcedure

Procedure GetPidByName(p_name$)
Protected hDLL.i, process_name$
Protected PEntry.PROCESSENTRY32, hTool32.i
Protected pCreateToolhelp32Snapshot.PFNCreateToolhelp32Snapshot
Protected pProcess32First.PFNProcess32First
Protected pProcess32Next.PFNProcess32Next
Protected pid.i

hDLL = OpenLibrary(#PB_Any,"kernel32.dll")

If hDLL
pCreateToolhelp32Snapshot = GetFunction(hDLL,"CreateToolhelp32Snapshot")
pProcess32First = GetFunction(hDLL,"Process32First")
pProcess32Next = GetFunction(hDLL,"Process32Next")
Else
ProcedureReturn 0
EndIf

PEntry\dwSize = SizeOf(PROCESSENTRY32)
hTool32 = pCreateToolhelp32Snapshot(#TH32CS_SNAPPROCESS, 0)
pProcess32First(hTool32, @PEntry)
process_name$ = Space(#MAX_PATH)
CopyMemory(@PEntry\szExeFile,@process_name$,#MAX_PATH)

If UCase(process_name$) = UCase(p_name$)
ProcedureReturn PEntry\th32ProcessID
EndIf

While pProcess32Next(hTool32, @PEntry) > 0
process_name$ = Space(#MAX_PATH)
CopyMemory(@PEntry\szExeFile,@process_name$,#MAX_PATH)

If UCase(process_name$) = UCase(p_name$)
ProcedureReturn PEntry\th32ProcessID
EndIf

Wend

CloseLibrary(hDLL)

ProcedureReturn 0
EndProcedure

; This appears to be pretty much how Windows kills a program if you 'End Process'
; from the Task Manager. Note that this is 'unfriendly'!

Procedure KillProcess (pid)
phandle = OpenProcess_ (#PROCESS_TERMINATE, #False, pid)
If phandle <> #Null
If TerminateProcess_ (phandle, 1)
result = #True
EndIf
CloseHandle_ (phandle)
EndIf
ProcedureReturn result
EndProcedure

; Main Loop

Repeat

Delay(3600000) ; 1 hour delay and sleep

w.l=FindWindow_(0,"Catalyst Control Center")

If w.l=0 ; If the Catalyst Control Center is closed, kill and relaunch, otherwise schedule for next hour.

KillProcess(GetPidbyname("CCC.exe"))
RunProgram("C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static\CCC.exe","","",#PB_Program_Hide)
EndIf

ForEver

 

Care to explain why my CCC still takes less than 10MB of memory when runnign in the background and 100-150MB when opened even after two weeks of uptime?

You know why AMD is not fixing this horrible memory leak? Because there is none. Reserved (virtual) memory is not used memory.

 

Maybe you're lucky...

Look man i'm not here to argue the toss. The guy had a problem. I made a 5 minute fix simple as, completely free to do with as you please. The commit memory size increases of CCC are patently obvious and not just for me.

Other apps don't come close to doing anything near what CCC is doing. If VM is being exponentially reserved, why is it being reserved ?, what for exactly ?, and more so to the point why isn't it ever being expunged.

That's classifies as a leak in my book whichever way you want to interpret it. Problem solved. The End...

 

Actually, I overlooked the GPU memory usage part. That IS a problem, much worse than the debatable system memory thing.
Playing around with it, I managed to get GPU memory usage up to 600MB, which is pretty horrible.

On the other hand, I wouldn't just flame AMD to hell. I am sure they will fix it if enough people report it. You know, maybe it never showed up as a problem and they are not even aware of it.

 

What??? for 5 years...or shall we dare go back further and say since the conception of CCC. That's a long time to not be aware of "something" like ""Jesus where's all of my memory going."

If they ain't taken to task on these things then they'll just never fix anything. Like the abysmal 2D performance on the 5000 series worse than el cheapo IGP's that was fixed in 10.4 after admitting it and being pressed over it repeatedly by Tom's Hardware.

Of course the gfx ram usage is going up and up opening and closing CCC, you can see it climbing on the graph inline with the commit size...

 

I would recommend try a clean OS installation, probably in a VM if you don't have a spare system and re-check your findinds, before calling it an issue.

If some user have it and other not, then it sounds more like a follow up error caused by something that is broken deeper in the system!

 

^ This one just totally cracks me up...

What do you think I tested the really old CCC's on ?

You know the ones even older than 2008...clue it wasn't a Windows 7 box.

 

Yeah. I even had one person on here ages ago also with a 4870x2 swearing blind they didn't get the clock bug with any of the 12.x drivers. oh *you* must be doing something wrong. When the world and his brother knows it exists.

It's totally frustrating here sometimes getting past the road blocks and time wasters.

Idiots...they don't see anything because they want to be an ostrich, and they don't want to go digging or find anything out for themselves that will discomfort them from using their proud loyalty cards cocooned in a bubble.

It wasn't even me who discovered the problem to start with, and now i'm getting told to re-install. 3 people confirming it can't be wrong, ridiculous...

If bugs are known about and out in the open, then people might be able to offer a solution for others. Hardware is useless without decent software.

 

3 different rigs, one with 4870, another with 2 5870 and another with 2 7850, one with w7 and two with w8...i never, but never experienced this problem for many years...so...

if i think that amd cannot reproduce the problem and with my personal 3/3 win win situations, i neither can accept that as a real world problem...

i also never had the famous 3d/2d clock bug as mentioned above...

now if you conclude my systems and amd's official point of view, you can't blame me or amd for these problems...

we know at least the basic terms of programming some people, you can't debug and fix something which is not broken.

 

Some testing I did:

The Private Byte usage of CCC.exe did climb with each open, but it didn't seem to climb "that" much.

For kicks, I'll even record a video of it in a bit

Edit: http://youtu.be/ojEYBpZBFZM (will be done uploading soon)

 

Look...don't go complain at me, kindly PM the OP for his opinion on whether he's happy with the solution, he seems to be leaking even more than me. I said earlier up I was never leaking 50mb a time. But there is no denying the gfx memory of the CCC process is being munched on and never being returned via process explorer.

And Hydravision has a memory leak all of it's own.





66% Physical memory in use out of 4gb just sat with Firefox open and playing with CCC which the taskmanager shown above verifies. Now kindly explain what other app apart from CCC reserves over 2gb of ram in use. And if it's supposedly as suggested reserved memory (not in use) then prey tell why have I got 66% physical memory in use doing absolutely nothing but fooling with CCC on the left and at the bottom of the screenshots...so if I can't fix something that isn't broken man, then ask the thankful OP why he get's all his memory back every hour from his CCC process now instead. Sorry but you have the pants completely down here ova this issue.

How can the Physical memory in use at the bottom+left and the commit size column lie ? and take note of the Physical memory usage history rising.

The camera never lies my friend, unless your going to tell me next this is all a mock up or maybe it's a feature not a bug. CCC used here is latest for legacy cards, but happens on all previous versions before it as well. If you're doing the testing on later CCC/different cards then it may or may not happen obviously because the files/other factors are coming into the mix.

Now onto the clock bug. You don't see it (and jolly good for you) because:

1. You have a single 4870.
2. It doesn't affect 5000/7000 series in this combination.
3. I'll just let everyone else chime in with what happened after 12.2-12.6 on legacy multigpu cards and 5970 users as well for that matter just for kicks.

Another half an hour of time wasted on further justification and proof. I'll leave others to comment on the clock bug including Kn00tcn who also has 4870x2 if you think I'm here fixing things for legacy cards for fun and just working around AMD's crap-shoot drivers for nothing.

GPU graphics memory usage of CCC process inline with 2GB ram usage of opening/closing cycles of CCC process above.



Half a gig dedicated GPU memory use. Approaching over a gig GPU committed memory use, attributed on the CCC process itself and alone *without playing any games* or listing any other tasks using gpu memory apart from the CCC process on a system that is going to be asking for this same memory for other tasks/games later on down the line.

That's a whole lot of system and graphics resources used for just a "little control panel" just being opened and closed. So don't sit there and tell me there is no memory leaks when I tested it all out for hours of my time according to the OP's findings initially aswell.

Process explorer doesn't lie about any of it. Pretty depressing reading huh ppl.

No denying the facts, but clearly I'm obviously wasting my time fixing other peoples problems that don't according to you, or at least for you actually exist or apparently haven't been noticed for years by yourself neither AMD...

No problem here then, you don't need to bother with using the fix. It's really that simple. And in any case the fix was for the OP, and the OP changed the thread title for it not me.

No need to keep stating the obvious that the problem doesn't exist for you despite 3 other people confirming it, or jumping ignorantly to AMD's defence. You can all just thank me later when it's fixed for real.

However you did just accidentally win my special badge award....

 

Sometimes ccc likes to use 30/50 (maybe a little more) mb of memory but it goes down eventually.

OMG my ram

 

But i'm pretty sure it doesn't use like 300 or 500mb. Also, ccc can be stopped when you don't need it.