search

thpatch / thcrap

Touhou Community Reliant Automatic Patcher
https://www.thpatch.net
The Unlicense
561 stars 41 forks source link

Guard against conflicting plugins #59

Closed Zrrg closed 4 years ago

Zrrg commented 7 years ago

It worked fine before I've tried to install jisakujien's hitbox patch (http://www.mediafire.com/download.php?vive3tpn34n45qe). I've replaced d3d8.dll and put hitbox.png into game folder. it works fine while I launch game via vpatch and crashes, if I launch thcrap with vpatch.exe as game exe. Game gives memory error at start and crashes, when Shift is pressed.

nmlgc commented 7 years ago

I can't reproduce this on any of my Windows installations. Could you please post a screenshot of the memory error, as well as thcrap_log.txt?

Zrrg commented 7 years ago

Strangely, it worked fine on other computer on Win7, so it may be single case. This is WinXP. It says "The instruction at A referenced memory at B . The memory could not be read" 59ws4aauwug thcrap_log.txt

nmlgc commented 7 years ago

I can't even get that box by provoking a memory read access violation on a clean Windows XP installation, so it's very likely that something else on your system injects its code into the process. Let's find out: Please replace the thcrap.dll and thcrap_tsa.dll with the versions in the attached .zip file, then crash the game again and post both the message box (the addresses might be different) and thcrap_log.txt. thcrap Module logging.zip

Zrrg commented 7 years ago

pic thcrap_log.txt

nmlgc commented 7 years ago

Could you repeat this with the Sandbox patch in your configuration? (Since the crash happens during the first stage, I put the necessary debugging code into the .msg patcher, and it's guaranteed that vpatch is initialized by then. And without the Sandbox patch, no .msg files are getting patched.)

Zrrg commented 7 years ago

image thcrap_log.txt

nmlgc commented 7 years ago

Turns out the problem was the fact that @Zrrg had a second instance of thcrap_tsa.dll, thcrap_tsa.dll1, which got loaded into the process. This happened because we're calling FindFirstFile() with "*.dll" to enumerate DLLs, which also retrieves any file whose extension merely starts with .dll because the 8.3 name of a file with a longer extension simply includes the first three characters, and Windows still has to support 8.3 name parameters for FindFirstFile() for reasons of backwards compatibility.

I've wanted to do something about this for a while, especially since the Visual Studio solution currently puts both the Debug (*_d.dll) and Release versions of all binaries into the same output directory. The best solution I can think of right now would be to look at the global reflected list of functions, check if a newly loaded DLL would overwrite any of them, and then either silently ignore the wrong DLL if we can identify it for sure (which we can by searching the list of imported DLLs for the Visual C++ runtimes), or show a conflict warning message.

Which probably should be nicely formatted, meaning that this needs a GUI to be fully done.

brliron commented 4 years ago

Duplicate of #116