PIX - Direct3DCreate9 never returns
Author
I'm trying to debug a problem with my application. Therefore I am trying to run it in PIX. Yet if I do so Direct3DCreate9 will never return. If I run my application outside of PIX it runs just fine (except for the problem I'm trying to debug, but that is another story).
I am running a debug build (obviously) with the Direct3D debug runtime. Using the retail version doesn't work either. There is not debug output to give me any kind of clue about what's going on. No exceptions are thrown. I just get nothing :(
I'm using the November 2008 SDK if that matters.
Author
Well, if reading my mind would solve the issue then I think I wouldn't have posted here ;)
The code is trivial. A Direct3DCreate9 call is not really complex.
And as I noted above, the problem only occurs when the application is running through PIX. Thus I was hoping that someone would have come across a similar issue in the past.
Of course it is possible that the problem is related to something else in my project structure. But I doubt anyone would like to browse through even little bit of the application.
The code is trivial. A Direct3DCreate9 call is not really complex.
#include "stdafx.h"#include "Direct3D.h"namespace gEngine { namespace Direct3D { CComPtr<IDirect3D9> getDirect3D() { // Accquire Direct3D9 interface IDirect3D9* d3d = Direct3DCreate9( D3D_SDK_VERSION ); // Create COM pointer wrapper CComPtr<IDirect3D9> comPtr; comPtr.Attach( d3d ); return comPtr; } }}And as I noted above, the problem only occurs when the application is running through PIX. Thus I was hoping that someone would have come across a similar issue in the past.
Of course it is possible that the problem is related to something else in my project structure. But I doubt anyone would like to browse through even little bit of the application.
I can't see anything wrong with your code, however i have also had problems with IDirect3D9 and COM pointers. Have you tried this without the smart pointer?
Author
Well, it hangs before I even attach it to the CComPtr. Direct3DCreate9 itself never returns.
Here's some more things to try:
- Make sure you have the latest drivers for your video card. By the way which card is it you have?
- Find or Create a simple program that does a minimal setup and calls D3DCreate9() and see if that works in PIX. You could use one of the sample programs that comes with the SDK, or borrow one from a tutorial.
If that simple program works then try cutting things out of the problematic one till it works.
You could also try attaching the debugger to your program while it's hung, and seeing if you can find anything useful from that.
- Make sure you have the latest drivers for your video card. By the way which card is it you have?
- Find or Create a simple program that does a minimal setup and calls D3DCreate9() and see if that works in PIX. You could use one of the sample programs that comes with the SDK, or borrow one from a tutorial.
If that simple program works then try cutting things out of the problematic one till it works.
You could also try attaching the debugger to your program while it's hung, and seeing if you can find anything useful from that.
Author
I do have the latest drivers for my card. I tried it both at work (Radeon 4870) and at home (4870x2). Sadly I have no access to a GeForce at this time.
I'll try with a simple program to see how that turns out, but I have a feeling that that might work ;) Cutting things from this project until it works would obviously be something that might offer results. Though this project is quite large already and this will take quite some time.
I am attaching a debugger to that application. That's how I tracked down the function where it hangs in the first place. The application calls Direct3DCreate9 and the call never returns.
I'll try with a simple program to see how that turns out, but I have a feeling that that might work ;) Cutting things from this project until it works would obviously be something that might offer results. Though this project is quite large already and this will take quite some time.
I am attaching a debugger to that application. That's how I tracked down the function where it hangs in the first place. The application calls Direct3DCreate9 and the call never returns.
Quote:Original post by genchaWhat if you do Debug -> Break All and look at where the current thread is? Is it in some windows system call?
I am attaching a debugger to that application. That's how I tracked down the function where it hangs in the first place. The application calls Direct3DCreate9 and the call never returns.
Author
When I pause the process Visual Studio tells me that the process seems to be deadlocked or is not running any user-mode code.
This is the call-stack:
This is the call-stack:
> ntdll.dll!_KiFastSystemCallRet@0() ntdll.dll!_NtWaitForSingleObject@12() + 0xc bytes ntdll.dll!_RtlpWaitForCriticalSection@4() + 0x8c bytes ntdll.dll!_RtlEnterCriticalSection@4() + 0x46 bytes ntdll.dll!_LdrLockLoaderLock@12() + 0x1df0 bytes ntdll.dll!_LdrGetDllHandleEx@20() + 0x22f bytes ntdll.dll!_LdrGetDllHandle@16() + 0x18 bytes kernel32.dll!_GetModuleHandleForUnicodeString@4() + 0x1d bytes kernel32.dll!_BasepGetModuleHandleExW@16() + 0xf2 bytes kernel32.dll!_GetModuleHandleW@4() + 0x1f bytes ole32.dll!InitMarshalling() + 0xf5 bytes ole32.dll!GetIFDFromInterface() + 0xe bytes ole32.dll!ContextInfo::GetSize() + 0x3c bytes ole32.dll!ActivationProperties::GetSize() + 0x6e bytes ole32.dll!ActivationProperties::GetMarshalSizeMax() + 0x7d bytes ole32.dll!CDestObjectWrapper::GetMarshalSizeMax() + 0x79 bytes ole32.dll!_CoGetMarshalSizeMax@24() + 0x77 bytes rpcrt4.dll!NdrpInterfacePointerBufferSize() + 0x60 bytes rpcrt4.dll!NdrpPointerBufferSize() + 0x13f0f bytes rpcrt4.dll!_NdrPointerBufferSize@12() + 0x29 bytes rpcrt4.dll!_NdrpSizing@8() - 0x7d1b bytes rpcrt4.dll!_NdrClientCall2() + 0xfc bytes rpcrt4.dll!_ObjectStublessClient@8() + 0x5d bytes rpcrt4.dll!_ObjectStubless@0() + 0xf bytes ole32.dll!CRpcResolver::CreateInstance() + 0x137 bytes ole32.dll!CClientContextActivator::CreateInstance() + 0xdbfb bytes ole32.dll!ActivationPropertiesIn::DelegateCreateInstance() + 0x4b bytes ole32.dll!ICoCreateInstanceEx() + 0x10b4b bytes ole32.dll!CComActivator::DoCreateInstance() + 0x28 bytes ole32.dll!_CoCreateInstanceEx@24() + 0x1e bytes guard32.dll!003b523f() [Frames below may be incorrect and/or missing, no symbols loaded for guard32.dll] wbemprox.dll!CDCOMTrans::DoActualCCI() + 0x3d bytes wbemprox.dll!CDCOMTrans::DoCCI() + 0x2a bytes wbemprox.dll!CDCOMTrans::DoActualConnection() + 0x16e bytes wbemprox.dll!CDCOMTrans::DoConnection() + 0x25 bytes wbemprox.dll!CLocator::ConnectServer() + 0x72 bytes dxdiagn.dll!CWMIHelper::CWMIHelper() + 0x5b bytes dxdiagn.dll!CDxDiagProvider::Initialize() + 0x133 bytes PIXHelper.dll!008bf282() PIXHelper.dll!00929c4f() PIXHelper.dll!0092efbf() PIXHelper.dll!00934300() ntdll.dll!_ZwClose@4() + 0xc bytes advapi32.dll!_BaseRegCloseKeyInternal@4() + 0x49 bytes advapi32.dll!_RegCloseKey@4() + 0x84 bytes PIXHelper.dll!008ad1d6() PIXHelper.dll!0092c458() ntdll.dll!_RtlAcquirePebLock@0() + 0x28 bytes ntdll.dll!_RtlReleasePebLock@0() + 0xf bytes ntdll.dll!_RtlGetFullPathName_Ustr@24() + 0x2f7 bytes ntdll.dll!_RtlGetFullPathName_U@16() + 0x33 bytes 565308ec()
From the look of that call stack I think you're stuck in a deadlock on the loader lock. Some DLL is probably doing far too much work in it's DllMain().
It might be worth finding out what the other thread is that it's deadlocked with. You can do that by looking for other threads that are waiting on critical sections. Hopefully there won't be too many threads running so soon after starting the application.
If it's your DLL there's more info on what not to do in DLLMain() here:
http://blogs.msdn.com/oldnewthing/archive/2004/01/27/63401.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/01/28/63880.aspx
http://blogs.msdn.com/oldnewthing/archive/2007/09/04/4731478.aspx
If the DLL causing the problems isn't yours I'd suggest checking what threads you create at startup, and where possible deferring them till after D3D is set up.
It might be worth finding out what the other thread is that it's deadlocked with. You can do that by looking for other threads that are waiting on critical sections. Hopefully there won't be too many threads running so soon after starting the application.
If it's your DLL there's more info on what not to do in DLLMain() here:
http://blogs.msdn.com/oldnewthing/archive/2004/01/27/63401.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/01/28/63880.aspx
http://blogs.msdn.com/oldnewthing/archive/2007/09/04/4731478.aspx
If the DLL causing the problems isn't yours I'd suggest checking what threads you create at startup, and where possible deferring them till after D3D is set up.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
