Sign in to follow this  
holdenp

Direct3D hangs on device release

Recommended Posts

I am having a problem with my application process not closing when the HAL device is released. The execution gets stuck when IUnknown::Release is called for the device specifically in the Destroy method of the CD3DHAL object when it tries to delete wmt_pvfuncs. This code is within the d3d9.dll which I traced through the assembler code. I am using the November 2007 Directx SDK and running the debug runtime. I have used the Directx control panel and edited the registry directly and found that the problem can be toggled on/off using the HKLM\Software\Microsoft\Direct3D\FullDebug key which is one of the keys set by the Directx control panel utility. On another machine I used the control panel to fix the problem but then couldn't unfix it. I need to find out why this is occurring so that the bug does not reappear. Any ideas anyone? Do you know what the FullDebug key does and why it would send the execution down a different path in the dll?

Share this post


Link to post
Share on other sites
This has something to do with the component object model but I don't know what it is all about..

Anyway, you need to release the COM-objects in the correct order. The first object that is created must be released last. Don't release the device before you have released every texture and so on. And make sure you really have released everything before you release the device (textures, vertex and index buffers, device stage, device data stream etc.)

// CreateDevice
// CreateTexture

Texture->Release();
Device->Release();

I couldn't find any reference to this topic, when I find some i will post it

I hope this helps, it worked for me when I had the same problem...

Share this post


Link to post
Share on other sites
I'd attach WinDbg to it and use !locks to see what the lock contention is on. Seems like deleting wmt_pvfuncs, whatever that is, acquires some kind of lock. If you had a callstack for the thing that was holding the lock, it might help you figure out how to diagnose it.

Did you create d3d to be multithreaded by any chance? No idea if this is related, just brainstorming.

Share this post


Link to post
Share on other sites
Probably not the cause but still:

Do not release the device inside a window message handler. It's safer to do that outside in the main loop, not while you're inside your Window Proc.

Share this post


Link to post
Share on other sites
Thanks for your replies - I have had nothing from Microsoft - no surprise there.

I am releasing the devices in the correct order, tried both just to be sure. they are being released in the same thread as they are created. Tried the disconnect to make sure the COM was disconnected and all ok.

It is multithreaded and has to be that way. The device creation is:

m_pDirect3D->CreateDevice(i, D3DDEVTYPE_HAL, ::GetDesktopWindow(),
(D3DCREATE_MULTITHREADED | D3DCREATE_FPU_PRESERVE|D3DCREATE_SOFTWARE_VERTEXPROCESSING),
&d3dpp, &pDevice);

I found the d3d9.pdb file for windows xp sp2 and used it to debug inside the dll. So far I have found the connection between the FullDebug key and why it might make the problem go away.

If the FullDebug is unset then when the device is created in the CBaseDevice::Init function, an extra thread is created called wmt_CSSEShaderCode::ProcessPositionAndColors. On a working or a non-working machine, by the time the device is to be released this thread has already gone.

Not sure why it has this shader code as I am not using shaders to my knowledge. There may be other initialisation of the device that changes when the FullDebug is set so I am looking into that next.


Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this