Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
Yeah, this is annoying. The only way to keep it out of your games is to go into the file properties for the DLL and add a DENY entry for Execute permissions.
Properties | Security | (your user account), Edit:
Read & Execute: DENY
Eventually Valve's going to make even this solution non-functional, and then you should just stop buying games on Steam altogether.
It works, thanks for the idea.
I ended up setting the files to have:
It tried resetting on the next launch but it failed and created a file called:
You can go ahead and try to block it functioning as you have, but you can expect some sets of Steam functionality like Steam Input / gamepad support, in-home/remote streaming, and more to be fully broken.
The dll appearing in the callstacks you looked at for a hang in Mass Effect isn't really evidence it's related at all. It will hook into some function calls and can appear, when all it's doing is passing through calls. Further, you won't have debug symbols for Mass Effect or for the overlay, so your callstacks are likely all inaccurate after you hit the first stack frame that doesn't have public symbols from Microsoft. Without looking at the callstack (and possibly without having Mass Effect 3 symbols) I can't tell you what did cause the hang, but it's very likely not the overlay dll.
I'd suggest you don't try to prevent it being loaded, you are breaking things you wouldn't expect, and you likely aren't solving the game hang or receiving any actual benefit by blocking it.
First of all, thanks for responding and apologies for venting my frustration.
It would be nice if you could provide a full list of functionality which will cease to work.
So far none of the things you mentioned are relevant to me for this particular game. As far as I know Mass Effect 3 isn't using Steamworks for mods. Perhaps the achievements? But I already have them at 100%. Cloud saves? I don't use them.
I see no personal benefit of that DLL being injected into the process and potentially causing instability because let's face it -- overlay hooking (which probably uses MinHook) as well as any other form of process hooking outside of Windows' sanctioned hook API is a hack job and depends heavily on the game (and / or its DRM) cooperating with you.
As such it may, through simple interactions such as call pass-through you are mentioning, expose hidden game bugs such as bugs in threading synchronization / locking by just changing the timing of a single call.
It is kind of irrelevant what was the exact cause of the hang, because Mass Effect 3 is a 32-bit game which is running quite close to the 32-bit process address space limit (try playing single player and then loading multi player then going back to single player and chances are you will already be missing some UI textures), and as such tends to be finicky even if you don't inject any hooks into it.
Origin (and probably EA App as well) respect the overlay setting in the sense that when it's off nothing is injected into the process.
Injecting a DLL wastes limited resource (32-bit process has 2 GB or 3 GB with LARGEADDRESSAWARE flag) by mapping said DLL and anything it needs into a finite process address space.
I believe that I as a user should have the right to decide whether any of the functions offered by this DLL are relevant to me, and if I don't need any of them in a specific game then I expect said DLL to not get injected into the game process. It's as simple as that.
This is especially important for old games such as Mass Effect 3 which are no longer supported and which are somewhat unstable due to them running at the limit of technical limitations of the time when they were produced.
I really hope you guys will reconsider allowing us to fully disable injection instead of resorting to hacks.
SteamAPI itself will actually load the overlay, and 99% of games on Steam these days use it.
I'd say generally you don't need to be too concerned by the DLL being injected, even though it does have non-defeatable hook code.
I have to prevent it from injecting from time to time in order to debug stuff correctly, but it mostly stays out of the way if you just export:
SteamNoOverlayUIDrawing=1
Not gonna lie, this sounds awesome…
In this particular case I am only concerned with the DLL and its dependencies taking up valuable 32-bit process virtual address space.
Steam Input doesn't work to begin with, I wish I didn't have to do all sorts of code gymnastics to get it to stop breaking HID, DirectInput, SetupAPI and XInput. Buying games on alternative stores is so much more attractive, because input simply works.
If you've got your own code in the game one way or another, you can hook LoadLibraryExW, check for "gameoverlayrenderer" and then SetLastError (ERROR_MOD_NOT_FOUND) and return nullptr.
You'll need to be in the process pretty early for this to work :-\ Most games have an import dependency on SteamAPI, and they'll immediately initialize it, bringing the overlay DLL into the process.
One way of accomplishing that would be with the Windows compatibility shim loader or Image Execution File options to load a DLL to prevent the overlay from loading globally.
Frankly though, Valve needs a literal kill switch for this stuff. Because it's SteamAPI loading the DLL into the process, this is never going to happen, as all games using SteamAPI would have to be patched with a new DLL that respects said killswitch.
The shim database approach is one that could work though.
https://www.boozallen.com/insights/cyber/tech/user-space-persistence-techniques-application-shims.html
Hilariously, almost all discussions on this sort of thing are written with a slant on malware. That's what Steam has turned into, so many unwanted things that the only way to circumvent crap is to do things that normally are only of interest to malware authors.
sigh
You can just block it using NTFS file permissions as I shown above -- it works.
I don't have my code in the game, I just don't nead Steam code messing with that one game.
I wish we were back in the timeline where "disabled" meant the same as in dictionary, not some imaginative "running but kinda-sorta invisible".
I believe it is a valid thing to ask for -- "allow us to fully disable injection in legacy games".
I don't doubt that Steam devs are checking compatibility and writing robust code, the problem is that the games themselves are often buggy mess and anything hacky interacting with them is undesirable. Choice should be ours because we know our games the best.
Finally, injection is what other storefronts such as EA App and Origin also do so we end up having 2 hooks in the process and the chance that something will go wrong grows exponentially.
I know they read this stuff, and then implement all these things just to irritate me.
As soon as I have a working bypass for Steam Input, they go and make it even worse... this is a nuclear arms race to keep Steam from screwing up the entire Windows input stack and I hate it. Steam Input just walks into the place like it owns the place, disables all input APIs, creates fake HID devices that you have to ignore because they don't actually work, and worst of all, when set to off, none of this stuff is actually off.
If only the games I wanted to play weren't Steam-exclusive, I'd be done with this store forever.