[UPDATED with new discoveries] Hi everyone! :) I'm currently doing the multiplayer code in a game.. and I'm trying to initialize a DirectPlay8Server interface and then a DirectPlay8Client interface in the same application, but it isn't working. If I start only the server and start hosting and then shutdown everything works OK. If I start only the client I can also shut it create it and shut it down properly. Debug output from dplay doesn't give me any suspicious errors or anything. If I create an exe with only the server running and one with only the client running I can succesfully connect to the server and communicate with it. Everything works fine. But if I try to create the server and the client at the same time in the same exe, everything seems to work, but when I try to release the last interface everything crashes with a memory leak. If i release the client first, and the server later then it crashes in the server->release(). If i release the server first and the client later it crashes at client->release(). So the order in which I init and release the client and the server doesn't matter. Both interfaces are encapsulated inside two classes and cannot access each other and alter each other's data. And this happens when I create and destroy the interfaces without hosting and connecting... [update] Just found out that if I create the server and the client, start hosting on the server and then immediately stop hosting and release both interfaces it doesn't crash. It seems as though it crashes when I let the update run (which does nothing on my part) - just an empty event handler for DPlay and that's it. Anybody got any ideas? Are there any known conflicts when running both the client and the server from the same app? My delete procedure is as follows: - stop the server/disconnect client - cancelasyncoperation (all) - interface->release() PS: I've found no samples whatsoever doing a listen server with directplay. [Edited by - klajntib on August 4, 2004 3:20:19 PM]

Hmm, i'll check it, but all mi CoInitializeEx and CoUninitialize calls are done in constructors and destructors, so all inits should have their respective uninits. :) Hopefully :P

OMG!
EAX screwed my DirectPlay! Seriously!

I used CoInitializeEx( NULL , COINIT_MULTITHREADED ) to initialize COM since it says in the documentation that using the singlethreaded CoInitialize( NULL ) with DirectPlay could cause "serious race conditions". Can anyone translate this?

The unfortunate thing is that EAX screws up when using the multithreaded version so i'm now using the single threaded version and hope that DirectPlay won't have any problems.

Yeah.. EAX (Creative's Environmental Audio Extensions). We are using EAX through DirectSound. At first we were creating DirectSound with EAXDirectSound8Create instead of just using DirectSound8Create. This worked fine with the single threaded COM model. But DirectPlay prefered the multithreaded COM model and when I changed that it somehow screws up EAXDirectSound8Create and causes and access violation on shutdown. Createing EAX with CoCreateInstance fails when using multithreaded COM, but works when using singlethreaded COM.

So EAXDirectSound8Create somehow managed to screw things up. I'm using singlethreaded COM now and just hope that it doesn't fook up DirectPlay :)