Open ghost opened 8 years ago
heaths
commented
8 years ago The DllRegisterServer entry point should always have the same signature and, of course, is unlikely to change between your dev and build machines. It does lead me to wonder if your dev and build machines are using the exact same version of the .NET Framework, though (considering the major.minor.build version of .NET, as well as any updates available for said version).
ghost
commented
8 years ago I have tried rebuilding an independent machine that exactly mimicked my dev machine (i.e. same OS, Visual Studio, and WiX versions) and it still continues to fail.
I don't think the issue is around the function signature for DllRegisterServer but may have something to do with the calling conventions, as stated in the PInvokeException.
Looking at the WiX harvesting code, I don't believe it accounts for the various calling conventions on Windows, nor do I know how it'll be able to.
Are you able to reproduce the issue? Perhaps you can get a better understanding of the issue in your dev environment.
heaths
commented
8 years ago DllRegisterServer should always use a __stdcall calling convention. That is part of the signature. We could probably handle different calling conventions, but that the function isn't (perhaps) declared properly may lead to other problems.
Is your function declared as __stdcall?
jchoover
commented
8 years ago If the signature is invalid, I would expect regsvr32 to also have the same issue on the machine that heat is failing on.
It would be interesting to compare a dependency walker scan of regsvr32 on the dll between a good and based machine.
On Thursday, December 24, 2015, Heath Stewart notifications@github.com wrote:
DllRegisterServer should always use a __stdcall calling convention. That is part of the signature. We could probably handle different calling conventions, but that the function isn't (perhaps) declared properly may lead to other problems.
Is your function declared as __stdcall?
— Reply to this email directly or view it on GitHub https://github.com/wixtoolset/issues/issues/5127#issuecomment-167141359.
ghost
commented
8 years ago I don't know the calling convention for DllRegisterServer for msjava.dll; it's from a third party. We're using it in one of our products and no one here seems to know too much about it. I don't know if msjava.dll is open sourced or who the publisher is.
On Fri, Dec 25, 2015 at 6:50 AM, Heath Stewart notifications@github.com wrote:
DllRegisterServer should always use a __stdcall calling convention. That is part of the signature. We could probably handle different calling conventions, but that the function isn't (perhaps) declared properly may lead to other problems.
Is your function declared as __stdcall?
— Reply to this email directly or view it on GitHub https://github.com/wixtoolset/issues/issues/5127#issuecomment-167141359.
I have a COM DLL that causes heat.exe to crash. The COM dll is msjava.dll and can be downloaded from http://www.dll-found.com/msjava.dll_download.html. The version I used for testing is 5.0.3234.0 version but the error occurs with both.
The crash does not happen for all COM DLLs.
[System Environment] Heat commandline: heat.exe file msjava.dll -nologo -cg "temp.component.group" -dr INSTALLDIR -srd -suid -svb6 -out out.wxs OS: Windows 8.1, Windows Server 2008R2 WiX: 3.9.1208.0 Visual Studio 2012
When running the above command line on my dev machine, heat.exe does not crash; however, on our build it machine it does. Our build machine is largely identical to my dev machine.
I have built my own version of WiX 3.9 and stepped through in the debugger to find that harvesting is performed as expected (i.e. the output file generated) but when the heat.exe process is closing (after return statement), something causes the whole process to fail (manifest as a "WiX Toolset Harvester has stopped working" dialog.
Sometimes, but not always, I get a PInvokeStackImbalance exception, which is the best hint to date. This exception is thrown in DllHarvester.cs, line 75, when DllRegisterServer is invoked.
The exception details are:
Message: A call to PInvoke function 'wixTempAssembly!::DllRegisterServer' has unbalanced the stack. This is likely because the managed PInvoke signature does not match the unmanaged target signature. Check that the calling convention and parameters of the PInvoke signature match the target unmanaged signature.
CallStack: [Managed to Native Transition]
[Native to Managed Transition]