Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Interop / February 2006

Tip: Looking for answers? Try searching our database.

Threads frozen when using CorBindToRuntimeEx

Thread view: 
Enable EMail Alerts  Start New Thread
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 Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.