Forums list
New topics
Topics list
Search
Help
Login
Register


Topic: «Actual Multiple Monitors DLL , Disable continuous DLL injection attempts? » on forum: Feature Requests   Views: 9548
 
Syrinx
Registered user
 
Posts: 28
Joined: 12/16/2016
Posted: 12/16/2016 09:48:37
 
 
I am concerned about the way everything is injected with a dll. I realize this is likely due to the multitude of other options it has and is needed for them but as I only want it for two things (to extend the taskbar across monitors and handle backgrounds for each) I think it would work fine for my needs without doing this.

I would like to request an option to disable this constant DLL injection behavior.

While DisplayFusion already seems to have this option I find its high (idle) CPU usage and bloat completely unacceptable. I like to keep a light but secure system and so far Actual Multiple Monitors is a winner in the light area. I also use Sandboxie and all of my non-security\system internet facing applications are run inside. While I can manually block access to the DLLs in question and accomplish what I want within I then notice a rise in CPU usage as the DLL attempts to inject into these protected processes over and over and over. So some type of option\check to avoid these repeated attempts would be ideal but I understand it may still be needed for the likes of Explorer or DWM.

Let me know if you are confused on anything, I may not be explaining myself well.
 
Top
Bogdan Polishchuk
Administrator
 
Posts: 4080
Joined: 04/04/2012
Posted: 12/16/2016 10:49:48
 
 
Hello, Syrinx

Could you create a different user in your system and try to run Actual Multiple Monitors as this user while in your main account. In this case the taskbar feature and ability to set background pictures should work, but none of the processes will be affected by Actual Multiple Monitors. Let us know the result.

Best regards.
 
Top
Syrinx
Registered user
 
Posts: 28
Joined: 12/16/2016
Posted: 12/17/2016 07:14:55
 
 
First off, thanks for the speedy response!

Secondly, my results were not what I had hoped for. =(

I tried terminating the running exes and launching with runas for a new SUA/LUA account but no dice at first. I got a "Runtime library version mismatch. Please log off and then log on..."
After a reboot I finally got that part sorted out and at first things seemed promising.

On the up side, with runas used this way, the DLL is not injected into the *unsandboxed* processes...so while close sadly the dll still gets injected into any program ran inside Sandboxie. I suspect this may be due to the way it runs the programs under ANONYMOUS LOGON which is even lower in rights than the standard user accounts....
Program windows would not 'maximize' normally (eg respect the expanded taskbar) and in addition (but less important) the extra options on the desktop such as next slide etc were not available when runas was used.

After a bit more thought, I wonder if it might have been better to ask for a blacklist where we can add programs that should be 'ignored'? I think this would end up with the same results that I desire.

Very clever idea but unless I mucked up the tests it doesn't seem to help in this particular scenario.
 
Top
Bogdan Polishchuk
Administrator
 
Posts: 4080
Joined: 04/04/2012
Posted: 01/17/2017 16:31:02
 
 
Syrinx,

Quote
While I can manually block access to the DLLs in question and accomplish what I want within I then notice a rise in CPU usage as the DLL attempts to inject into these protected processes over and over and over.
Do you adjust some special settings to prevent DLL injection into the programs running inside the sandbox?

What exactly process has a rise of CPU usage?

How have you figured out that there are constant attempts to inject DLLs? Does some special software display this?

Best regards.
 
Top


User(s) reading this topic
Number of guests: 1, registered members: 0, in total hidden: 0


Forums list
New topics
Topics list
Search
Help
Login
Register