Regression: In 1.3.x branch it is no longer possible to use 3DMigoto + Reshade 3.x #98
Comments
|
This works fine for me (Win 10, tested in DOAXVV) and others, but still others report it broken. I'll need the logs and some details of your environment (What OS? If Windows 7 do you have the evil update installed?) |
|
This also works fine on my Windows 7 (with evil update KB 2670838 installed) box. Again testing in DOAXVV since some people report it doesn't work there. Reshade is version 4.0.1.488 since that's what the DOAXVV mod uses, so maybe this is something that has been fixed since 3.x? |
|
I've just seen a forum post of someone who managed to work out that their compatibility issue between 3DMigoto and ReShade was actually caused by RiverTuner (this isn't the first time I've seen that tool implicated in all sorts of random issues - I guess it hooks into the whole universe... poorly). Are you using that or have it installed? |
|
Bad ReShade log from random user 1: dxgi.log No one has yet sent me a 3DMigoto debug log of this crash. |
|
One possible lead is that ReShade appears to do much what SpecialK did - hook D3D11CreateDevice and redirect it to D3D11CreateDeviceAndSwapChain, so it's possible we've hit another case of that game of hot potato since 3DMigoto does the opposite: We do have code in 3DMigoto to protect against that scenario for SpecialK by ensuring that we don't ever call our own exported function that SpecialK hooked, but it appears that ReShade bypasses that by hooking the real d3d11.dll directly, which of course we do call: My guess is that when we call the D3D11CreateDevice in the system d3d11.dll it gets redirected to ReShade, that then calls back into us and here we go with the hot potato again. I still need to actually confirm this and understand why it doesn't happen on either of my systems (maybe just something to do with the load order or delayed hooking in ReShade?). |
|
Possibly related to #83 |
|
More discussion of the possibly related SpecialK issue in #78 |
|
I could REALLY use a 3DMigoto debug log for this. Everyone has given me ReShade logs of this issue, but no one has yet given me a 3DMigoto log. |
|
Possible lead worth investigating (if I can ever manage to reproduce this issue) - PCSX2 devs debugged a crash down to ReShade's D3D11CreateDevice to D3D11CreateDeviceAndSwapChain redirect, which suggests they are calling a NULL/invalid pointer for their trampoline in some cases. This would be an alternate explanation to the crash that does not involve a game of hot potato since the crash would be immediate on the ReShade side as opposed to running out of stack like SpecialK. I still need a 3DMigoto debug log, which would very clearly show if we are playing pass the parcel or not. |
|
EDIT: The crash was not reproduced in this log file 3DMigoto debug log: Edit: Log removed as irrelevant and to protect privacy At first glance this log looks okay - initialisation is fine, I see multiple frames being rendered, it doesn't end in a crash and it appears the DLL is was unloaded cleanly. Based on this, I don't think the crash was properly reproduced in this log. However I did notice something rather odd, just after this: and just before this: We see a lot of NULL bytes in the log covering bytes 0x3416221 through 0x3E26BD3 inclusive... That's over 10 megabytes of missing data in the log. I'm not sure what to make of that - it could of course be something mundane like filesystem corruption or a bad upload, but if it isn't... it's quite bizarre. |
|
Edit: This log does NOT reproduce the crash If that log does show the "crash", this is how it ended: |
|
Log from Helifax testing Resident Evil 2, 3DMigoto 1.3.14, ReShade 4.1, Windows 10 1809: https://cdn.discordapp.com/attachments/515704137795633154/541392344927174670/d3d11_log.txt Excerpt: I haven't looked at the rest of the log yet or tried to reproduce myself with RE2, but this looks like the clue we need. |
|
More log files of the issue from an affected DOAXVV user. When they name ReShade d3d11.dll it works, when they name it dxgi.dll it doesn't. They were unable to generate a 3DMigoto log file in with this - I'm not certain if they didn't have the two tools configured correctly to generate one of if 3DMigoto was never initialised (would possibly fit in with the theory that ReShade is bypassing the d3d11.dll in the game directory), but if I'm understanding correctly it sounds like the issue exists with ReShade when named dxgi.dll regardless of whether 3DMigoto is present or not - if so, that would indicate that this is a ReShade bug. Leaving this open until the issue(s) are resolved somewhere.
|
|
Looking at Helifax' log file in a bit more depth: CreateDevice looks okay. This is neither the device from DirectX, nor from 3DMigoto. Presumably this is something ReShade has wrapped. QueryInterface(IID_HackerDevice) failed, meaning one or more of several possibilities: This also means our backup lookup via IUnknown address also failed. And there's why - this is a fundamental violation of COM since QueryInterface(IUnknown) did not return a consistent address regardless of which interface it was called from, refer to: However, this is not entirely unexpected if ReShade wrapped the device as it is necessary to prevent certain games from unwrapping the device (and 3DMigoto also has this same violation), but in combination with the above issue prevents us from finding our HackerDevice. Presumably these are all the ReShade wrapper. These addresses do correspond to the DirectX device object, which we could potentially use to locate our HackerDevice object instead of IUnknown. If ReShade ever chose to start wrapping these as well we would be screwed for this method, but we could also implement a third backup strategy to find our HackerDevice with SetPrivateData (probably not SetPrivateDataInterface - the refcounting could get weird). |
|
I can reproduce the issue with Resident Evil 2 with much the same d3d11_log.txt as Helifax, however the dxgi.log I get differs from the samples provided for the DOAXVV case (in particular, the fail is prior to swap chain creation), so I suspect there may be two separate issues here. |
|
I added a check for violations of the COM identity rule, which as expected showed that ReShade is violating it, but unexpectedly it also showed the D3D11Device4/5 and Multithreaded interfaces violate it, and I very much doubt ReShade would have touched those - meaning that Microsoft has violated their own rule and we might run into this issue in the future if allowing more recent device interfaces (for now, this is just noteworthy): Note that since this query starts with a ReShade object those are listed as not violating and the DX interfaces are listed as violating since they are not consistent with the ReShade identity. The unexpected thing is that the device 4+ and Multithread interfaces resolved to a different identity than the other DX interfaces. |
|
Might be worth reporting that as a bug to Microsoft. They are pretty lame, but there is an off chance they would care enough to fix it. Assuming you are correct, that is actually kind of terrifying, because that means that internally Microsoft does not do any automated testing on this API. |
|
I've implemented a strategy to find our HackerDevice via Set/GetPrivateData on the DirectX device, which works - unfortunately it crashes immediately afterwards with this at the end of the d3d11_log.txt: And the dxgi.log reports this instead of exiting: The crash occurs when we call through to the original CreateSwapChain routine: This appears to have called into ReShade... I'm not entirely sure if that's what we expected because I don't know exactly how everything has managed to hook/wrap themselves in. Edit: This was just down to a bug in my code missed due to lack of type safety in SetPrivateData. |
|
Notably, there are reports of crashes with ReShade in Resident Evil 2 without 3DMigoto: |
|
I'm able to reproduce this with a ReShade built myself in Release configuration, however when building ReShade in debug configuration I get a different crash earlier on - again a NULL pointer dereference, but this time when ReShade attempts to call into the original CreateDeviceAndSwapChain: Call stack looks like this: Edit: This is somehow relates to the DirectX debug layer, which ReShade forces on in debug builds. While curious, this is getting side tracked from the issue at hand. Disabling the #ifdef _DEBUG in ReShade's d3d11.dll is sufficient to get past this. |
|
I've got the PrivateData strategy working and pushed a fix to master for the RE2 issue. This should also avoid any other issues where a violation of the COM identity rule interferes with our ability to find our HackerDevice. I'm leaving this issue open for the time being, until I hear back from some of the affected DOAXVV users since I'm not certain if that is the same issue or not. |
|
Just found this by accident. To clear some things up: ReShade's QueryInterface on a DXGI/D3D11 object can return two different ReShade objects:
Implementation is here: https://github.com/crosire/reshade/blob/2d179bd115591461b77613b7445772fcc5ee1c33/source/d3d11/d3d11_device.cpp#L54 By the way, you can check if a D3D11 device is hooked by ReShade by querying for this GUID: |
|
Thanks for the feedback. You wouldn't necessarily need to derive D3D11Device from DXGIDevice, but ideally you would choose one of them to be the returned as the COM identity whenever QueryInterface(IID_IUnknown) is called on either. Regardless we may still have to cope with potential violations if we are handed a newer version of the interface that isn't wrapped, such as the D3D11Device4/5 interface, so having this backup strategy of locating our device via Set/GetPrivateData is worthwhile I think. Going the other way, 3DMigoto also violates the COM identity rule as we dropped wrapping IDXGIDevice objects a while back (opting to hook the minimum functions we needed to get the swap chain instead) and therefore no longer intercept IDXGIDevice::QueryInterface. So far this hasn't caused us any issues, but it has the potential to - we should consider hooking the IDXGIDevice's QueryInterface so that we can redirect queries for D3D11Device[1] and IUnknown back to our HackerDevice. Likewise if you ever needed to check if a device object is wrapped or hooked by 3DMigoto you can query for |
|
We can probably close this now that 1.3.15, but I'll wait until I hear back from some of the DOAXVV users because I'm still not sure if that is the same issue or not. |
|
I'm closing this. There might still be an issue on DOAXVV for a minority of users, but as far as I can tell it's a problem with ReShade not loading when named dxgi.dll REGARDLESS of 3DMigoto, and the PEBKACs don't understand that when they remove 3DMigoto they remove 3DMigoto, nor can they follow simple instructions to enable proxy_d3d11. ReShade is fundamentally broken in DOAXVV anyway (breaks the news) so I don't damn well care anymore. |
Hello. i use 3dmigoto. luckily it helped me disable tsaa in a game. I want to use Reshade with this specific game at the same time as migoto . Problem is to get reshade to work in that game, i need to rename reshade dll to d3d11.dll. and 3DMigoto also used d3d11.dll. So i cant get them into the same folder because It dont let two dlls with the same name. i tried a few different ways to get this to work to no avail. Any help and advice you can give me would be thankful for DarkStarSword . I want to use 3DMigoto to disable the TSAA in the game, and then Reshade to polish up any aliasing left over from doing that. |
|
Try naming ReShade something else entirely and chain loading it via 3DMigoto's proxy_d3d11 option |
I guess im a bit too inexperienced. https://www.mtbs3d.com/phpBB/viewtopic.php?f=181&t=25451#top |
|
If that didn't work then try the loader method:
Troubleshooting:
|
|
To: DarkStarSword I got a configure issue with CMD pop up. I ran into this before and unsure what i did or didnt do yet to cause this . Update : Unsure how to set require_admin=true in the d3dx.ini ? this option appears missing in d3dx.ini . Do i have add a entry somewhere ? |
|
Okay i think getting close. forget to put exe game name in the loader entry. But . the issue is, the game has a launcher that has to trigger the game exe. if i start exe itself, as the loader appeared to have done, the game crashes, seems it needs the launcher exe which is in a folder or two back along the path. what to do in that case ?. edit - |
|
the game seems to only like d3d11.dll works without fail. But when its not present its like it dont exist. Unsure if im doing something wrong. Or the game just dont regard the loader . it wants a d3d11.dll. specially a dll in the main game folder. with the exe. |
The 3DMigoto loader should notice when the game itself launches and inject 3DMigoto. In the event that both the loader and game executables have the same name, but are in different directories, you can specify part of the path in the target setting. The template d3dx.ini has an example of this: The delay setting may also help if the game's executable spawns multiple times while launching, e.g. delay=20 will keep the loader open for 20 seconds after a confirmed injection in case any other instances of the game's executable show up during launch. You should set this long enough to get through the launcher, past any splash screens, etc until the game's window is visible full screen.
This is in the d3dx.ini shipped with 3DMigoto 1.3.16. If your d3dx.ini is based on template from a previous version it may be missing this option, but you can simply add it to the [Loader] section, provided that the 3DMigoto loader is a recent version (i.e. from the 3DMigoto 1.3.16 zip file). Alternatively you can just right click on the 3DMigoto loader -> run as administrator (the option only exists so you don't have to remember to manually run as admin every time for games that require it). For reference, the template d3dx.ini looks like this: |
|
Reading your post now . Thanks . |
|
Okay so i think i did it right this time just using the regular launcher , but this got a new error message that crashes the game before it loads |
|
from one of these pics here, https://imgur.com/a/eaXG3q6 i almost got it running i think. guess not . frustrating i cant figure this out yet. |
|
Star Citizen? Last I heard they were planning to switch their engine to Vulkan - if they do so and no longer provide a DX11 option 3DMigoto will be unusable in that game at that time (though considering their rate of development that could well be years away, if ever - just a caution that any modding on Star Citizen is very likely to break in the future). Looks like you have target and launch mixed up. Should be: |
|
Yes. May take them a long time as you noted ; for vulkan . Still I hope you guys can get it working on vulkcan too XD. |
|
To : DarkStarSword . Yet again the UI of 3DMigoto is not showing yet . Unsure what this means . |
|
Cool what is this ? new CMD. But still not appearing in game. reshade is there. Not 3dmigoto yet . |
|
was i supposed to fill out the proxy line with something ? i sent the ini file to your discord. i think thats you. 3D Vision. |
|
Reshade works fine for me named dxgi.dll, which allows the two tools to be used together. This is just using the stock template d3dx.ini with no modifications (no proxy dll, no loader settings), and 3DMigoto located within the game directory as d3d11.dll: All other methods of combining the two tools have hit one issue or another for me. I suggest you focus on trying to get ReShade working named dxgi.dll without 3DMigoto first, then add 3DMigoto to the mix. To answer your questions:
Usually means the game was run as admin and the 3DMigoto loader was not. This is what the require_admin=true option is for, though I'm not entirely sure why you would be hitting this since I've installed Star Citizen on my system and it does not require admin.
Seems the RSI Launcher is writing it's log to stdout which shows up in our launcher window if using the launch= option. Unexpected, but mostly harmless - it does mean the loader window won't close automatically since a second program is using it, and that you should leave it open while the game is running, then manually close it afterwards.
You have multiple target and module lines in your loader section - there should only be one of each. As noted above, I was only able to get 3DMigoto to work in this game when it is named d3d11.dll (regardless of being loaded from within the game directory or externally), however that prevents ReShade from using that name.
Yeah, that's me. Lately I've been using Discord for work so I'm not signed in to my personal account much and may not see messages there. |
|
Thanks for all the help. you have given me good information to use the loader if i need to. |
|
DarkStarSword - any clue as to why dxgi.dll is not displaying reshade UI like yours ? Mine used to work months ago. Has not worked since. inorder now for reshade to UI ro appear in game, i gotta rename it to d3d11.dll. but what changed that ? this is beyond my education- im just a video game player .Searching through forums ive seen others experience this through the years so far with no resolution . |
|
maybe its a order to load. Or dynamic link library , maybe a dependency was added or changed for the dxgi Maybe, its actually that reshade did install, but its UI is not using dxgi right to display . |
Hi guys,
3DMigoto version 1.2.73 is the last known good version where I can use both 3DMigoto (d3d11.dll) and Reshade (dxgi.dll).
(Default 3Dmigoto from zip file, default Reshade from Installer. Nothing was modified.)
Starting with 1.3.1, they no longer work together as any game crashes. (I tested on Vampyr in particular, but I saw it in other games as well).
This is very easy to reproduce as is 100% repro case. The crash always originatest in Reshade as it can't hook one of the DXGI factories.
If you want a reshade log + a 3DMigoto log please let me as I can easily get them, (You can also get them just by putting the dlls one next to the other and run a game)
The text was updated successfully, but these errors were encountered: