ClockBlocker (profiled AMD power-management control)

Device requires an old version of LGS? Do you get any log created from the proxy dll in Documents (indicating that it's loaded even), or any other sort of error?

--Very possible that the older releases don't depend on Quartz. I'll probably have to take a look at that version when I get some more time, most likely can swap over to / write an external injector (create remote thread & suspend on launch) rather than relying on a self loaded dll.
(to improve compatibility with different versions)



If you have some log produced, if you can PM that to me or post it here that would be a big help as a starting point.

EDIT: My guess is that Logitech won't be adding any future fix to an old release if they're not even allowing their older hardware to be used on new versions of their software.
---So, this is probably something we need to fix ourselves.


Update:
Downloaded, installed, and looking at LGS 5.10.127. It looks like the app doing profiling in this one goes by a different name than LCore (LWEMon this time), and also it doesn't load Quartz.
--You can ignore my request for a log, as you won't find one (hooks aren't loaded).

Since the behavior is the same as in the latest LGS, I assume that the detection issue is the same (the API use for detection looks the same at first glance). **Just need to adjust the method of loading the hooks.

^ I should be able to get this done without owning a device to test with (one that's compatible with the older version).

 

Coming soon... Just a bit more testing of the x86 loader on Logitech WingMan.



Essentially we're moving away from loading through a proxy-DLL, to external injection through a launcher.

This has some implications:
-No more risk than the current approach (through proxy-DLL) to anti-cheat software, in that we're still touching nothing on the machine aside from LGS. (no global injection & hooking)
-More compatibility with future and prior LGS versions. (no risk of dependency or exports changes)
-LGS' STOCK auto-start won't include the hook. That means you guys will need to disable Logitech's start with Windows, and create your own startup links to this loader instead.

 

Main post updated, 1.1 released.

1.1 changes:
-Moved to external injector (launcher) rather than proxy-DLL injector.
-Under the hood changes to get 5.xx working. (this release should work on both old and new)
-Made some minor edits to the readme. (be sure to read them and that you make use of the loader programs)
-Log path now includes a suffix indicating the launched process.


NOTE: It probably goes without saying .. incase though, don't forget to remove "Quartz.DLL" if you were using 1.0 first. Don't want to be double hooking. I suspect nothing bad would happen, yet best to avoid it.

 

Works but there's a problem with this one. I have to close and open it every time I start up.. it does not work the first time ever

New one already and this is why I ask, lol!

 

-Please see the included readme. This release is not intended to be an "upgrade".

^ There is no reason for you to change to 1.1 ... as 1.0 was working fine on your machines.
** Correct me if I'm mistaken or if there's something we need to address.

 

With some more RTFM it works! doh
Also fyi some of us just like to run new things. It's an addiction

One more question if I can please.

I'm trying to understand what's wrong with LGS and want to know what I'm using on my PC. Playing with lots of apps here and I can't find a single one that breaks LGS.. other than Clock Blocker. Lots of these have hidden windows (seen with Spy++), but they work just fine with LGS.. So.. how does your program have hidden windows and doesn't work and all the other ones do? You say that the hidden windows issue effects lots of apps but can you list a few?

Till using Clock Blocker everything just works. I want to know why.

 

-Happens to everyone, you may notice that I didn't just word it as "RTFM".

-Often that's a good practice whenever security is involved.
(Virus Definitions, OS Updates, browser updates, email client updates, and so on)

-This is not one of those good practice situations.

LGS-Hook only serves a single purpose (blacklisting ClockBlocker's helpers) without the intention to expand on that. Unless it stops working there's probably no real motivation to change from a working version.
^ Of course I won't judge you if you just want to run the bleeding edge of everything. However, I can promise that you'll have more problems as a result (and gain nothing for it).


--- Updating because you want to test is fine, but don't cause yourself unnecessary problems just for the sake of being up-to-date.

I'm not sure what type of explanation you're looking for... I can try to elaborate a bit, yet at the same time I feel the brief two-line jist that I wrote was actually pretty thorough.


-To cause the issue with LGS a program needs to have a window, and this window needs to never be shown. That's it, literally. My suspicion if you're testing programs with invisible dialogs that are not shown on launch, is that they actually are shown (quickly hidden after creation) and that you are just not noticing this.

^ I suggest that you start one of these programs with a delayed startup using the Task-Scheduler "AFTER" a game is running in fullscreen mode and see what happens. (or however you're testing right now) Probably the launched program will steal focus, its window gets hidden, focus returns to the game window. If you're fullscreen the game will minimize to the taskbar and then restore. (assuming you don't click the desktop during that time)

** LGS functions here because a focus swap happened and the foreground process changed (however briefly it happened for). There was thus another event for the return to the game process. If you're playing around in "windowed mode" you may just not notice it.


Per MFC, typically people just call "ShowWindow(SW_HIDE);" after creation. The window spawns, is shown a split second, then is hidden. It may happen so fast that a person doesn't notice, yet it was still shown and STILL takes OS focus.

Far as ClockBlocker, doing this would be unacceptable (Reason outlined above). A much better way is to override WM_WINDOWPOSCHANGING, like so:

Code:

void CSomeWnd::OnWindowPosChanging(WINDOWPOS* lpwndpos)
{
	lpwndpos->flags &= ~SWP_SHOWWINDOW; // <= remove SWP_SHOWWINDOW
	__super::OnWindowPosChanging(lpwndpos);
}

^ This way the window is never shown at-all and never is thrown in the foreground.


Why do ClockBlocker's helpers (child processes) have windows?
-Design of the program is split in to components in order to completely unload libraries (such as OpenCL) after loading them.
----Completely unloading libraries is necessary as other applications (such as MSIAfterburner) will otherwise detect ClockBlocker's use of 3D API's after a game closes. (eg, OpenGL -- which gets loaded as a result of loading CL)

-Since functionality of ClockBlocker is split apart in to separate processes, these need some means to coordinate between eachother. (when they should end, the status of other components [such as detecting a crash for graceful termination], what they should do -- Blocking Mode, Clock Speed, etc)

-ClockBlocker uses a combination of Shared Memory (memory mapped file), Windows Messages, Mutexes, and polling.
----Mutexes and Windows Messaging permit an easy means to serialize communication. Obviously Windows Messaging requires having a 'window'. This window cannot take focus as the helper processes always launch "after" a game gains focus. [Stealing focus on each profile swap would endlessly minimize a fullscreen game]

^ While there are other ways to do this (and to structure the program that would avoid it), I am not going to drop use of Windows Messaging or make radical changes to ClockBlocker because of LGS' misuse of its hooks.

-Sure, pick any program that starts minimized in your system tray.
Most of them will spawn their main dialog hidden, or will go with the other route of creating this dialog and then immediately hiding it.

EDIT: ^ The reason these programs don't cause you grief with LGS is because they started with the machine 'BEFORE' a game was loaded. (and then they stay resident)

 

You blame LGS.. but only your software causes LGS to screw up. What I'm trying hard to understand is why logitech is the fault and not CB. You complain about changing CB, but from my view everything on my PC including LGS worked software wise until I ran your tool.

See what I'm getting at here? That's what's not making sense to me that you expect logitech to do something about this.

I'm running apps during gameplay started how they usually start. If I set a program to start in task scheduler myself or edit its startup, then this sounds very far fetched and not like normal use. Also it sounds like you missed a part of the problem.

Edited your quote to show what I feel you left out. If I got that right it sounds like CB launching the helpers after the game starts is the true cause.

So.. isn't that CB causing it and easy to fix by starting the helper before a game starts? I'm not a programmer but this sounds like an ordering issue.

But these apps normally never start in a way that will cause problems, right? I wanted an example app that caused the issue normally other than CB.

 

-No, I don't see what you're getting at.

What I see is that you've decided that somehow ClockBlocker is at fault ... despite that a bug in LGS' foreground detection (misuse of hooks within LGS) is causing otherwise totally-legal software usage (starting a program with an invisible / hidden window) to break detection.

I'll re-iterate again, a program not showing a window is 100% "legal". There is nothing wrong with doing this, and there is no legitimate reason that LGS shouldn't be able to handle this.


=> I expect Logitech to fix their software, because there's a bug in their software.

-That it's an ordering issue is completely irrelevant. It's also not trivial, and I did not miss anything, I talked in my reply to you about launch order explicitly -- thanks.

I will re-state once more that ordering is irrelevant, and so is whether or not CB is the only program under normal-use that you have that causes this issue. The cause is "a bug in LGS", period.

-It's not my job to provide you an example of some software that causes the problem. (You can build such a test program yourself)


Now for being blunt:
-We're done with this type of discussion.

I provided you a workaround and it clearly works as you've said it's working for you. If you have a problem with ClockBlocker or the provided workaround, stop using them.

 

OK OK, chill :wanker:

CB is very helpful for me. Not trying to rub you the wrong way.

 

Hi Razor,

did anything big change in 17.4.1 so that Clockblocker has issues with any method (ADL / compute)? ... am on GCN 1.0

 

I haven't gotten around to testing the new release just yet. However, on the otherhand noone has mentioned anything to me either of issues.

Sounds like something is wrong on your end?
--I'll check them out in depth soon as I get a chance. (may take until the weekend)

 

You don't really need Clockblocker for GCN 1.0, as you can set a profile in Wattman and simply use the highest clocks for all its States.

 

From the image there I notice that power state 4 is omitted. While I haven't installed the drivers yet, ClockBlocker only is giving special consideration in 16.12+ (1.3 beta) to state-0 (the low power idle state).
-Trying to control locked down states causes them to not be set with ADL, and so that might be the problem.


@vase: can you PM me a log from ClockBlocker trying to apply a block rule with a blocking mode that contains ADL?

 

The settings I posted do give me locked gaming clocks.

 

Indeed, I expect that would do the trick for you, didn't mean to imply otherwise.


More just looking at that picture (as one from an older card) and trying to extrapolate possible causes of why ClockBlocker isn't working on 17.4.1 with vase's setup (before I do anything later on). I don't leave my 7950 in an active machine, so I basically have to swap hardware to do any sort of testing.

--To clarify a bit, the states display in Wattman reflects what ADL can touch to a degree.

 

Any fix for Win10 creators? I update today and now blocking stopped working.

 

-No adjustments have been needed for 15063 in my own testing.
^ I've now gotten around to playing with AMD's 17.4.1 drivers a bit as well.

(This has not been extensively tested by any means, ClockBlocker at least seems to be working on both the new drivers and Creator Update though)
NOTE: This is with the latest "beta" release (1.3), and not 1.2.6-5.


What exactly are you noticing behavior wise? (eg, Program crash? Won't start? Block profiles specifically not working anymore?)
=> Also, please PM me a log while applying a block profile (from within ClockBlocker) and or paste it in this thread. (** assuming you can do so and it's not a crash **)

--- I need a bit more specifics basically.
[Screenshots, description, logs, anything you can provide for hints]


More (edit):
Also a good idea after upgrading to the new Windows release to check what drivers are installed. At least for me, upgrading caused WUA to install-over what I had on there.

-You may need to DDU and re-load 17.4.1.

 

CB just stopped working and profiles do not work anymore. No crashes.
Here is the log https://pastebin.com/VrRGHzhN

I check and I have 17.4.1 installed still, games all working just fine.


So what next?

 

-There is something wrong with your drivers. ADL and CL support are missing or non-functional.

^ This is the HD 4600 iGPU in your system (judging from your forum specs).

-My hunch is still that this is a driver problem. I would wipe your installed video drivers with DDU and reinstall.
(that's probably all you need to do to get ClockBlocker working again)

That games are working I would not take as an indication that the drivers are working fine... Something is clearly messed up as seen in the logs.


=> Let me know if that doesn't work, of course.