what is your high level usage of CDOResource?
I assume both threads get a pointer to it, and make sure that resources are locked and unlocked before being accessed, right?
Where do strings come into play, how are they shared?

Note also that the pattern you are using can lead to deadlocks. If the code is used like this:

if (resource->Lock())
{
// .. use resource

resource->Unlock();
}

if the resource does not exist then you never leave the critical section.

sorry was on out for vacation

all resources are derived from the class and yes it can dead lock if resource is locked twice by same thread but most of the time the function calls lock and unlock the resource as needed. i think somewhere something is just going stray in memory

as called this is the disassembly

7C90122B nop
7C90122C nop
7C90122D nop
7C90122E nop
7C90122F nop
7C901230 int 3

in ntdll.dll deep called by direct x called by d3dx

this time called by the 2nd line here

Lock();
HRESULT hr = D3DXCreateEffectFromFileA(m_pD3DDevice, Filename.c_str(), pDefines, pInclude, Flags, pPool, ppEffect, ppCompilationErrors);
ReleaseLock();

called as follows

if(FAILED(g_CDODevice.CreateEffectFromFile(Filename, NULL, NULL, dwShaderFlags, NULL, &m_pEffect, NULL)))

Superficial; the location it jumps to is irrelevant. You're probably passing a bogus pointer. Check the parameters to the call to CreateEffectFromFile, make sure they're all valid (use a debugger).

It's definitely your fault, unfortunately it's not definitely at the one line of code you posted. Memory corruption bugs are often very subtle, and the actual cause of the bug can often be very far from where the bug manifests itself. If you're not willing to post more of your code, you're not going to be able to get much more help.

My comment about the deadlock is not that a thread locking twice will cause a deadlock, the comment is that if the usage pattern of lock/unlock is what I illustrated then you can have deadlocks. Your API could be improved in that sense, but that is not relevant to the problem you have.

Going back to the issue at hand, you want to make sure that all the parameters you pass to D3DXCreateEffectFromFile (or other APIs) are stack based or if they are global that accessing them is safe from multiple threads.

If the Filename parameter is not local to the loading thread, and could be modified by other threads you can certainly run into problems.

If the usage is:

Device->LoadResource

Device::LoadResource
Enqueue request to Load Thread

LoadThread
LockResource
LoadEffect
UnloackResource

If the parameters you pass to load resource are references or pointers they can either be out of scope and be overriden when the load thread is running.

If the problem is heap corruption (unlikely) there are some things you can do on Windows to try to catch the problem, but is painful. I think there is a way to turn on a validating heap on windows, but I do not recall the details.

For overruns or underruns there used to be a useful tool called BoundsChecker, not sure if it still exists or if they have a trial version, but if they do you might be able to use it to help you diagnose your problem.

yoshscout you are protecting the potential for the class CDOResource from being copied and passing by a type of reference aren't you?
ie copy constructor in protected/private.
assignment operator in protected/private.

If you do not do this, two classes may try and delete the same mutex when leaving scope.

i might be misunderstanding your question but objects are generally passed via pointer which is sorta via reference

copy constructor is not protected nor is assignment operator

i think this is whats going on http://www.debuginfo.com/tips/userbpntdll.html

this just popped in the debugger for the first time outta no where

===========================================================
VERIFIER STOP 00000003: pid 0x6A4: multithreaded access in HEAP_NO_SERIALIZE heap

02151000 : Heap handle
000008E8 : Thread owning heap lock
0000084C : Current thread trying to acquire the heap lock
00000000 :
===========================================================

after hex converting it and cross referencing to the debuggers values for my threads the main thread owns lock on heap and the resource loader is trying to acquire the heap lock

Are you sure you are linking against the multi-threaded version of the CRT?
If your project is split across multiple dlls you need to make sure everybody is linking against the multi-threaded version of the CRT.

Arguments passed by pointer or by reference are equivalent. If you create an object on thread 1 and pass a pointer to it to thread 2 then you can run into several problems. The first problem is if the object passed was created on the stack of thread 1 since by the time thread 2 tries to use it the stack of thread 1 has been cleaned up or modified.