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.
Related
I have a web application, using Spring-Boot. There is now a need for this application to use a custom dll (in house build dll file). There is nothing wrong with this dll, as we use it on our other applications, and have no problems with it.
To load the library in this new web application I'm writing, I have added the dll file to the procrun directory. This directory is on the library path, so that makes sense.
During startup I put in code to immediately load the dll, and also test some of its functionality. This works fine.
However, I have a timer, that schedules the execution of some functions, which may or may not include function calls to the dll.
At some point, about 10 minutes or so into execution, the service unexpected and seemingly without any valid reason, stops.
Although I try/catch exceptions at the appropriate logical places in code, there are no relevant log entries printed.
The Event Log shows something that reminds me of a null pointer exception:
Another bread crumb is that the event log will print something about the dll_unload. (see picture)
I need some help figuring out why the service is failing/stopping.
Kind Regards.
EDIT: After about three days of debugging and scratching my head, I came upon a forum thread that explained that this problem has something to do with the manner in which the system releases the memory during garbage collection. It seems that the dll in question was being unloaded by the garbage collector, even though it could still be called at some time later - which of course was the cause of the service falling over.
To solve the problem, I put in a timer that would call a method in the dll at three minute intervals (on my system this would not impact performance). I know this solution is a hack, but it works for me.
Recently I've been working on an external .exe to communicate with AutoCAD. Since it was an outside .EXE I had to work with the COM to get what I wanted. (Else I could've used the .NET API which is (in my opinion) much better).
In any case, I keep getting COM Interop errors (Call was rejected by Callee) and I'm having a lot of trouble dealing with it. I could use timers but sometimes it will over wait, or under wait for a particular situation. Also, this isn't the best solution if I have to use a slower computer.
Microsoft's solution:
Add the following class to your application.
Add a reference to "Microsoft Development Environment 8.0." This
adds references to EnvDTE and EnvDTE80 to your solution.
Add a reference to System.Windows.Forms.
In the code, create an instance of EnvDTE80, as outlined in the
following example.
Call Message.Register to handle thread errors.
Call your automation code as usual.
When your automation code is finished, call Message.Revoke to remove
the thread error handlers.
http://msdn.microsoft.com/en-us/library/vstudio/ms228772(v=vs.100).aspx
Importing
In order to use the error management code (once the class is added) we will need to add an import such as:
Imports WindowsApplication1.ConsoleApplication2
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'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.
In short: I want to monitor selected calls from an application to a DLL.
We have an old VB6 application for which we lost the source code (the company wasn't using source control back then..). This application uses a 3rd party DLL.
I want to use this DLL in a new C++ application. Unfortunately the DLL API is only partially documented, so I don't know how to call some functions. I do have the functions signature.
Since the VB6 application uses this DLL, I want to see how it calls several functions. So far I've tried or looked at -
APIHijack - requires me to write C++ code for each function. Since I only need to log the values, it seems like an overkill.
EasyHook - same as 1, but allows writing in the code in .NET language.
OllyDbg with uHooker - I still have to write code for each function, this time in Python. Also, I have to do many conversions in Python using the struct module, since most functions pass values using pointers.
Since I only need to log functions parameters I want a simple solution. Is there any automated tool, for which I could tell which functions to monitor and their signature, and then get a detailed log file?
A "static" solution (in the sense it can capture a stack trace on demand) would be Process Monitor.
A more dynamic solution would be ApiMonitor, but it may be too old to be compatible with the applications to monitor. Worth a try though.
Some more Google searching found what I was looking for: WinAPIOverride32. It allows writing text files such as:
CustomApi.dll|void NameOfFunction(long param1, double& param2);
Later on, these files can be used inside the program to log all calls to NameOfFunction. Now I just need to figure out how to log arrays and structs parameters.
Visual Studio Addin Runtime Flow here:
Runtime Flow in real time monitors and logs function calls and
function parameters in your running .NET application and shows a stack
trace tree. No instrumentation or source code required for monitoring.
If you just want to see the function interfaces of the DLL, you could try "Dependecies" (https://lucasg.github.io/Dependencies/). This is a nice remake of the DependencyWalker in as OpenSource.
This only allows you to see the dependencies of the DLL, with the corresponding function names (however, not the calling structure). Unfortunately, I don't believe it will tell you which specific functions in a DLL are being used by the calling DLL/EXE.