Well, I assumed you were using MFC because it's not uncommon to see this
issue at program exit time when managed code interops with C++ code that
uses MFC clases. Of course you can run into the same issue without using any
of the MFC classes.
This same exception is getting raised, when you call into managed code via a
COM interface or a managed delegate from the unmanaged DllMain while you are
processing DLL_PROCESS_DETACH, after the CLR has started shutting down. The
exception is an indication that executing managed code is no longer
possible.
Willy.
| MFC? I'm using standard C++ code; no MFC anywhere. Not sure where you get
| that impression..
|
| I'll have a go in the .vc newsgroup though.
|
| --Søren
|
| | > Søren,
| >
| > This doesn't relate to C#, you might get better answers when posting to
| > the
| > vc NG at "microsoft.public.dotnet.languages.vc" or/and
| > "microsoft.public.mfc.vc" as I have the impression you are using MFC in
| > your
| > unmanaged code.
| >
| > Willy.
| >
| > | > |I don't create or release the managed code from unmanaged code (not
| > unless
| > I
| > | misunderstand how managed c++ works, that is).
| > |
| > | What I'm doing is essentially this:
| > |
| > | In a managed C++ class' constructor I call upon an unmanaged
singleton's
| > | static Instance() member function. It doesn't matter whether the
actual
| > | object instance is created before or after the Instance() call in
| > managed
| > | code. I get the exception either way. If this is the first call to the
| > | singleton, an instance is created like this:
| > |
| > | // Make the run-time destroy the singleton automatically
| > | static T theInstance;
| > | m_psInstance = &theInstance;
| > |
| > | Oh, and I should probably note that the destructor of the singleton is
| > not
| > | called before the exception occurs. As far as I can tell from the code
| > where
| > | the debugger breaks, the exception occurs when cleaning up things
| > related
| > to
| > | atexit() (which should also cover the static 'theInstance' above).
| > | However, as I said above, if I call the singleton from purely managed
| > code
| > | BEFORE calling it from managed code, the exception still occurs. Hence
| > why
| > I
| > | find it odd if there should be any clean-up problems related to the
| > static
| > | instance (as it was created in unmanaged code space).
| > |
| > | If I call the singleton from unmanaged code only (and not managed),
the
| > | exception doesn't occur.
| > |
| > | I guess I'm a bit shaky when it comes to defining the boundary between
| > | unmanaged and managed c++. I mean, I'm using the "#pragma unmanaged"
and
| > | "#pragma managed" directives to specify which files are unmanaged and
| > | managed, but I'm unsure how this plays out in run-time when calling
| > classes,
| > | which were included as unmanaged, from managed c++.
| > |
| > | What an essay..
| > |
| > | | > | > Can you provide some sample code of how you create and release the
| > managed
| > | > code from the unmanaged code?
| > | >
| > | > That may provide some insights into why it's happening.
| > | >
| > | > Pete
| > | >
| > | > | > | >> Hi,
| > | >>
| > | >> I have a mixed C#, managed C++ and unmanaged C++ project.
| > | >>
| > | >> The managed class calls a method which exists in an unmanaged
| > singleton
| > | >> class. During the entire lifetime of the application, this gives no
| > | >> problems whatsoever. However, upon shutdown an exception pops up:
| > | >> "The string binding is invalid"
| > | >>
| > | >> If I call the singleton method from inside a purely unmanaged
class,
| > I
| > | >> receive no exceptions during shutdown. Access to the singleton
| > instance
| > | >> is achieved through a static member function in the unmanaged
class.
| > Is
| > | >> there anything special going on when calling static functions from
a
| > | >> managed class?
| > | >>
| > | >> It's a little hard to describe the problem thoroughly without
showing
| > the
| > | >> entire code (which is quite large), so please let me know of any
| > points
| > | >> you'd like me to elaborate on.
| > | >>
| > | >> I can provide stack traces etc. upon request.
| > | >>
| > | >> Thanks!
| > | >>
| > | >
| > | >
| > |
| > |
| >
| >
|
|
