ClockBlocker (profiled AMD power-management control)

I get the same crashes on both the 32b and 64b versions. DEP settings in Windows were on the Windows services & programs only, so DEP should have been off for ClockBlocker.

I tried to switch to the other one (on globally with exceptions) but it won't let me add ClockBlocker, either the 32b or 64b version. If I try to add the 64b version I get a message saying that DEP attributes cannot be set on 64b executables and if I try it on the 32b executable it says that the program must run with DEP enabled and that it cannot be disabled. I've scoured the BIOS, but was unable to find anything about DEP. I guess it's either missing or under some name that doesn't contain 'DEP' or 'Data Execution Prevention' and I didn't see it.

Also, I have temporarily disabled the iGPU to test it out. By this I mean that I have turned it off in the BIOS (but haven't uninstalled the drivers, still, it no longer shows up in Device Manager). This did not fix the problem and I still get the exact same crashes with the same addresses. It looks like it could very well be caused by something else and not by the iGPU being enabled.

The only other "uncommon" things about my system are CF, FreeSync and multiple monitors I guess.

I also have a Windows 10 install that I'm not really using, I'll give it a try over there too. I don't think I even installed Crimson over there, so I'll see how it goes.

LE: Tried it on W10. Over here I have 15.11 Beta installed (before Crimson) and Windows is a bit out of date (don't have TH2). In any case, it works with the iGPU enabled. So, right now, judging by my own system, the issue must have something to do either with W8.1 or with Crimson 15.11.1. I will get W10 up to date, update the GPU drivers as well and see if it breaks or still works.

LE2: Updated everything on W10, still works, iGPU enabled. There seems to be something else wrong with the game detection though, when I ran Witcher 3 ClockBlocker crashed with a similar type of error I was getting before, but if I set the default profile to block it seems to work in terms of keeping clocks up. I've still seen some small variability, like dropping up to ~30MHz under the maximum clock (temps were fine), but this is much, much better than AMD's amazing default "power saving" that ran my GPUs at <800MHz and turned games essentially unplayable.

 

@ Bloodred217:
The DEP related guesses were a long shot overall, though 2/4 of my machines do have an issue when using software implementations of it. The BIOS options impacting Windows' DEP feature generally aren't labeled DEP or anything sounding similar, but rather are named along the likes of "Hardware NX support" under a CPU category. [not all motherboards have such an option too]

--If Hardware support is disabled in BIOS, the OS falls back to a software implementation (and in this case, the software implementation is what was causing trouble with my machines). 1.0-7 got around that by being built as a mix of code from two compilers (just the VCC compiled code causes issues). Anyway, seems this wasn't your issue.

(The exclusions was just a guess on the spur of the moment, not something I actually tried)


Far as Windows 8.1.. Ironically the main machine that I work on ClockBlocker on is an 8.1 system, w/ Crimson 15.11.1. It's also one that has all Windows Updates installed, including many beyond what's available via just WUA.

(here's a dump from WMIC if curious to compare)


**I'm currently thinking of adding something like BugTrap to builds or massive amounts of trace messages, so that I can get a nice record of what happens in each thread on crashes. Still brainstorming on other possible causes for that type of error.. It's good to know that the IGP isn't causing issues though. I had put in alot of code to distinguish between multiple ICD's, yet of course hadn't really tested it properly.

I'd really hate to ask to do a VS remote debugger session, I'll try to come up with a better and less intrusive way to collect info on what's happening first.



EDIT:

Just re-read through that last amendment you made on that reply. This is pretty interesting.

--Does this mean that if you run TW3, ClockBlocker 'hoses' every time with the error that you see on startup?


If it does, this is quite significant. Fullscreen detection is fired up right from the get-go, almost the same time as CL initialization. I've no idea what in the process scanning would crash as there's tons of checks in there (already are), but it's a lead and I'll start looking at that portion of the code again.

---Maybe there's some other program on the 8.1 install that when scanned causes ClockBlocker to crash. Going through and adding alot of sanity checks right now (that I wouldn't believe would be needed ... but we'll play it safe and see if that stops the crashes).




EDIT: And ... those checks are added in 1.0-8, ready for a re-test. In particular I've also delayed the startup of the scanning by 4 seconds after the splashscreen fades. While the scanning was technically active before the splash ended, the splash-screen is probably the foreground window during that time (ClockBlocker excludes fullscreen detection when it's the foreground target).

The 4 second delay post splash-screen should make it clear if it's still crashing, since you'll feel an extra delay or potentially be able to double-click and open the settings before it hangs.

 

1.0-8 released.

This release adds xxela's suggestion of a faster way to manipulate the "DEFAULT" rule action from the tray-menu. It also adds alot of sanity-checks to the process scanning and fullscreen detection.

 

Hello, ive been waiting for years for an app like this, maybe this could help you out.

Radeon pro has a flag in the overclocking section that says to maintain high clockspeed at all times while game on profile is active.

The name of the flag is FULLOVERIDE. idk what it does, but just as your program, it doesn't let the clock go down even if the gpu is at very low usage.

BUT the difference is that this is a registry flag, not a app tricking an app to get this behavior. Maybe if you find out what this flag is and how it works you can implement it to the program you made so it doesn't have to rely on other codes in the background.

Thanks, and good luck!

 

I can't install this tool on win10..
I'm getting this



Could you allow us to change install dir?

 

I've given 1.0-8 a quick test on 8.1, still fails with the same error. It pops up immediately as ClockBlocker opens, not after 4s. The splash screen itself appears and after the animation finishes it fades out nicely. About Witcher 3, I only tried it once with the 32b version running, it crashed immediately as TW3 started. I then tried the 64b version, it did not crash but also did not detect TW3 as a fullscreen application (no specific TW3 profile).

Another thing I noticed, MSI AB seems to detect ClockBlocker as a 3D application immediately as it starts up and switches to the 3D OC profile. I did try disabling AB, but it makes no difference.

Sorry I haven't included much detail in this reply, I'll do a bit more testing tomorrow and come back with a more info, it's 4:30AM over here and I've got work in the morning.

 

I'm on Windows 10 with 15.11.1 CCC, I'm having the same crash as Bloodred217. DEP is off, program is ran as admin. Crash happens immediately as well.

 

I could add support for changing the install dir, don't necessarily have an objection to doing this. I'll just have to store the selected installation path in registry for auto-updates if I do. Didn't think there would be a need to have custom install paths due to the program's very small footprint.


That said, I'm not sure that this will help you though to change the path, because even if you're able to install the tool I'm doubtful that ClockBlocker will run properly (with that type of error message). The Install Shield is created with Indigo Rose Setup Factory (a commercial Setup Shield maker), and I've rarely (if ever) seen a failure like this in past software I've released except where the user's account can't grant admin rights to a program. The Install Shield and the ClockBlocker executables have a manifest that states they need admin rights to run ... yet, just because it's requested doesn't mean that Windows will necessarily obey such (such as if the user account doesn't have that rights level).

In this case the sharing violation is likely because the installer isn't granted rights to write in to that folder. The worry I have is more of a 'why', as ClockBlocker needs admin rights to work correctly as well.



--Is the account that you're using granted admin-level access?

Anything special about your user-accounts that you've set up, or some type of HIPS (host intrusion prevention system) software running on the machine that automatically drops launched process rights? And or, have you altered the default location of the Program Files folders that Windows usually uses?

 

Ah, so the program-crash (error message) happens immediately but the SplashScreen pops up and proceeds to run while the error message is shown?


--That narrows it down a bit, because this implies it's something that happens in a thread separate to the main UI thread.

Thanks! That provides a bit more for me to go on.

I may be able to do something about this by unloading CL (completely) when not using it. I'll take a look.

 

I'm absolutely open to looking at more methods and providing more choices of different methods to locking clock speeds (through ClockBlocker's interface).


-It's ultimately my hopes that through providing some option to stop downclocking on more-hardware, and more-choices to do so .. that interest in such tools will effectively show AMD how massive the demand for it is that exists in their userbase. And furthermore, with this interest that perhaps they will see it as a necessity to match their competition's driver options for it.


It's funny in a sense to design a tool where you say "Hopefully one day we won't need this tool". But yes, I'm hopeful that day will eventually come too.

Cheers!

 

Well you see the bright side.

As AMD customer you know there is not much fun with a Ferrari (Fury X) stuck in "eco mode" AKA downclocking power saving fest...

 

Yeah, it seems that whatever makes it crash is not happening on the splash screen thread, but somewhere else. If it's any help, the tray icon also appears.

AB detecting it as a 3D application is a very minor thing, it should be easily solved by disabling detection for ClockBlocker in RTSS using a profile.

 

Yep, it's definitely helpful to know as I pretty much misunderstood at first. Going to be figuring out fairly soon where the crash is happening exactly because I'm refactoring massively, and literally splitting the project in-half at the moment.


In order to combat the whole 3D-detection with other tools, it's probably going to be necessary to unload CL -- completely. While OpenCL and DirectCompute libraries are very easy to load dynamically, I'm finding it's a nightmare to unload them cleanly during program execution. I can stop and forcedly unload the library (that part is already working), but bad things happen on the re-initialization afterwards sometime. So ... to solve this I'm simply separating the logic, blocking, and GUI.

-It seems the best long term solution to run parts of the program in a separate task that's started and terminated on the fly, and communicates back to the main process through Shared Mem. This will also allow for people to do things like swap out ClockBlocker modules if a new version doesn't work and an old did, while still keeping GUI improvements.

It also should drastically improve stability of the tool through driver-crashes.


--This is probably going to take more than a day.

 

The problem is not the power management system. The problem is because the AMD power management system is horrible! Really bad algorithms and broke our gaming experience.

nVidia have the same feature works much better. Not perfect, but definitely better. Drivers "know" which games needs 100% power and where isn't needed. Not only that. When clock is lowering, rarely there's stutter or FPS drops like AMD drivers.

Again, not perfect, sometimes (Fifa series) we need to turn ON maximum power on nVidia CP, but most of time works fine and it's well implemented.

So summing up, the problem is how bad AMD algorithms are. Incapable to determinate with minimum acuracy what games need full power and not only that, when clock is lowering, there's a lot of stutter and fps drops, destroying game experience.

ps.: Thank you again OP. You're my master now.

 

Clockblocker is the best and almost the only solution for bad AMD power management for me. Radeon Pro works well, but AB need to turned Off and some games aren't compatible. AB doesn't work at all to keep full clock for me. Never worked for it. For me, of course.

 

My friend had problem with the "crimson drivers" both the first one and the hotfix. Apperently while in games her r9 Fury clocked down to around 5-600mhz making the games lag.

She today tried your program and the "crimson hotfix 30nov" drivers and now its working good. Her r9 Fury sits at 1050mhz all the time.

Thanks for a good program!

 

RadeonPro can work for every game/.exe. It doesn't have to be compatible. If the game crashes when RadeonPro is involved, just right click on the RadeonPro profile and select "Disable API detection". The high clocks will work, just not the in-game RadeonPro stuff.

 

Great tool
Run fine with win10+msi ab
Thank you!!

 

1.1-0 is now live. This is a release candidate build with a massive amount of code-change and a complete restructuring of how the program works as a whole. It thus is very very likely to have remaining problems -- so be warned.

If you're feeling adventurous, of course enjoy!


EDIT: In particular of things that I want watched for of people that try out 1.1.

If you see anything like the following (to give a small set of issues that I've been fighting), let me know:
-Helper process not being launched on blocking.
-Helper process not being terminated on downclocking, or closing the program.
-Helper process immediately terminating (both the parent and child monitor eachother incase the other crashes)
-Helper process complaining that it's to be launched by ClockBlocker, when actually launched by ClockBlocker.
-Helper process messages being "duplicated" in ClockBlocker's logs. (appearing 2-3 times each)


I believe these are dealt with finally, but yes to give an idea of the types of problems you 'might' see.


Update - 1.1-0a:
Observed under debugger -- should be gone now for sure:

 

Gave 1.1-0 a quick try, the problem I had is now gone. Thanks!

I just tried setting the default to "Block" and the clocks jumped up immediately. One thing probably worth mentioning is that it only seems to lock to the stock clocks. If I apply an OC profile in AB, it does go a bit higher but not all the way (1050MHz setting results in 1016, 1100 in 1021, 1010 stock is 1010). I'd guess this isn't related to ClockBlocker, but rather with AB/the way the OC is applied. Can't test it right now, but I have a hunch that launching a game would drive clocks higher. I'll try it out later today.