安装 Steam
登录
|
语言
繁體中文（繁体中文）
日本語（日语）
한국어（韩语）
ไทย（泰语）
български（保加利亚语）
Čeština（捷克语）
Dansk（丹麦语）
Deutsch（德语）
English（英语）
Español-España（西班牙语 - 西班牙）
Español - Latinoamérica（西班牙语 - 拉丁美洲）
Ελληνικά（希腊语）
Français（法语）
Italiano（意大利语）
Bahasa Indonesia（印度尼西亚语）
Magyar（匈牙利语）
Nederlands（荷兰语）
Norsk（挪威语）
Polski（波兰语）
Português（葡萄牙语 - 葡萄牙）
Português-Brasil（葡萄牙语 - 巴西）
Română（罗马尼亚语）
Русский（俄语）
Suomi（芬兰语）
Svenska（瑞典语）
Türkçe（土耳其语）
Tiếng Việt（越南语）
Українська（乌克兰语）
报告翻译问题
讨论规则及指引
2 
举报此帖
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.
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.
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 found an even better way.
I wrote a simple launcher which opens those two DLL files with sharing mode set to none then launches Steam and waits for it to exit before closing them effectively making them inaccesible without having to fuss with file permissions.
It also temporarily disables Steam client update on launch by creating steam.cfg to avoid Steam client trying to repair the installation when launched. It removes steam.cfg before exiting so that you can update Steam normally when you run it without launcher.
They already do that hence my workaround.
For "fun", I've been analyzing what is causing persistent frame drops on my machine in Team Fortress Classic (the greatest game ever made). I have the Steam overlay disabled as well, but it looks like gameoverlayrenderer periodically calls functions that need shared critical sections deep in win32 land. Sadly, no matter how desperately you try to minimize all windows and/or close non-critical apps, Windows seems to always have an occasional storm of activity in the background that needs the same critical section resulting in stalls of the hl.exe renderer.
Example call stack: