I am working on a wxWidgets console application that I want to call into = a C# DLL from, via the CLR. Unfortunately, the application hiccups in the wxWidgets application initialization code because OleInitialize is failing. The error I'm seeing is a pop-up simply stating "Cannot initialize OLE."
It seems that this problem is usually avoided by setting the apartment style for threads by applying a directive to the application's entry point but I'm really struggling with what entry point I'm looking for. My C# code is a DLL: there's no specific entry point. The code compiled with /CLR exists in a .lib which is linked into my wxWidgets application. wxWidgets actually defines the WinMain in their code, and allows me to override behaviors via implementing wxApp.
Other suggestions include disabling OLE support in wxWidgets but In my release, 2.8.6, setting wxUSE_OLE, wxUSE_CLIPBOARD, wxUSE_DATAOBJ, wxUSE_DRAG_AND_DROP to 0 creates unresolved externals while compiling wxWidgets.
Has enjoy encountered this before and found an effective work around? Can anyone provide any clarification on what entry point I need to be modifying?
As mentioned in my question, this is a problem involving the thread style settings between the C++ application and the CLR defaults. This was apparently a bug, once upon a time, and Microsoft has released a fix:
http://msdn.microsoft.com/en-us/library/s6bz81ya.aspx
Recompiling the executable the uses the CLR-enabled .lib with /CLRTHREADATTRIBUTE:STA was sufficient to eliminate the errors I was seeing.
Related
I have a VS2017 MFC C++ application which uses a ribbon based UI. Up until now I have been using the statically linked MFC libraries but now have to move to MFC in a DLL as I need Multithreaded DLL linkage /MD in order to support another third party SDK (Vulkan). One of the reasons for using statically linked MFC is that it allowed me overcome some problems in the implementation simply by including the source for the item I needed to change in my application. e.g. to use data the edit part of a combo box to select the nearest item in the drop down. This doesn't work when I use the DLL version of MFC for obvious reasons, is there any way around this? I can't simply inherit from MFC base classes as my application is building the ribbon interface from a ribbon resource file and there don't seem to be any hooks to customise this behaviour.
My current thoughts for possibilities include building my own version of the MFC DLLs or simply adding the full MFC source as a sub-project and change my main project Use of MFC to Use Standard Windows Libraries. Both of these seem like nasty hacks.
Edit: In response to the comment below from IInspectable, I'm not entirely sure why the current behaviour doesn't work but have some ideas. Linking the static lib version of the code, if I include my own copy of a function that occurs in the lib, the lib version never gets called (possibly never even gets linked). When linking the DLL version of MFC, my modified function never gets called. This could be because it is called by another function in the same DLL which never sees my code or it has a slightly different decorated name. My thinking is that including all the MFC source in my app and not linking any MFC in the compiler options is one brute force solution, though a pretty horrible one.
I ended up recompiling a custom version of the MFC DLL based on this project, https://www.codeproject.com/Tips/5263509/Compile-MFC-Sources-with-Visual-Studio-2019 This lets me keep my MFC modifications while also using MFC in a DLL with minimal changes to my existing project
I am reproducing the following behavior in VS2008 (native C++):
attach to an executable that consumes a custom dll (for which I have the source)
debug the code from the dynamic lib
encounter an access violation error (probably caused by the code in the executable - closed source)
break on access violation error with the attached debugger
After this, no matter how many times I reattach, rebuild, restart the application, computer, any breakpoint I will set in the .dll source code becomes inactive (No executable code associated with this line is the alleged cause, according to VS).
I suspect this is an issue with VS2008, as I did the same on a different machine and now I have two machines where debugging is no longer possible.
Are there any recorded solutions of this issue? What can be done to overcome it?
What I have done:
deleting everything (the entire solution, pdbs, binaries, etc.) and starting with the code from scratch (cloning the latest version from the repository)
restarting the machine
changing the machine (it worked once, until the error occurred, then the other computer exhibited the same behavior)
What I cannot do:
change compiler/VS version
debug the executable (sadly no source code available and lack of assembly skills)
The root of the issue was more subtle. Although the project was intended to be native C++, I have found that on the configuration I was testing the code, the entire project was built with CLR support.
When attaching to the application the first time on any machine, in native debugging mode, the breakpoints would trigger. However, when encountering the native access violation error, these breakpoints became permanently inactive thereafter. After deciding to check what happens if I let the debugger attach in auto mode, I have discovered that the breakpoints became active and hence found out that all code had been compiled with the /clr flag except for the entrypoint in the consumed dll, which had no CLR support.
The question here is why VS2008 behaves like this and does not directly disable breakpoints whenever one attempts to debug a managed context using native debug settings.
TL;DR: check if your C++ project is built with CLR support and attach either as native or managed, depending on your needs. Alternatively, if only some of your files require C++-CLI usage, enable the /clr flag only for those. It is more often a better choice since C++-CLI often clashes with certain native libraries (e.g. not std::mutex support, linking against native static libs Linking unmanaged C++ DLL with managed C++ class library DLL, etc.).
I need to add Common Language Runtime Support (/clr) to my mfc dll project in order to use managed code in it.
I have do some setting for the all projects according to how to compile MFC and ATL Code By Using /clr from msdn.
I have done a lot of testing. But still failed to run my application although I only add the /clr support to the project without adding any managed code.
See below for details：
The exception, call stack, output information, the difference of output information and dependency dll between using and without using /clr please see Exception Detail
I can't get any useful information from call stack. I don't know even where to add the break point for debugging. Anyway, it's too later to add the break point at the InitInstance() of the application.
It seems the exception caused by loading dlls according the output information. But I don't know the really reason.
Otherwise I have downloaded a sample solution from msdn see Sample about Using /clr in MFC. The sample contains a mfc application calling a mfc dll with /clr support. And it works well. When I add my mfc dll(with /clr support) into this sample, it can work well too. I really don't down why it can't work in my solution. I have checked the property setting of my project compare with the sample solution. There seems nothing special.
I do need help, any suggestion?
Thank you all.
I have solved the issue by delaying loaded the dll that cotaines /clr support in the project calling it. See Set Delay Loaded DLL for how to delay dlls. It seems the exception caused by the chaotic unmanaged and managed initialization.
"Unmanaged and managed initialization is performed in two separate and distinct stages. Unmanaged initialization takes place first (via DllMain), and managed initialization takes place afterwards, through a .NET-supported construct called a .cctor. " See Initialization of Mixed Assemblies for details
For some reason the integrated debugger is causing an error as soon as I make reference to a third party vendor's dll class. This same code runs when it is built and ran as a release, stand alone. The two properties for debug and release should be the same as I have not really altered them. I added the lib file to the path for both builds. I simply have:
ClassNameFromDll blah;
When it gets to here, I get this exception:
Unhandled exception at 0x78a3f623 (mfc90ud.dll) in MTGO SO Bot.exe:
0xC0000005: Access violation reading location 0xf78e4568.
It occurs in: afxtls.cpp, line 252.
This is an MFC app, but I am not really using any MFC other than a very simple gui which fires off an event that is all win32. I am using Visual Studio 2008 Express.
Looking at the atltls.cpp file from my VC9 install, the crash is occurring here:
inline void* CThreadSlotData::GetThreadValue(int nSlot)
{
EnterCriticalSection(&m_sect);
ASSERT(nSlot != 0 && nSlot < m_nMax);
ASSERT(m_pSlotData != NULL);
ASSERT(m_pSlotData[nSlot].dwFlags & SLOT_USED); // <== crash
// ...
}
So the reason the crash doesn't occur in release build is because the ASSERT() is a no-op in that build. I'm not familiar with ATL's use of thread local storage, but this assertion indicates that something is asking for a value in a slot where nothing has been stored yet.
Whether the initialization of that TLS slot is your responsibility or the 3rd party DLL's responsibility, I don't know.
It looks like GetThreadValue() has some additional protections such that it'll return a NULL pointer in the release build for an uninitialized slot (though I'm not sure that this would be guaranteed) - I'd bet that the 3rd party DLL relies on that behavior (ie., it checks for a NULL return) so no crash occurs in release builds. Note that the vendor might be using the CThreadSlotData class indirectly (the stack trace would give a clue about this), so they might not be aware of its expectations.
engaging psychic debugging
The fact that it runs in release mode fine and crashes in debug mode leads me to believe that you've somehow managed to reference, specifically, the release version of that DLL (mfc90u.dll), rather than referencing the library itself and allowing the linker to decide which version to import.
You may not be using MFC for anything in this app, but if it's building as an MFC application, you will get all of the MFC stuff whether you want it or not (which means you also have to solve the MFC dependency problem and ship the MFC DLLs with your app).
Do you have a stack trace you can post? It might have some helpful information.
If the 3rd party DLL is still actively supported by the vendor, then the first thing you should do is see if you can have the same problem occur with a very simple program that you can send to the vendor and ask them to fix it.
If the vendor is not available or responsive enough:
If you have source of the 3rd party DLL and can easily build your own version, you have probably the best way to debug this (short of getting the vendor to support you). Even if you cannot easily build a source-debuggable DLL, you can trace into the constructor's assembly instructions and use the source as a map to help you understand what's going on.
Even if you don't have source for the 3rd party DLL then I think the best course of action is to trace through the constructor for ClassNameFromDll to try to figure out whats going wrong. It might help to compare the instructions path in the Debug build vs. the Release build.
MFC source is distributed with MSVC (probably not with the Express version, but I think with all other versions) so when you get in to the MFC DLL's code you might find the source to be useful in helping to figure out what's going on.
I have an MFC application that uses several MFC extension DLL's. I want this app (and several other similar apps) to be able to access some parts of the .net framework. I wrote a C# library to do the .net work I want and was hoping to be able to write an MFC dll to hide all the C++/CLI code from my apps. The apps would stay as pure MFC apps and the only C++/CLI code would be in my new MFX extension DLL. However when I did this the apps crashed when accessing the new MFC C++/CLI dll. If I put the C++/CLI code in the apps it works ok and I can debug my way all the way in to the C#.
Does anyone understand why the dll idea doesn't work?
Thanks
You can't reference managed assemblies from pure native code. You have to either flip the /clr switch on the consumer (either project-wide or in certain files,) or do some interop.
One interop option that will allow your consumer to say pure native is calling into the managed assembly via COM Callable Wrapper.
I believe I have run into a similar problem. My setup was similar - A pure MFC app with a pure MFC DLL which in turn interacted with the C++/CLI DLL. Everything would run fine, but it would crash on exit. The problem was exacerbated while testing the pure MFC DLL using CppUnit.
On debugging, I found out that due to a bug, my C++ code was throwing first-chance exceptions for access violations (objects referenced via a dangling pointer) on exit. Now, the C++ runtime ignores these violations on exit, whereas the CLR does not. The CLR runtime throws an unhandled exception making it appear that the program / unit-test crashed.
Your problem maybe different, but it does sound quite similar to the one I had.
The MFC dll project references the C# library and has one file compiled with /clr that handles the interface into my C# library. I have actually seen this work sometimes at run time but have never been able to debug into the MFC dll or into the C# code. However it doesn't seem to be at all stable and crashes in the majority of cases.