When we shut down our engine with this:

	m_context->Release();
	m_engine->GarbageCollect();
	m_engine->ShutDownAndRelease();

I get a whole lot of these kind of messages:

[WRN] [11:20:48]  (0, 0) : ERR  : Object {7962}. GC cannot destroy an object of type 'array' as it can't see all references. Current ref count is 1.
[WRN] [11:20:48]  (0, 0) : ERR  : Object {7964}. GC cannot destroy an object of type 'array' as it can't see all references. Current ref count is 1.
[WRN] [11:20:48]  (0, 0) : ERR  : Object {7963}. GC cannot destroy an object of type 'SpriteWidget' as it can't see all references. Current ref count is -1.
[WRN] [11:20:48]  (0, 0) : ERR  : Object {7965}. GC cannot destroy an object of type 'array' as it can't see all references. Current ref count is 1.
[WRN] [11:20:48]  (0, 0) : ERR  : Object {7966}. GC cannot destroy an object of type 'RectWidget' as it can't see all references. Current ref count is -1.
[WRN] [11:20:48]  (0, 0) : ERR  : Object {7967}. GC cannot destroy an object of type 'array' as it can't see all references. Current ref count is 1.
[WRN] [11:20:48]  (0, 0) : ERR  : Object {7968}. GC cannot destroy an object of type 'array' as it can't see all references. Current ref count is 1.

What do they mean exactly? I'm a little confused at what "ref count is -1" means, as well as "ref count is 1"; where is it referenced? Is this a reference added by the program code when constructing these objects? Why does shutting down the engine not just get rid of everything?

These messages mean that you have some problem with the managing of the reference counting in your application. It looks like you have some cases where the references to the array object is not released properly (perhaps some global variable is still holding on to a reference?), and also some cases where the application code is releasing references it doesn't own resulting in the instances of SpriteWidget and RectWidget being destroyed too early. refCount == -1 is probably that the memory has already been freed and used for something else that just happens to be interpreted as -1.

You don't need to explicitly call GarbageCollect before ShutDownAndRelease. ShutDownAndRelease will attempt to get rid of everything. When it is not able to properly clean up the memory these messages are given to the application so the code can be fixed.

If you do not fix the code in your application you may experience memory leaks or even random crashes.

The number in "Object {7962}" refers to number of calls to asIScriptEngine::NotifyGarbageCollectorOfNewObject, i.e. 7962 means that the object instance with the problem was the 7962nd object to be included in the GC. If you can consistently reproduce the problem in each execution you should be able to use this to track down the origin of the object that is not properly freed by setting a breakpoint in the NotifyGarbageCollectorOfNewObject.

We have most of our memory issues fixed now. Thanks, this post helped! Also, related to this; it would be nice if messages like these:

[WRN] [16:51:14]  (0, 0) : INFO : The builtin type in previous message is named 'array'

Could show up with their type instead, for example:

[WRN] [16:51:14]  (0, 0) : INFO : The builtin type in previous message is named 'array'

I've modified as_module.cpp to achieve this myself for testing purposes:

asCString templateInstanceName = ot->GetName();
asUINT numSubTypes = ot->templateSubTypes.GetLength();
if (numSubTypes > 0)
{
	templateInstanceName += "<";
	for (asUINT i = 0; i < numSubTypes; i++)
	{
		asCDataType &dt = ot->templateSubTypes[i];
		templateInstanceName += dt.GetTypeInfo()->GetName();
		if (i < numSubTypes - 1)
			templateInstanceName += ", ";
	}
	templateInstanceName += ">";
}
msg.Format(TXT_PREV_TYPE_IS_NAMED_s, templateInstanceName.AddressOf());
engine->WriteMessage("", 0, 0, asMSGTYPE_INFORMATION, msg.AddressOf());

Thanks for the suggestion. I'll look into it.