It is the constructor of the global gCriticalSection that calls InitializeCriticalSection() on the member.[/quote]
Certainly, I mixed it up again with the struct CRITICAL_SECTION. Seems it's too late today already, I'm getting numb ;-)

I'll post again when I have news from the memory breakpoint.

When I set a breakpoint on EnterCriticalSection in my test bed I get the following values in the member criticalSection:[/quote]
Did you also try to enable the breakpoint only after the last line of the desctructor of asCScriptEngine has been reached:

asCThreadManager::Release();

Only in this case I got the strange values and the crash. All preceding calls go fine.

I think now I know what to look at a bit closer:
I've incorporated the AngelScript engine in a class that is a Singleton and which is itself statically allocated. During this classes' destructor the mpEngine->Release() call is made. I guess at this point the also statically allocated asCThreadCriticalSection object (gCriticalSection) is already dead... Simply a question of the order of destructor calls by the compiler, possibly. I'll look into this some more and probably may decide to call the Release() method somewhere else, i.e. earlier.

Regards,
Thomas

ah.

Do you by any chance keep the engine pointer in a singleton, i.e. a global object where the destructor of that object is the one that releases the engine? If that is so, it might be that the destructor of the global critical section has been called before the destructor of your singleton, which would explain why you get the crash.

We came to the same conclusion at the same time. I remember seeing this before in an earlier version of AngelScript where I had also allocated the thread manager globally, and the same kind of crashes happened for others who like you stored the engine in a singleton.

I'll have to find a way to avoid storing the critical section in the global memory. It has to be created with the first engine instance and destroyed with the last one. The problem will just be in how to do this in a multithreaded environment where multiple engines might get created at the same time.

I've removed the global criticalSection in revision 1293, it is now a member of the thread manager instead. You should no longer face the crash with this version.

For version 2.24.0 I'll add two new global functions to deal with the problem that led me to create the global criticalSection in the first place. These new global functions will only be required for those applications that uses multiple engines in multiple threads, so most projects will probably not even need to know about them.

Perfect, just tried out rev 1293 and the crash is gone.

Many thanks again for the great and super fast support!

Regards,
Thomas