Page 2 of 2

Re: IRONCAD QueryInterface crash in CoCreateInstance.

PostPosted: Tue Oct 29, 2019 7:32 am
by kimjw0820
sorry. x86 does not cause any problems.
I was mistaken.

"There is a problem with IRONCAD and cannot be solved in MCH."
Is that correct?

Re: IRONCAD QueryInterface crash in CoCreateInstance.

PostPosted: Fri Nov 01, 2019 8:35 pm
by iconic
Yes, this is unrelated to MCH entirely. I've also tested 2 other API hooking libraries (my own) as well as another (DDetours - entirely open source). Same issue remains. I've not tested x86, only x64 where ICDraft.exe is a 64-bit process, this is what crashes for me here. The only logical explanation is that QueryInterface() is not implemented or implemented improperly by a DLL that ICDraft is loading, you can expose a method but not necessarily implement it, bad practice by the way. It's 3rd party and doesn't fall on Microsoft whatsoever, so it's isolated and solely the independent vendor's responsibility to implement methods properly according to COM contract standards and handle/catch any potential access violations. The issue here is certainly (x64) IronCAD and not any hooking library, you simply cannot call QueryInterface() *safely* without hacks, as I've said in my previous post. This is why an empty callback works (you only call the original function). In that moment it's already hooked, your callback gains execution control, and you can call the next hook (trampoline) just fine. That more or less rules out any hooking library related issues right there. I've tested this myself, it works fine for any/all hooking libraries I've tested

--Iconic

Re: IRONCAD QueryInterface crash in CoCreateInstance.

PostPosted: Thu Nov 07, 2019 1:29 am
by kimjw0820
Thank you for the quick response.
I was able to report the problem.

Have a nice day!!!

Re: IRONCAD QueryInterface crash in CoCreateInstance.

PostPosted: Thu Nov 07, 2019 7:46 pm
by iconic
:D No problem

--Iconic