microsoft
"Rejecting IJW module" exception injecting into .net
When injecting any c++ dll via DetourCreateProcessWithDlls into a .net 2 executable that is configured with both .net 2 and .net 4 as supported runtimes, the clr throws exception code e0434352 (error "ERR: Rejecting IJW module built against v2.0.50727 because it could be loaded into another runtime in this process.") and the program terminates. The same exe will load just fine with detours if the useLegacyV2RuntimeActivationPolicy option is set to true in the .net exe's .config file. The clr function throwing the error and terminating the process is clr!PEFile::CheckForDisallowedInProcSxSLoadWorker and if that function is bypassed then the exe will load properly with detours. Other methods of injecting the same dll using createremotethread or queueapc do not cause any issue and the exe loads fine.
I assume the issue has to do with the IAT method of injecting the dll but I am having trouble pinpointing the exact reason or modification from detours causing the issue to see if it can be corrected.
This is easily reproduced with the detours withdll exe, simple32.dll and an appropriate .net app to inject into. I have attached a sample project. If you build it in release mode and run "withdll.exe /d:simple32.dll DotNetAppTest.exe" you should reproduce the crash.
you can try detours in my project to fix this problem, https://developercommunityapi.westus.cloudapp.azure.com/storage/temp/11277-filetracker-bug-fix-src.zip, I hope official will merge my modification to official repo.
you can try detours in my project to fix this problem,
I have built your version and it does appear to fix the issue. I cannot read the comments in your code, there appears to be an encoding issue. Would you mind explaining a little about what the issue with .net was and how you fixed it? It appears that detours was not adding all of the appropriate information to the modified import table, is that correct?
I was able to open up your changes with chinese encoding and translate your comments. I will test the changes more but it does seem like they should be a welcome contribution to the trunk provided there are no issues.
Hi. I'm seeing the same issue. The link posted by sonyps5201314 no longer works. Can anyone point me at the zip file or the code change that needs to be made?
Lucky for you I'm a hoarder :P found it still in my downloads folder and uploaded to dropbox https://www.dropbox.com/s/ko4wrjclmklfyrr/11277-filetracker-bug-fix-src.zip?dl=1 The modifications have been running on hundreds of thousands of endpoints with no issues and the problem resolved. Why nobody is merging these fixes into the repository is beyond me.
Thanks for that. I notice that there are multiple changes and comments are all in Chinese. Would you know which of the changes fixed the "Rejecting IJW module" exception for .Net 2 executable that is configured with both .Net 2 and .nNet 4 as supported runtimes?
@rob191, @sonyps5201314 if would you send a PR we would be happy to work on getting it merged. As far as I can tell a PR was never submitted, and hence we don't know anything about these private fixes. :)
11277-filetracker-bug-fix-src.zip
Adding ZIP directly here, to account for potential Dropbox link death.
Uh I don't think I, or anyone should touch that zip with a 10 foot pole :) I hope @sonyps5201314, as the assumed original author of the changes, would be willing to submit a patch, as that's the only valid way to accept those changes.
Was just mirroring it before it vanished for visitors, no action needed on your part. The ZIP has no executable images. Agree without @sonyps5201314 there are some unresolved legal issues.
Ok, I will publish my Detours modified version to github.com, but the code comments in my repo use chinese, you can recomment to english after merge.
Uh I don't think I, or anyone should touch that zip with a 10 foot pole :) I hope @sonyps5201314, as the assumed original author of the changes, would be willing to submit a patch, as that's the only valid way to accept those changes.
I have submited now, please merge it as you said😁, thanks. follow is the patch file: https://github.com/microsoft/Detours/pull/127/commits/10247b1201311914b8300b97544217c892165325
I believe PR #104 - Improved 32bit detection by @frerich which was just merged to master should fix this? Can you test @rob191?
@bgianfo
Believe? What makes you believe?
Microsoft merge code only by guest and analysis, and not by test by self?
This is the reason Windows 10 have so many bug after publish?
That's the answer you don't want to see.
@bgianfo Believe? What makes you believe?
I read the description of this issue, and it sounded related to the fix I had just merged, that's all.
Microsoft merge code only by guest and analysis, and not by test by self?
I personally don't download zip files from folks I don't personally know off the internet, extract them and execute them on my machine. I would recommend you don't either, out of an abundance of caution.
I would prefer all bug reproductions be source code only, this issue didn't include source and only a binary, so I asked the original filer of the issue to test them selves.
This is the reason Windows 10 have so many bug after publish?
Please make sure you follow the repository Code of Conduct when contributing to the Detours project. The aggression and snark is unnecessary, I work on detours for fun as a side project, I have a different day job, please don't make me regret spending my free time contributing to this community.
That's the answer you don't want to see.
I don't mind being proven wrong. Thanks for testing and confirming it doesn't fix the issue, and linking your suggested bug fix.
@bgianfo , sorry about my high spirits, because I wait for your team to merge #127 so many days, and I have seen many PRs have be merged, even post after my PR. I don't really like open source myself owned code , but in case the official Detours project version and the personal version which is my maintaining went to branch roads, and some official unresolved issues, and community requests required, I decided to open source my own version.
I completely agree with the frustration. Our company paid $10k to
use this product and it has been buggy all along. Support from
Microsoft while they still owned the project was non existent and
then it moved to open source of course with no refund of the $10k.
I work for a company with detours deployed on somewhere around 1/2
million endpoints. sonyps5201314 gracefully responded to an issue
that was impacting our customers for over a year and provided a fix
that's now been in production since and I greatly appreciate his
contribution, thank you so much. If you're scared of a zip file you
shouldn't be in the computer business. I've had the fix in place
for years and didn't want to bend over backwards to hand it over in
the proper way or care much to mess with this any longer because
when the issue was being discussed, there was absolutely no interest
in the team maintaining detours so why she we bother now? Just my 2
cents that you also probably didn't want to hear.
On 9/4/2020 10:43 PM, sonyps5201314
wrote:
@bgianfo
, sorry about my high spirits, because I wait for your team to
merge #127 so many days, and I have seen
many PR have be merged, even post after my RP.
I don't really like open source myself owned code , but in case
the official Detours project and the proprietary version I was
maintaining went astray, and some official unresolved issues,
and community requests required, I decided to open source my own
version.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
[
{ "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/microsoft/Detours/issues/54#issuecomment-687532865", "url": "https://github.com/microsoft/Detours/issues/54#issuecomment-687532865", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]
@rob191, Thank you for your support and understanding. This problem is indeed difficult to fix. I also recorded and tracked this problem for a long time. In order to completely solve it, it took seven or eight months to track it in stages. Inside ntdll and .net clr, I also looked at a lot of reference codes, including the clr runtime code of the open source .net core, and finally determined the ultimate fix. This problem has been officially shelved for so long. To me, it doesn’t seem to be very strange, because I have reported many problems to the visual studio 2017 developer community before, but they are all very slow to solve, and they have to be shelved for a long time. For more than a year, I even submitted a repair plan to them. They did not believe or could not understand the problem I said, and remained highly skeptical about the problem I said, so I didn’t bother to give the official feedback on the problem later, and would rather use the old version VS, at least it can guarantee stability.
The picture below shows my modification record of the version of Detours that I maintain, and the circled ones are related to the .net program. It took seven or eight months, after several versions, to finally have the merged version in the link I posted earlier. At that time, the link was also to solve a problem for visual studio 2017, but the official did not trust it. It was not solved until more than a year later, when the official estimated that it also encountered this problem.
