On compiling a visual basic assembly, int32 variables are cast as int64 for calls to adodb methods that require int32. This results in a method not found exceptions at run time. The unnecessary cast operation can be seen when using reflector to inspect the site of the method call and is not present in the source code.
To further muddy the waters when the code is compiled on my 64bit windows 7 machine all is well, but on a 64bit windows 2008 r2 the unnecessary cast is added.
Does any one know how to stop this happening?
Try compiling the app specifically for x86/32bit.
How do I force MSBuild to compile for 32-bit mode?
Related
As per Saving the XMM register before function call, it seems that XMM6 to XMM15 need to be preserved by function calls on Windows but don't need to be preserved on Linux.
I have a native plugin, compiled by Visual Studio 2015, for use in Unity, which uses Mono. The C# code passes a delegate down to the native plugin, which receives it as a function pointer (annotated stdcall for the sake of 32-bit builds, although the problem I have is with 64-bit ones). So, this means the native code can call a function which is implemented by Mono.
When I do this, the Mono function seems to be clobbering XMM6 to XMM15. The code compiled by Visual Studio obviously wasn't expecting this, and proceeds to malfunction.
Any ideas for ways to solve this? Is it possible to annotate specific function pointers so that Microsoft knows they behave wrong? Are there intrinsics we can call to save and restore those registers explicitly around any calls that we know have this problem? Other ideas?
Edit with further discoveries:
The registers are only clobbered the first time a given C# function is called. I've traced it to the Mono AMD64 general trampoline. This commit fixes the bug, but Unity uses an old version of Mono which still has it. The bug is that XMM0 to XMM7 are saved and restored using MOVSD, which only saves the lower 64 bits and resets the upper 64 bits to 0, while XMM8 to XMM15 are not saved at all, which may matter if something were to use them.
This seems to work for simple cases:
#include <immintrin.h>
alignas(16) std::array<uint8_t, 512> regs;
_fxsave64(regs.data());
callToMonoGoesHere();
_fxrstor64(regs.data());
Extra steps must be taken if the function returns a floating-point value:
alignas(16) std::array<uint8_t, 512> before, after;
_fxsave64(before.data());
float f = callToMonoGoesHere();
_fxsave64(after.data());
memcpy(after.data() + 256, before.data() + 256, 160); //XMM6 to 15
_fxrstor64(after.data());
I've been using ESENT for my projects quite extensively and I really love how easy and fast it works. And stable too!!
But I have a HUGE problem with Windows 8!!! Regardless of how I link to the esent.dll (dynamically or statically) whenever I call something other than JetSetSystemParameter, the dll is crashing, takig my app down the cliff.
Unfortunately I still can't get it running. My code had no problem running with Windows 7 or older. But with Windows 8 I get esent.dll crashing when I try to create an instance (floating point invalid operation).
I tried all possible calling conventions. This is definitely NOT the problem. I tried some more and discovered this weird situation: 1. I created a demo application using VS 2012 and JetCreateInstance worked just fine. 2. Exactly the same code in Delphi XE3 will send esent.dll crashing. 3. I created a DLL using VS 2012, exporting the method that worked perfectly in the above demo app, thinking it's a Delphi bug. 4. And then I loaded the DLL in a demo Delphi project (tried with 6, XE2 and XE3). Called the method and BOOM. Same crash.
Now my assumption is that Microsoft won't allow?!? any other developer environment to work correctly with the esent.dll. Is this possible???
The error, a floating point invalid operation, makes the problem sound as though it is related to the floating point control word.
By default Delphi unmasks floating point exceptions. So when code asks the floating point unit to perform operations that result in errors, the FPU signals which is then converted to an exception.
But most other Windows development environments mask these exceptions on the FPU. Such code is written under the assumption that the execution environment has FPU exceptions masked. But if you call a DLL from Delphi, the execution environment will have unmasked FPU exceptions, breaking that assumption. I suspect that if you mask FPU exceptions then your problems will disappear.
To test if this is the problem, you can simply add this to your code, executed early in its life:
Set8087CW($027F);
This will mask all exceptions and set the FPU control word to the default Windows setting.
In the longer term you may wish to mask exceptions before each call to this DLL, and then restore the FPU control word when the call to the DLL returns.
That is a slightly dangerous game using the libraries that are supplied with Delphi since Set8087CW is not threadsafe due to its use of the global variable Default8087CW. If you wish to read more about that issue, I refer you to QC#107411.
I've created a mixed DLL (C++/CLI) and after successfully calling it from a plain ANSI C application, I've moved on to calling it from a C++ COM server (using the same C entry points). However even before the COM server successfully starts or calls into the DLL I get a "access violation" in ntdll.dll. The call stack just has ntdll.dll!ExecuteHandler2 repeated multiple times to the point where a stack over flow is reported in the VS debug output. I can see my mixed mode DLL and mscoree.dll are loaded.
I added the mixed DLL to the delay loaded DLL options of the COM server and it appears to work.
Why does the mixed DLL need to be delay loaded in the C++ COM Server when the C application I wrote seems to work fine without delay loading? How do I go about debugging this problem (unless this is expected, however I couldn't find anything about it)?
Looks like a COM Appartment needs to be initialized. COM appartments are used to care of threads synchronization.
I am debugging the live process (not dump) of PresentationHost.exe. It used to works fine, but suddenly few days ago I get the above error message. !Threads, !pe, virtually all SOS command doesn't work.
All I remember is that I installed Visual Studio 2010 and .NET framework 4.0 before I'm getting that error. Is it related?
UPDATE:
I myself can not reproduce the problem I was having. Probably I was debugging 32 bit process with 64 bit debugger, or .NET 4 process with .NET 2.0 SOS, or vice versa, or combination of both bitness and DLL version.
Apologize that this question may not valid.
When are you trying to issue the command?
This error is quite common when attempting to issue SOS commands before the CLR was fully loaded.
You could attempt to break right after the CLR had finished its initialization procedure. In order to break at that point, you could place a breakpoint in the following manner: bp clr!EEStartup "gu". This will cause the debugger to break on the EEStartup function, and continue execution until the function completes.
When the debugger breaks on that breakpoint, you should be able to issue your SOS commands.
I'm reorganzing a legacy mixed (managed and unmanaged DLLs) application so that the main application segment is unmanaged MFC and that will call a C++ DLL compiled with /clr flag that will bridge the communication between the managed (C# DLLs) and unmanaged code. Unfortuantely, my changed have resulted in an Access violation that occurs before the application InitInstance() is called. This makes it very difficult to debug. The only information I get is the following stack trace.
> 64006108()
ntdll.dll!_ZwCreateMutant#16() + 0xc bytes
kernel32.dll!_CreateMutexW#12() + 0x7a bytes
So, here are some sceanrios I've tried.
- Turned on Exceptions->Win32 Exceptions->c0000005 Access Violation to break when Thrown. Still the most detail I get is from the above stack trace. I've tried the application with F10, but it fails before any breakpoints are hit and fails with the above stack trace.
- I've stubbed out the bridge DLL so that it only has one method that returns a bool and that method is coded to just return false (no C# code called).
bool DllPassthrough::IsFailed() { return false; }
If the stubbed out DLL is compiled with the /clr flag, the application fails. If it is compiled without the /clr flag, the application runs.
- I've created a stub MFC application using the Visual Studio wizard for multidocument applications and call DllPassthrough::IsFailed(). This succeeds even with the /clr flag used to compile the DLL.
- I've tried doing a manual LoadLibrary on winmm.lib as outlined in the following note Access violation when using c++/cli. The application still fails.
So, my questions are how to solve the problem? Any hints, strategies, or previous incidents. And, failing that, how can I get more information on what code segment or library is causing the access exception? If I try more involved workarounds like doing LoadLibrary calls, I'd like to narrow it to the failing libraries.
Thanks. BTW, we are using Visual Studio 2008 and the project is being built against the .NET 2.0 framework for the managed sections.
I believe I solve my problem. By systematically removing each library reference and
commenting out the calls to that particular library in the application code (unmanaged), I eventually removed the problem library and got the program to run. It's a brute force way of diagnosing the problem, and fortunately I didn't have to remove too many libraries to solve it. I'd still be curious if anyone has a comment if the library could have been identified though the debugger.
So, the next step is to move these library calls to managed code and pass the information back to the unmanaged side via my bridge DLL. BTW, I reintegrated the winmm.lib into the project and it still works.