Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have a mixed .NET application (managed and unmanaged code bridged by C++/CLI wrappers) which uses unmanaged Direct3D9 9.0c to do rendering inside a control which is wrapped inside a C++/CLI class which extends System.WIndows.Forns.UserControl.

Everything has been working fine for years now, but I recently put another instance of this Direct3D9 control inside a new Windows Form. That is, I have two concurrent instances of the control. I had done that before and it worked, but now I have issues. Perhaps the problem was always there, but because it's related to a race condition, it started happening now...

Ok, the details: When I try to render an image over a texture on the new instance of the control, sometimes it works, sometimes it doesn't. And when it doesn't, nothing is rendered, and from that point onwards, all Present calls fail (I log those failures). If I close the form and open it again, it might work or not. Nasty.

If I use DXGetErrorString and DXGetErrorDescription, all I get is something like:

EFAILED Undetermined error

Not really helpful... To make matters worse, I can't reproduce the issue in my development environment; I only see it in a production box.

As far as I know, the main reason Present fails like this is a Lost Device. But I implemented the usual scheme to handle that (I can post the code if necessary), and it seems like the device is not being lost... What else can I try?

share|improve this question
    
My experience of the D3D errors was very bad too. –  DeadMG Apr 26 '12 at 15:06
    
I've been researching, and it seems that, asides from Lost Device, Present can fail if some other D3D api call failed before. He doesn't know the exact error because it happened in some other stage of the pipeline and is not available. Anyway, if I could only see the Debug Runtime error messages in the production box, I might get more meaningful errors. Is there a way to do that? –  dario_ramos Apr 26 '12 at 15:12
1  
I suggest switching to the debug libraries using the DirectX Control Panel, with full verbosity, then capturing the D3D stream using PIX for Windows. I recently had Present() fail with absolutely no error message, because I was using CreateTexture with D3DPOOL_SYSTEMMEM, but that function was still returning S_OK. PIX and the debug library helped find the problem. –  Sam Hocevar Apr 26 '12 at 17:30
    
Sounds good. Can that be done without installing anything on the client's box? (with a portable version of PIX, for instance). As a last resort, I can install and uninstall the debugging tools, but I should avoid that. –  dario_ramos Apr 26 '12 at 17:45
    
I'm afraid I don't think it's possible. I would not advise deliberately crippling the debugging environment anyway; the DirectX SDK is only one (admittedly large) package to install, and can be uninstalled from the Control Panel. –  Sam Hocevar Apr 27 '12 at 9:25
add comment

1 Answer 1

up vote 1 down vote accepted

You will likely get your answer by viewing debug output.

Really, it's like a whole set of documentation there, embedded right in the debug spew. Run in debug mode and view the output in Visual Studio, or use a program like DebugView to see the messages. Be sure to enable the D3D9 debug runtime as the diagrams show in the linked answer above.

share|improve this answer
    
We changed a call to GetWindowRect by GetCLientRect when computing the viewport dimensions, and the error, apparently, has stopped happening. If it happens again, first we'll try updating the graphic card drivers. Should that fail, we'll look at the debug output. I should mention that we came up with this idea (using GetClientRect) when we checked the differences between the svn trunk and the svn branch versions of the app (the problem happened in the branch, which is a little out of synch). –  dario_ramos Apr 27 '12 at 13:34
    
Hmm, well debug output is usually the first thing I try to check, because you can actually learn a lot by looking at the debug spew! (the debug messages are usually detailed!) –  bobobobo Apr 27 '12 at 13:44
1  
For example, here is a debug message I recently captured when I was trying to create a texture cube as a dynamic texture: D3D11: ERROR: ID3D11Device::CreateTexture2D: A TextureCube cannot be a D3D11_USAGE_DYNAMIC resource. [ STATE_CREATION ERROR #101: CREATETEXTURE2D_INVALIDDIMENSIONS ]. I just wouldn't have known that without the debug spew. –  bobobobo Apr 27 '12 at 14:29
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.