if (SUCCEEDED(D3DXLoadMeshHierarchyFromXA(pFilename.c_str(),
        D3DXMESH_MANAGED, d3d::GetInstance().GetDevice(), &Alloc, NULL, &m_pFrameRoot, &m_pAnimController)))
    {
        // load it also as a static mesh
        if (FAILED(D3DXLoadMeshFromXA(pFilename.c_str(), D3DXMESH_MANAGED, d3d::GetInstance().GetDevice(),
            NULL, NULL, NULL, NULL, &m_pStaticMesh)))
        {    
            cout << "Failed to load mesh: " << pFilename << endl;
            return false;

        }
    }
 
LPD3DXFRAME                           m_pFrameRoot;
CComPtr<ID3DXAnimationController>     m_pAnimController;    
CComPtr<ID3DXMesh>                    m_pStaticMesh;

D3DX: MEMORY LEAKS DETECTED: 4 allocations unfreed (48 bytes)
D3DX: Set HKLM\Software\Microsoft\Direct3D\D3DXBreakOnAllocId=0x125c5 to debug

I've verified that the D3DXLoadMeshFromXA is leaking, but the question is why?

When I comment out the D3DXLoadMeshFromXA line, I only get 24 bytes leakings (2 allocations)

Thanks

Jack

I don't see anything obvious that would lead to leaks with the code you've posted. Are you sure you're not just reporting leaks before the m_pStaticMesh is destroyed? If you call that code multiple times, do you get multiple leaks, or still just one?

I know nothing about D3DX, only straight D3D, so the above advice may not apply. However, in normal D3D order-of-destruction is important when chasing leaks.

From MSDN:

To free this data, call ID3DXAnimationController::Release to free the animation sets, and D3DXFRAMEDestroy, passing in the root node of the frame hierarchy and an object of your derived ID3DXAllocateHierarchy class. DestroyFrame andDestroyMeshContainer will each be called for every frame and mesh object in the frame hierarchy. Your implementation of DestroyFrame should release everything allocated by CreateFrame, and likewise for the mesh container methods.

Sounds like you need to call DestroyFrame?

I think only around 2% of these types of questions asked on here actually post the code that's responsible for the problem.

You've showed us where this thing is allocated. Great. Now show us where it is de-allocated. And I don't mean just in the CComPtr. Give us the whole call stack for how it'll get there. Where are those member variables stored? Where does that parent class live? When is it destructed? Can you put a breakpoint where that happens?

Hi There,

I pin down the problem now. The problem is in the 3d asset itself.

I didn't know why the material of the asset has multiple texture filenames, and the loader of mine just can't handle it.

I would prefer to have one texture filename per material, each applies to diffuse map and normal map etc

Hi again.

I didn't know why the material of the asset has multiple texture filenames

I think I do if my memory serves me correctly, Your using 3DSMax and exporting .X files but the thing is when the plug in for .X files in 3dsmax exports what ever material is in the materials editor gets linked (Had me for a while) the fix go into the materials dlg and remove none used materials. thats why all my objects became just skinned meshes for all things.

Just some had less bones like A bone.

That's what I think it is.