Home
Products
Overview
Compare Products
Actual Window Manager
Actual Multiple Monitors
Actual Title Buttons
Actual Virtual Desktops
Actual File Folders
Actual Transparent Window
Actual Window Minimizer
Actual Window Guard
Actual Window Menu
Actual Window Rollup
Download
Actual Window Manager
Actual Multiple Monitors
Actual Title Buttons
Actual Virtual Desktops
Actual File Folders
Actual Transparent Window
Actual Window Minimizer
Actual Window Guard
Actual Window Menu
Actual Window Rollup
Order
Single User License
Corporate Sales
Upgrade Center
News
Latest news
Newsletter
Support
FAQ
How to Upgrade
Restore License Key
Online Demos
Online User Manual
Forums
Announcements
General
Feature Requests
Technical Support
Tips and Tricks
Beta Testing
Feedback Form
Beta Testing Section
Resources
Articles
Reviews
Success Stories
Multi-Monitor Wallpapers
Company
About Us
Contact Us
Privacy
Our Clients
Press Center
Press Releases
In The News
Reviewer's Guide
Logos and Screenshots
Publishing-friendly Graphics
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: 9547
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