.NET Forum / .NET Framework / Interop / February 2006
Threads frozen when using CorBindToRuntimeEx
|
|
Thread rating:  |
dnebeker - 23 Feb 2006 16:33 GMT Sorry, this one is complicated.
I have a normal (completely non-Managed C) C++ app that uses MFC. This app calls: CorBindToRuntimeEx(L"v1.1.4322", NULL, STARTUP_LOADER_OPTIMIZATION_SINGLE_DOMAIN, CLSID_CorRuntimeHost, IID_ICorRuntimeHost, &ppv);
Once started, it does a LoadLibrary on two _managed C++_ DLLs. I completed all of the steps in "Converting Managed Extensions for C++ Projects from Pure Intermediate Language to Mixed Mode" (ms-help://MS.VSCC.2003/MS.MSDNQTR.2005OCT.1033/vcmex/html/vcconConvertingManagedExtensionsForCProjectsFromPureIntermediateLanguageToMixedMode.htm)
which is basically a technique for getting global/static variables (which MFC uses) initialized.
The managed C++ DLLs in turn uses other .NET components.
Sometime after loading the managed C++ DLLs, newly created threads freeze. I can see that they are created, but they are stuck waiting on some internal object.
At first, I had each managed C++ DLL getting loaded and initialized in a separate thread. Doing them both from the same thread (the thread that calls CorBindToRuntimeEx) got it working in more situations. However, if I only load one of the managed C++ DLLs, then the problem does not occur.
The problem seems to be worst on Windows 2003 Enterprise servers with SP1.
Any ideas???? I'm guessing .NET is somehow finding out about thread creation and doing some sort of marking/apartment/whatever stuff here, but not sure.
Thanks for ANY ideas.
Doug
dnebeker - 23 Feb 2006 16:46 GMT > Sorry, this one is complicated. > [quoted text clipped - 32 lines] > > Doug One other note: I have a fresh install of Windows 2003 Enterprise SP1 with all patches from Windows Update. When I first run the program after installing, the thread that calls CorBindToRuntimeEx doesn't return (it is in a call something like 'CorMarkThreadinThreadPool'). However, if I stop the app and run it a second time, it works. Some sort of pre-compile/caching going on? Or just a race condition and I'm getting lucky? Final note: the main C++/MFC app is a service running as Local System.
dnebeker - 23 Feb 2006 22:35 GMT > > Sorry, this one is complicated. > > [quoted text clipped - 40 lines] > going on? Or just a race condition and I'm getting lucky? Final note: the > main C++/MFC app is a service running as Local System. Additional info:
There are two scenarios that happen consistently: 1. When I do the fresh install, the thread that calls CorBindToRuntimeEx is now freezing (I've adding calls to CoInitialize and been trying different things that shouldn't have an effect). The stack trace is: ntoskrnl.exe+0x207bc ntoskrnl.exe+0x1d071 ntoskrnl.exe+0x115ed9 ntoskrnl.exe+0x115d5d ntoskrnl.exe+0x2337b ntdll.dll!KiFastSystemCallRet !CorMarkThreadInThreadPool+0x2986 !CorMarkThreadInThreadPool+0x2ee7 !ReleaseFusionInterfaces+0x14d4c !GetCompileInfo+0x12e2b !Ordinal17+0x27d8e
2. If I go in and remove one of the two managed C++ apps, restart the app, then it comes up fine (no frozen threads). I can then put the managed C++ DLL back, start it up, and everything works fine.
"Peter Huang" [MSFT] - 24 Feb 2006 09:40 GMT Dear Customer,
From you description, I understand that you want to HostCLR yourself and run the managed code by calling the CorBindToRuntimeEx.
If I misunderstood, please feel free to let me know.
To isolate the problem, I think you may try to run the samples below to see if the managed dlls run OK in the Sample.
Microsoft .NET: Implement a Custom Common Language Runtime Host for Your Managed App http://msdn.microsoft.com/msdnmag/issues/01/03/clr/
Creating a host application for the .NET Common Language Runtime. http://www.codeproject.com/dotnet/simpleclrhost.asp
Based on my experience, a problem as complex as this may take extensive time to narrow down. If the issue is urgent, you may want to work with Microsoft Customer Service and Support (CSS) for a faster resolution. Once you open a Support incident with Microsoft CSS, a dedicated Support Professional can work with you in a more efficient manner.
http://support.microsoft.com
Thanks for your understanding!
Peter Huang Microsoft Online Partner Support
 Signature Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
dnebeker - 25 Feb 2006 21:37 GMT Thanks for your attention Peter. I don't necessarily want to host the CLR--I just want to run some managed code from an unmanaged app.
From doing lots of research for the past three days, it looks like this could be the infamous mixed-mode DLL deadlock on .NET 1.1, since both of my managed C++ DLLs were mixed mode (used CRT and some MFC/ATL). I took some time and rewrote both DLLs so they are completely managed now--no linking with any runtime libraries. I confirmed by loading them into dependency walker and they both only depend on mscoree.dll.
I've tried both doing just LoadLibrary on the DLLs (IJW right?) and also calling CorBindToRuntimeEx first. In both cases, the very first time I run the app, the DLLs are loaded and everything works perfectly. Every time after that (including after reboots) the app hangs after loading the second DLL (I can switch which is loaded first and second and it doesn't matter, the second DLL loaded hangs). Thanks heavens for Virtual PC which makes going back to a previous image easy!
I've tried this with .NET 1.1 SP1 and the exact same issue occurs. This is 100% reproducible on Windows 2003 Enterprise (without Win2003 SP1 so far, will try loading that up).
I'm also VERY surprised Microsoft has so many documents talking about how to enable mixed-mode DLLs--that's a death sentance for your project!
I'm also completely stumped why I get this freeze when I'm no longer mixed-mode. I've tried dozens of permutations of loading the DLLs in different orders, loading them from different threads, pumping messages, etc. Is there anything that could unlock the loader lock? Why does it always happen on the second DLL? Why does it work the first time and fail on every subsequent attempt (I think that is a big clue--is the assembly cached somewhere??)
Thanks for anyone's input, guesses or otherwise!
Doug
> Dear Customer, > [quoted text clipped - 28 lines] > Get Secure! - www.microsoft.com/security > This posting is provided "AS IS" with no warranties, and confers no rights. "Peter Huang" [MSFT] - 27 Feb 2006 09:53 GMT Hi Doug,
Commonly for a pure managed C++ application, we do not need to call CorBindToRuntimeEx explictily. IJW means It just works. That is to say, in the Managed C++, we do not need to use DLLImport delare(such as C#,VB.NET) to call a API. What we need to do is #include the header file and just call it just as we are in the unmanaged C++.
e.g. #include "stdafx.h" #include <windows.h> #using <mscorlib.dll> using namespace System; int _tmain() { MessageBox(NULL,"ADF","fasdf",0); Console::WriteLine(S"Hello World"); return 0; }
From your description, it seems that you call the CorBindToRuntimeEx directory and then load the managed library into the runtime. That is why I think you are hosting CLR on your own. So I suggest you try the clrhost code. You may look into the two links about clr hosting in my previous link.
Also for your scenario, I think your assumption may be correct. Also from your description, it seems that you have made your two DLLs pure managed code and the problem persists. So it is hard to troubleshoot and confirm in the newsgroup support. Because we need to do dump analysis to see where the dead lock occurred and why and how the deadlock occurred. So I recommend you contact MSPSS directly http://support.microsoft.com
Here are some mixed mode articles for your reference. Mixed DLL Loading Problem http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechar t/html/vcconMixedDLLLoadingProblem.asp The Mixed DLL Loading Problem http://www.codeguru.com/columns/kate/article.php/c3643/ Changes for Microsoft Visual C++ in Microsoft Visual Studio .NET 2003 http://support.microsoft.com/default.aspx?scid=%2Fservicedesks%2Fwebcasts%2F en%2Ftranscripts%2Fwct032003.asp
BTW: if MSPSS confirmed this is a problem in our product, the incident fee will be refund.
Thanks for your understanding!
Best regards,
Peter Huang Microsoft Online Partner Support
 Signature Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|