If I recall correctly, the default deleter used by shared_ptr is just going to call standard delete. It will not call the delete that resides in the same module as the new that created the object. It will call the delete from the module in which the destructor is being compiled. And if your dll and your exe both have their own memory pools that they manage independently, this is where you'll encounter problems. In Visual Studio, if you compile with the option /MT (multi-threaded static runtime library), this is the situation you'll have.

There is a way to make the dll and exe share the same delete, however, and that is to use the shared runtime. This runtime is itself a dll, and both your exe and dll can dynamically link to a single instance of this dll, which means that news and deletes can interoperate between the exe and dll (or between two dlls).

To enable this, you'll need to use the /MD compiler flag, instead of /MT. I can't remember the exact settings panel it is in (VS isn't installed on my machine right now, going off of pictures from Google Images), but it looks to be C/C++ / Code Generation / Runtime Library / Multi-threaded DLL (/MD).

In some cases, it can ultimately be the right thing to create a solution where the shared_ptr (or something similar) can properly deallocate from anywhere, by storing at allocation time a stateful deallocator. Or alternatively to design a policy that avoids the issue altogether (e.g., ownership of a resource is never passed across module boundaries, only a non-owning reference). But in the basic case, using a shared runtime dll is easiest and perfectly fine. I'd recommend only going the more complicated route when you know precisely the reason in your particular case for doing so.

However, from what I've read std::shared_ptr can be used to avoid this problem as it contains a pointer to the deleter for the memory.

Agree with Sean. I probably undersold the idea of designing a clear ownership policy. Even if you're not dealing with cross-module issues, it's a good practice to always spend some time thinking about your program's ownership policy. A well understood and well chosen policy can make a whole host of problems go away, or not even appear to begin with.

About the unique_ptr, the compiler doesn't let me declare a std::list of unique_ptrs in the EventManager class.

This is just speculation, but it is possible that most of the events appear to get deleted fine due to implementation defined behavior of the runtime's allocator. For example, if every piece of allocated memory is part of a larger block that is predictably aligned, then on delete, the deallocator usually only needs to jump to the beginning of that memory's aligned block and fiddle with some book keeping information. This will work just fine even when technically using the wrong allocator, as long as the code is the same. But as soon as the deallocator notices that it freed the last piece of memory in a block, it might want to clean up the whole block. And to do this, it might need to check some other memory that is unique to that particular allocator (such as a list of memory blocks that the allocator is managing). If this block of memory wasn't actually allocated by the allocator currently doing the deallocation, things get confused really fast.

This might be the kind of thing that is happening when you delete the very last event. All deletes might be wrong, but the debug runtime only notices that fact on the last delete, when it tries to clean up a block.

Also keep in mind that your events are not the only thing being allocated and deallocated across dll boundaries. Every call to events.push_back() is going to use the default list allocator to allocate a linked list node, and every call to events.pop_front() will use that allocator to deallocate the node. But this is almost definitely a stateless static allocator. Since you statically link your event manager to both your exe and dll, the allocator used is going to depend on which module the calls to Queue() and HandleEvents() comes from. Calling Queue() from the dll is going to allocate from the dll, and calling HandleEvents() from the exe is going to deallocate from the exe. No amount of shared_ptr intelligence will protect against this, because this is completely independent of the memory allocated for events. Stateful allocators would solve this (at the cost of a little overhead), but have only been possible since C++11, and I'm not sure what VS2012's support of these is like.

Without stateful allocators, you pretty much need to figure out a way to guarantee that all manipulations to a container happen within a single module. In your case, you might actually try making your event manager library a dll also, instead of a static library. That way, all manipulations to the events list is guaranteed to happen within that dll, regardless of where the call to Queue() and HandleEvents() comes from.

This is the error message. It was caused by a call to EventManager's copy constructor, so no actual problem with list.
Error 1 error C2248: 'std::unique_ptr<_Ty>::unique_ptr' : cannot access private member declared in class 'std::unique_ptr<_Ty>' c:\program files (x86)\microsoft visual studio 11.0\vc\include\xmemory0 617 1 StaticLib