   _BLOCK_TYPE_IS_VALID(pHead-nBlockUse)
  It says "Memory still allocated!  Alloc count = 136".I'm really confused. I've been trying to figure it out for 2 days now but I can't seem to find any pointer that hasn't been "deleted" or Release() (I'm using DirectX9). When I commented out my function to load a mesh the problem dissapeared but the weird part is that I haven't changed anything in it's code for months. At this point my head is a mess.void Mesh::Load(LPCWSTR filename){LPD3DXBUFFER tempBufMaterial;D3DXLoadMeshFromX(filename, D3DPOOL_DEFAULT, pD3DDev, NULL, &tempBufMaterial, NULL, &matCount, &model);D3DXMATERIAL* tempMaterials = (D3DXMATERIAL*)tempBufMaterial->GetBufferPointer();material = new D3DMATERIAL9[matCount];texture = new LPDIRECT3DTEXTURE9[matCount];for(DWORD i = 0; i < matCount; i++){    material = tempMaterials.MatD3D;    material.Ambient = material.Diffuse;if(FAILED(D3DXCreateTextureFromFileA(pD3DDev, tempMaterials.pTextureFilename, &texture)))texture = NULL;}tempBufMaterial->Release();/*delete[] tempMaterials; <- apparently it was already deleted, because I got 1 more of the error when trying to delete that, not when the program shut down, like the other.*/}I tried with breakpoints on all the "Realease()'s" but none of them gave the error. The error is when WinMain() is finished.   
  Well, it's a bit hard to help if we can't see the problem code...   ;  Added the code for the function to load a mesh, which I've been using for ages but now somehow it seems I'm getting the error. I have a hard time believing it's what causing the error.   ;  Where do you delete the "material" and "texture" arrays?   ;  In my destructor, which works as intended.Can it be caused by HLSL variables?   ;Quote:In my destructor, which works as intended.Apparently not, as it either doesn't run at all, doesn't run enough times to match the allocation count, or fails to execute the code that actually deletes, etc. Let's see it.You also may be trashing memory somewhere by writing outside the bounds of any array. You're basically going to need to provide more code.Quote:Can it be caused by HLSL variables?Only in the sense that if you heap-allocate some value that you ultimately try and pass to a shader via some API and then fail to delete that value; but that actually has nothing to do with HLSL or the shader, and nothing in the shader itself can have this kind of impact on code that executes on the CPU.   ;  No; HLSL code runs in a completely different way than your main program. In particular, HLSL variables have no concept of the "heap" which is the memory area your data goes to when you allocate it via new (loosely speaking - it's a bit more complex than that but the details aren't important at the moment).The best thing I can suggest is to make sure that the problem is really in the code you think it is; try eliminating things in large chunks until the problem goes away, then re-enabling things in small chunks until it reappears. That should narrow it down.By the way - what compiler/other tools are you using? That might help us get an idea of why this is reporting memory leaks.   ;  Apparently I had a destructor so when I tried to release the memory texture and materials were pointing to it was done 2 times.   ;Quote:Original post by HannesnisulaApparently I had a destructor so when I tried to release the memory texture and materials were pointing to it was done 2 times.Not to be mean or too off-topic, but this is one of major downsides of C++.In managed languages this would be either impossible, or it would result in null pointer exception, with a nice stack trace.   