Jump to content
• Advertisement

# problems with DebugSetLevel & D3DXCreateFileEffect()

This topic is 2699 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

## Recommended Posts

Hi,

since a week I have the issue that every time on the exit of my application in the destructor of my resource-manager, I get an error trying to Release() my effect files (LPD3DXEFFECT). The error says "read access violation" at some adress (not 0x0000000). I added some output to my debug file to make sure each effect file is only loaded once, and that the destructor of the manager is only called once. I didn't found any strange behavior here, and also my textures, which are stored in the same class and released in the same destructor, work fine. Today I made a strange "discovery": due to performance issues I did some profiling, and I found out that D3DXCreateEffect() is called a whole lot of times during the whole code. This call causes about 5-35% (!) of my applications CPU time (measured with "very sleepy, always more then 60 seconds), even though I only load 5 effect files, and I made sure that they are only loaded one time! So I looked around the profiler, but I couldn't really find any clue what was calling D3DXCreateEffect(). I'm pretty sure it is called however, as this is the only explanation why release() fails for my effects, as far as I know (there are no calls of release() for any effect pointer elsewhere in the code). Does someone have any idea what could cause D3DXCreateEffect() being called randomly? My profiler tells me this weird stuff for "D3DXCreateEffect() called from:"

So.. first of all 50% of the time it is called from D3DXCreateEffect. This is somewhat normal, don't know if only for that profiler or in general. The second most used call is from the destructor of my resource-manager, which looks like this:
 CResources::~CResources(void) { DebugOutput("Destroying manager!"); for(map<wstring, LPDIRECT3DTEXTURE9>::iterator ii=m_MapTextures.begin();ii!=m_MapTextures.end();++ii) { ii->second->Release(); } for(map<LPCWSTR, LPD3DXEFFECT>::iterator ii = m_Effects.begin(); ii!=m_Effects.end();++ii) { ii->second->Release(); } }

and nearly every other call where I use the effect. Did I get something wrong? Is it illegal to do something with a direct long-pointer to a d3dx-effect? I really can't see any other reason for this strange behavior, except directx not working as intended. I didn't have that issues from the beginning, I was using effect files for about 2-3 weeks without any problems, until at some time this error at releasing them appeared. It appeared somewhere around the time I started doing postprocessing, but I can't really tell. Any ideas why this is happening/how to solve it?

The only perhaps relation I could find, as it is weird too, is a extraordinarly often call of "DebugSetLevel", which is called from nearly every directx-function, but the most from here:

void CDirect3D::EndScene(void) { m_lpDevice->EndScene(); m_lpDevice->Present(0, 0, 0, 0); }

It takes a huge amount of inclusive time (10-25% compared to the sum of all others), while only a small amount of exlucive time. It also calles Direct3DShaderValidatorCreate9 very often, so could this be a link to the issue with the effect files? I don't know, anyhow, this behavior is very strange. I did profiling before and I never had the function "DebugSetLevel" anywhere in the profile. I made sure DirectX-runtime is set to release and anything the has to do with debug is disabled.

So, can someone help me? I really don't know what to do against these two issues anymore, I spend a whole day trying to solve this, but somehow nothing works... thanks in advance

#### Share this post

##### Share on other sites
Advertisement

• Advertisement
• Advertisement

• ### Popular Contributors

1. 1
2. 2
3. 3
Rutin
19
4. 4
5. 5
• Advertisement

• 9
• 19
• 9
• 31
• 16
• ### Forum Statistics

• Total Topics
632617
• Total Posts
3007459

×

## Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!